基于Web Service的EAMS离线应用研究
2011-02-20冉崇善
冉崇善, 王 琦
(陕西科技大学电气与信息工程学院, 陕西 西安 710021)
0 前 言
企业资产管理系统，简称EAMS(Enterprise Asset Management System)，是一个面向资产密集型企业的信息化解决方案，以提高资产利用率、降低企业运维成本为目标，从而帮助企业提高其经济效益和市场竞争力.
随着信息化的推进和发展，EAMS已由最初的单机C/S架构转变为业界普遍使用的B/S架构，该架构能较好地满足企业的分布式应用需求.然而随着企业信息化的不断发展、业务的不断增长以及网络的不稳定性等因素的影响，导致单纯应用该架构时往往不能保证客户端处于离线状态时系统正常工作，而基于Web Service[1]的系统架构则可以很好地解决此问题.
基于Web Service的架构可充分利用客户端和Web技术的优势，其最大优点就是可以离线使用，使用户不论何时何地都能正常地进行工作.然而在具体实施时还有许多问题待解决，如客户端在线和离线状态的无缝切换时还存在着如何处理服务请求、如何缓存操作数据、Web Service服务器的响应效率低下等问题[2].本文以Web Service架构为基础，采用一种新的方案来提高Web Service服务器的响应效率，从而较好地解决了离线应用中的数据同步问题.
1 面向服务的数据同步解决方案
目前有两种数据同步方案可供选择：以数据为中心的方案和面向服务的方案.前者采用本地数据库和合并复制机制技术，在服务器和客户端之间相互复制操作数据来解决，其最大特点是要求在客户端安装本地数据存储区；后者是通过服务请求与网络上的服务进行交互的，如果客户端处于离线状态，它可以推迟服务请求，直到从新转换为在线模式时再提交.
面向服务解决方案的最大特点是客户端并没有与它使用的服务紧密结合在一起，和服务是彼此独立的，可以自由地与所需的任何服务进行交互，所以面向服务的方案中客户端可将重点放在服务请求本身上，而不是放在对本地保存的数据进行直接更改上，当客户端在线时只需要提交服务请求就可完成数据操作任务.另外，服务请求可能会导致客户端或服务器上的状态更改，但这些更改只是服务请求的副作用.
在面向服务方案的具体实施过程中还需要使用一种允许存储服务请求详细信息的基础结构，该基础结构由下列4个主要元素组成：
(1)服务代理：服务代理提供服务的主要访问点.它管理客户端与服务的所有交互，并封装所有必要的逻辑以允许客户端创建服务请求.
图1 面向服务方案的组件
(2)服务请求：服务请求的所有详细信息都封装在一个服务请求对象中.然后，服务请求保留在服务请求队列中，直到执行程序组件可以对它们进行处理.服务请求对象负责发出实际的服务请求.
(3)服务请求队列：该队列为服务请求对象提供持久的存储区.
(4)执行程序：当客户端重新连接到网络时，执行程序负责从队列中提取服务请求并执行它们.在服务请求完成后，执行程序会通知服务代理，以便其可以通知客户端.这4个元素之间的关系如图1所示，从图1中可以看出使用面向服务解决方案的组件中所必须包括的功能.
2 基于Web Service的EAMS客户端数据同步策略
2.1 EAMS功能模块设计
根据系统需求分析，EAMS包含了企业资产的前期管理、运行、维修直到报废等整个生命周期的管理，主要包括以下几个功能模块：
(1)设备管理：通过对设备台帐、采购、维修/检修、成本分析等的信息化管理达到如下目标：促进管理科学化；减少设备的故障率；降低设备维修成本；减少故障引起的经济损失；延长设备寿命等.
(2)工单管理：是系统的主线，通过工单的提交、审批和执行来帮助用户管理、计划和监控工作进程与资源调配情况.对于资产的安装、调试、退役和变更、纠正性的维修和计划性的维修以及预测性的维修都是通过工单来体现的.
(3)库存管理：用于建立一套集成的库存和物流管理平台，支持公司备件和材料等所有类型物料的库存管理.库存管理的主要目的在于库存数量账和金额账的管理.
(4)采购管理：用于控制采购流程，管理采购整个过程的各个方面，包括产生申请、批准、供应商选择、采购单发出、发票对照、收货.采购管理模块使用户能获得和跟踪实物资产维护工作需要的材料与服务.
(5)项目管理：主要目标是协调企业的各种资源，实现资金的合理利用、减少成本、增加效益.
图2 总体架构模型
此外，不同企业针对自身的实际情况可以增加或减少使用该EAMS的应用模块，达到既能节约成本，又能高效管理企业资产的需要.当然，在进行功能模块设计时，还应考虑增加其它管理模块，提供系统与其他管理事务的接口，增强系统的兼容性和可扩展性.
2.2 系统架构设计
基于XML与Web Service的数据同步策略是面向服务的，它使得客户端可以与需要的服务进行交互.而且，客户端只需关注服务请求本身，而不需要对本地保存的数据进行直接更改，其总体架构如图2所示.
在这里采用XML文件来缓存客户端进行的数据操作，我们可以将该XML文件看成是在离线工作时记录客户端每一步动作的日志文件，在本策略中将它命名为xmllogger，并通过XSD(xml schema definition)来定义.
用XSD来定义xmllogger文件，而非直接在xmllogger文件中存放SQL语句，可减少客户端系统的存储开销，并且能够更好地利用XML文件的结构性特点，方便在Web服务器上的数据解析与命令执行.
SQL命令经由客户端编码后，通过HTTP协议由SOAP消息将xmllogger传输到业务Web Service服务器，进行相关的后续业务处理.
2.3 业务 Web 服务
由于该架构系统所具有的离线特性，决定了在进行数据同步前，我们必须对其进行相关的业务判断，处理从断开连接到联机状态时发生的并发性问题.例如，我们自定义的COMMANDTIME字段用来记录操作的时间，通过它与数据库已存信息进行比较，对xmllogger文件的某些数据进行必要的逻辑修改.另外必须完成服务队列的监控调用和数据抽取工作.本文通过支持流程监控的WS-Proxy来完成服务队列的监控调用工作，而XML数据抽取则采用基于事件流的SAX来完成[4].WS-Proxy的详细设计如图3所示.
图3 WS-Proxy的详细设计
(1)本地服务目录：用于维护外部Web Service和虚拟服务之间的映射，当一个外部服务导入时，该模块将把其服务地址URI改成WS-Proxy的本地地址，同时将<原URI，本地URI>加入映射表中.此外，本地服务目录还维护一个本地的UDDI组件，用于保存外部服务和生成的虚拟服务的WSDL描述.
(2)WSDL分析器：从本地服务目录的UDDI组件中获取业务流程用到的Web Service的WSDL描述，进而获取服务调用消息所包含的数据元素的详细信息，这样可以得到一张所有输入输出消息所包含的XML元素的列表以及它们在消息中的具体位置(用XPath来描述).
(3)监控计划：负责维护一张监控列表，指明了哪些服务和XML元素需要监控.根据URI和操作名称，WS-Proxy知道需要处理哪些服务，而根据XML元素的名称及其位置，WS-Proxy 可以知道需要抽取哪些元素的内容以及该元素在消息中的位置.
(4)服务代理：是整个WS-Proxy的核心，所有的Web Service消息都由它来转发，同时它也负责对消息进行监控.每当一个服务请求从流程发送到这里，服务代理首先检查监控列表，如果该服务的URI和操作名称处在列表上，那么服务代理就将抽取与该操作关联的XML元素内容，并保存到监控数据的数据库中.然后服务代理查找服务映射表，获得对应的外部Web Service的URI，并转发服务请求至外部服务提供者.
在业务Web Service服务器上所进行的业务处理步骤中非常重要的一步是对XML文档的解析，本文使用JAXP(Java API for Processing)规范包装的SAX来解析XML文档，在文档开始、元素开始、字符数据、元素结束和文档结束5个事件分别对应的回调方法中进行编程处理.其总体架构程序如下：
public class StoreXML extendsDefaultHandler {
private int nid; //当前处理结点的 nid
private int pid; //当前处理结点的 pid
private Stack
public static void store(String uri) {
SAXParserFactory spf =SAXParserFactory.newInstance();
SAXParser sp = spf.newSAXParser();
sp.parse(uri, new StoreXML());}
//为节省篇幅，省略5个回调方法的具体实现，而仅在下文中描述其需实现的功能
}
文档开始方法(startDocument())完成3项功能：置当前结点的nid=0，pid=-1；初始化栈stack将文档结点的nid=0入栈；置下一个结点的nid=1.
元素开始方法(startElement(String uri, String name, AttributeList attrs))完成4项功能：取栈stack的栈顶数据作为当前元素结点的pid；如果当前元素有属性，通过循环依次将每一对属性名和属性值插入到属性表attrs，其nid就是当前元素结点的nid；将当前结点的nid入栈；使nid增1，以获得下一个结点的先序遍历序号.
字符数据方法(characters(char[] ch, int start, int length))首先以字符串的形式获取文本结点中的字符数据，然后截断其前后的空白字符，若截断后该字符串为空，则忽略此文本结点，否则将此文本结点的相关信息保存起来，并使nid增1.
元素结束方法(endElement(String uri, String name))和文档结束方法(endDocument())的主要任务分别是将元素结点的nid和文档结点的nid从栈顶弹出.
解析XML文档后，业务Web service服务器便需要与数据库服务器进行连接，执行具体的操作，最后根据操作返回的结果执行相关的处理.
若出现数据一致性等异常，则终止当前操作，触发并记录异常，然后通过上述xmllogger文件中的CLIENTID(客户端编号)元素值通知相应的客户端；若操作成功，则删除xmllogger缓存，减少资源占有率，达到优化系统的目的.
3 结束语
本文提出的离线问题解决方案的最大优点是在客户端不需要安装本地关系数据库，充分发挥了Web Service架构在系统部署上的优势，较好地解决了EAMS客户端的离线应用问题.另外，本方案将增加了WS-Proxy的扩展型Web Service模型与一种高效的XML数据提取方法相结合，大大提高了Web Service服务器的响应效率.同时利用不需要安装本地关系数据库的优点，可将该方案应用于不同类型的客户端，如PDA、手机等，具有较高的实际应用价值.
参考文献
[1] 景建笃,游晓黔. 安全Web Services体系结构的研究[J]. 计算机工程与设计,2007,28(5):1 232-1 234.
[2] 李 磊,牛春雷,陈宁江,等. 一种高效的Web服务性能优化策略[J]. 计算机研究与发展,2007,44(7):1 191-1 198.
[3] 任兴田,黄小红,马 严.基于Web Services服务管理系统的研究[J]. 计算机工程,2007,33(4):91-93.
[4] 柴晓路,梁宇奇. Web Services技术、架构和应用[M].北京:电子工业出版社,2003.
[5] 邓 芳. XML文档到数据库数据转换研究[J]. 北京邮电大学学报,2004,27(1):84-86.
