攀钢MES应用服务器TMesAppPlatform的设计研发

［摘 要］介绍了为攀钢MES建设所设计研发的MES应用服务器平台软件TMesAppPlafform，简述了软件的设计思路和基本架构，重点阐述了系统研发所采用的关键技术及实现，可供类似平台软件的研发参考。 攀钢整体产销系统于2005年7月1日整体上线运行，其特点之一是“整体推进、集成应用”，同步建设的炼钢、热轧、冷轧3个制造执行系统（MES）是其重要的下位支撑系统。在MES建设过程中，攀钢结合自身实际和软件产业发展战略要求，于2004年4月自主设计研发成功了MES应用服务器平台软件（简称：TMesAppPlatform），并于2004年6月开始作为应用开发平台支撑攀钢3个MES的应用研发，确保了攀钢MES于2005年3月成功上线并稳定运行至今。 本文将对TMesAppPlatform的设计思路和基本架构、关键技术及实现进行介绍，供类似平台软件的研发参考。 1 设计思路及基本架构 TMesAppPlatform定位为MES的服务基础件，是应用软件系统的开发及运行支撑平台，首先应保障平台系统本身稳定、高效可靠，实现对应用软件多层架构开发的支持，支持应用软件开发方法的改进，从根本上提高软件扩展性和开发效率。 MES本质上是在线实时系统，其基础和难点是实时数据的管理和使用，所以要求建立一套数据（特别是实时数据）管理机制，使数据与业务逻辑有效耦合，避免软件扩展性差、开发效率低等问题。 根据构件化、图形化、增量开发的原则确立软件架构和研发方法，借助AOP（面向方面编程Aspeet-Oriented Programming）思想，将应用程序中的业务逻辑与对其提供支持的通用服务分离开，把通用服务抽象为“数据”，集中统一管理，让数据实时驱动业务逻辑处理，使TMesAppPlatform严格遵循AOP的设计思想，支持采用AOP方法开发MES应用系统。 根据上述主要设计思路，TMesAppPlatform应用服务器的功能架构设计如图1所示。 2 关键技术及实现 基于上述功能架构，在Windows平台上采用VC＋＋/C＋＋、COM/COM＋技术、UML建模技术及面向对象（OOP）的开发方法，使TMesAppPlatform支持三层应用开发。 2．1 访问控制（核心调度） TMesAppPlatform借鉴Windows线程调度机制，通过建立“流水线程池”架构，建立了完整的服务调度机制和实时消息机制，以统筹管理和及时调度各项系统服务及应用服务。系统本身包含的服务及托管的应用服务（业务处理逻辑）皆以组件方式存在于系统中（以线程形式存在），同时支持组件动态加载。 “流水线程池”架构的原理是监控“空闲”和“忙碌”两张线程登记表，并对忙碌线程的运行状态进行监控，使“流水线程池”连续不断地向外部提供初始化后的空闲线程，降低线程在需要服务时才创建对性能的负面影响，并能够及时清除运行完毕不再需要的线程，构造一个线程的“供应-使用-回收”流水线。 为提高系统性能和可靠性，平台采用冗余结构设计，构成冗余的“主应用服务”和“冗余应用服务”，可分别运行在不同的物理服务器上，确保在“主（运行）应用服务”由于某些原因发生故障停止服务时，由“冗余应用服务”继续提供服务，保障应用系统的不间断运行。 为保证TMesAppPlatform具有安全的访问控制，平台设计了精细的、可扩展的权限管理功能，按照域、组、类、对象、属性进行数据和应用服务的权限控制，并可与数据库的访问权限绑定在一起。 2．2 实时数据库的建立和数据的集中管理 采用数据基类设计技术，开发建立了一套基于内存并与外部关系数据库有效衔接的实时数据库管理系统，作为整个服务器的核心，实现对系统数据（特别是实时数据）的集中管理。应用涉及到的所有数据由服务器统一管理，隔离业务逻辑对数据的存取和管理；通过建立事务（Transaction）管理机制，确保数据一致性；同时，系统自动根据数据实时性和访问频度进行高速数据缓存处理，自动管理缓存的建立、更新及释放；提供符合SQL99标准的数据操作（增、删、改、查）；并在系统架构内封装了表1所列的数据类型，支持应用逻辑组件的开发。 此外，在VC环境下，还可以使用TMesAppPlatform提供的CL3Variant类来封装应用需要的Variant数据类型，从而简化逻辑组件和前台表现层（HMI）程序的开发。 2．3 数据预约/发布管理（Sub/Pub） TMesAppPlatform基于数据的集中管理，实现系统数据的预约/发布管理，支持数据广播（组播）、预约发布、定向应用等灵活的发布方式，完成对数据的自动推送，让数据驱动业务逻辑（应用服务），降低应用逻辑及客户端软件的开发难度，并提高系统的响应实时性。 基于TMesAppPlatform设计应用服务组件（包括应用逻辑和客户端软件）时，通过配置文件完成数据预约定义（数据名称、数据预约条件定义）。TMesAppPlatform加载应用服务组件时，根据数据预约配置文件，在系统中注册数据预约，形成具备全局唯一消息ID的消息参数表（消息的ID、名称和数据参数表），并按照数据预约机制，为应用服务组件提供数据服务。 另外，系统也可以采用广播（组播）方式向应用服务组件发送数据，针对特殊应用，还可主动向某个特定应用服务组件发送数据。一旦应用服务组件（或前台HMI）监听收到响应数据，立即驱动相应业务逻辑组件进行数据逻辑处理，实现真正意义上的数据驱动业务逻辑。系统的数据预约/发布管理机制如图2所示。 为防止当组件卸载后预约信息丢失，系统建立了全局预约记录库，用于在组件被卸载并重新加载后，恢复原有预约记录。预约记录库存放在访问控制器中，使用一个以URI为关键字的预约记录表，记录对此URI进行预约的所有预约者的信息和预约类型。当任何对象对其它对象进行预约和解除预约时，访问控制器向预约记录库中登记预约信息。当组件卸载并重新加载后，组件管理器从预约记录库中读出所有和该组件相关的记录并重新恢复预约。 2．4 名字解析管理（Name Resolve） 采用资源定义的形式命名系统中所有可访问资源，通过从资源名称到实际物理对象的映射，完成系统数据名字解析功能。 2．5 对象映射（Object Map） 采用映射技术，对TMesAppPlatform托管的应用逻辑对象（以应用服务组件形式存在）进行管理，以确保HMI对应用服务组件对象的服务请求准确地定位。 2．6 客户端管理（Client Manager） 提供客户端的请求响应，实现对客户端请求的解释并转发到TMesAppPlatform的应用服务的调用上，并负责完成返回数据的处理。 该模块还监控应用服务器所在网络中的所有客户端，检查客户端的连接状态，在客户端连接失效后及时地通知相关的客户端会话（Session）退出。 2．7 人机界面接口（HMII/F） 作为应用服务器和HMI之间的隔离层，人机界面接口向HMI客户端表现层提供应用服务器的接口，进行HMI数据的转发和服务请求。人机界面的开发只需设计HMI的图形布局和数据在图形界面上的表现形式，不必关心网络通信实现、业务逻辑的处理及数据存储与管理，实现真正意义上的三层应用架构的开发。 2．8 数据层接口处理（Data layer） 数据层接口处理完成系统数据访问层的控制，抽象对底层数据库、其他外部系统数据的访问。数据库访问控制通过统一的接口封装，形成数据库访问组件，实现对数据库的统一访问（如图3所示），其封装的主要功能有： （1）实现应用逻辑对象和数据库表的数据映射；维护逻辑类和数据库表结构的匹配并进行一致性检查；针对逻辑类名称系统和数据库名称系统对大小写区分的不同规定，自动进行大小写转换和名称匹配维护。 （2）具备数据库连接池功能，使用数据库共享连接池降低数据库的连接负荷，提高数据库访问速度，实现用户对数据库连接池的维护和管理。 （3）实现多种数据库访问方式的切换，如：可通过配置来选择采用ADO或ODBC方式访问数据库，并实现多个数据源的并行使用，完成对Oracle，SQL Server，DB2，Access等数据库的访问。 （4）实现数据源监控扫描功能，完成从数据库中数据源到应用服务（逻辑对象）的反向数据变更通知。 平台集成开发了“多点信使”系统，以实现对外部数据访问控制，其配置结构见图4，“多点信使”系统具备自动重发功能。 2．9 Web组件库 为了支持实时数据的Web应用，确保使用．NET架构创建的任何应用程序均可按URI访问系统数据服务，实现了基于TMesAppPlatform架构的Web组件库。该组件库结构见图5，图中数据适配器包含若干数据适配器类和接口的定义，其作用是在系统和Web界面之间直接建立数据联系通道；Web控件群中的Web控件使用数据适配器来访问系统提供的逻辑功能，获取数据并将数据实时显示在Web页面上。 2．10 逻辑对象（Logic Object） 逻辑对象是应用系统的业务逻辑处理模块，由独立的逻辑COM组件构成，逻辑对象在应用逻辑组件声明后，提交服务器托管，由服务器对应用系统各逻辑组件进行调度管理，逻辑对象之间无法直接调用或通信，而是将请求发给TMesAppPlatform的核心——访问控制，由访问控制来控制逻辑对象的使用，各逻辑组件在数据的驱动下，完成整个应用功能。 应用逻辑对象以组件dl