LaMap 软件总线中间件和ODBC 数据库的集成.docVIP

LabMap软件总线中间件和ODBC数据库的集成 C. Bruce-Boye, W. Kanewski, D. Kazakov, Yaohui Wu 摘要：在这篇论文里我们想到了一个方法，这个方法是在LabMap软件总线中间件的基础上，把数据提取与控制自动化系统和企业版数据库方案集成在一起。我们提出了一个数据库接口与LabMap独立的体系结构。LabMap的各个应用可以透明地进入数据库，就象把数据库当作另一个虚拟硬件设备。这个方法的优点是数据库可以平滑地提供给用户应用软件，而且费用低，不用重新设计软件。 LabMap[1]是一个软件中间件总线系统，被用作软实时系统中的数据提取和控制。它已成功地配置在自动化、医疗和其他领域中。越来越多的工序自动化系统需要数据库方案的支持。通过与数据库管理系统互操作，使得LabMap进一步集成到了客户系统软件中。 开发数据库互连(ODBC)[2]通过特定数据库驱动服务，提供了与不同数据库互连的体系结构。ODBC在数据库APIs(应用程序接口)上是基于来自X/Open和ISO/IEC的呼叫－等级接口(CLI)规范，同时ODBC把结构化查询语言(SQL)[3]当作数据库存取语言。目前ODBC在存取数据库上是一个被广泛接受的技术，受大多DBMS(数据库管理系统)用户支持。 为了把数据提取和自动化控制集成到企业系统里，用户独立的数据库存取是一个重要的需求。为此，LabMap提供了基于ODBC的数据库支持。因此，使用LabMap中间件的应用软件可以享受来自所有DBMSs的完全独立的数据库以及所有功能和高性能，并且能实现最大的互操作性——也就是说，就象同一个应用在存取DBMSs。 通过LabODBC接口，LabMap提供到ODBC数据库引擎的完全透明的存取。这就意味着，LabMap用户可以把数据库看作与自动化系统里的其他硬件和软件组件类似的一个组件。图1描绘了基于LabMap把数据库集成到自动化系统的一个例子。这个图说明了分布在两个主机上(主机1和主机2)的一个系统。这两个主机通过LabMap总线系统连接到局域网(图示中的LabNet接口)。每个主机都通过LabMap连接着一个硬件。例如，在图中主机1是ProfitNet，主机2是CAN-Bus。对应的LabMap接口分别称作LabProfiNet和LabVXL。 LabMap通过特定的硬件驱动器(如图中的灰色方框)与硬件通信。就如上面提到的硬件，可以用类似的方法来存取企业版数据库。在这个实例里，LabODBC是ODBC应用层的接口，而它自己又通过企业网连接着企业版数据库。 LabODBC体系结构的简要描述 LabODBC体系结构如图2所示。LabODBC在概念上表示一个ODBC环境。LabODBC的每个设备单元都是一个到某个DSN(数据源名字)的ODBC连接。LabODBC可以处理的设备单元数目不受限制，因此通过LabODBC接口用户应用软件能同时存取任意个数据源。不同的ODBC连接可以共享一个数据源。这就意味着，通过不同的LabODBC设备单元，允许用户应用软件进行多个数据源事务处理。 LabODBC变量表示ODBC状态。状态可以预编译以达到最佳性能。技术上它是通过使用预先准备的ODBC状态来实现的。一个I/O操作调用一个LabODBC变量，相应地执行一个SQL查询。查询本身存储在变量配置表里。查询的参数和结果映射在LabMap的各个自变量里。按惯例它们是LabUser变量，它们表示用户应用软件对数据源的特定的应用域视图。通过ODBC参数绑定机制，可以实现自变量和SQL查询参数及结果的映射。通过ODBC提供的C语言数据类型和SQL语言数据类型之间的类型转换，可以透明地将参数类型设置成目标数据库特定类型或者恢复成LabMap变量类型。 事务模型 考虑到用户应用软件和数据库之间的通信，如何分布式地并且协作地存取数据是个很关键的问题。通过使用事务机制可以实现顺序的原子的更新。一个事务是指一个工作单元，它是一个原子操作；也就是说，这个操作作为一个整体成功或失败。LabODBC接口在设备单元里封装了多个事务。每个设备单元表示一个数据源连接。设备单元一旦启动，这些连接就建立。设备单元一旦结束，这些连接就关闭。在一个单元活动期间，可以发生一个或多个与数据源相关的事务。对于一个设备单元来说所有的事务是顺序的。与设备单元相关的LabMap变量集在事务期间共享一个数据视图。可以通过提交或回退事务来完成一个事务操作。如果事务被提交，则对事务的改变永久有效。如果事务被回退，所有受影响的数据可以回退到事务启动前的状态。通常一个应用可能希望有更精细的控制。为了达到这个目的LabODBC提供了几个特定的变量，它们能显式地提交或回退设备单元的当前事务。一个LabMap O