首页 理论教育 工作流管理系统的发展与标准化探索

工作流管理系统的发展与标准化探索

时间:2023-10-04 理论教育 版权反馈
【摘要】:在这些早期的工作流系统中只有少数获得了成功。据调查,截至1995年共有200多种软件声称支持工作流管理或者拥有工作流特征。1994年,工作流管理联盟发布了用于工作流管理系统之间互操作的工作流参考模型,并相继制定了一系列工业标准。ROA模式目前主要是基于REST框架,把工作流看做一种资源,通过其定义、发布、搜索和调用机制,实现工作流资源的定义、创建、修改、删除、执行和结果的管理。

工作流管理系统的发展与标准化探索

工作流是业务集成的核心技术,在企业资源管理 (ERP) 和客户关系管理 (CRM)中应用广泛。地学处理工作流是构建地球空间信息服务链的关键,由于它的复杂度、不确定性和智能化的需求,是空间数据共享与互操作的研究热点和难点之一。OGC 第七次测试 (OWS-5) 把地学处理工作流 (GPW) 作为2007—2008年度的主要工作计划; NASA从2006—2009年,开展Sensor Web和地球空间处理工作流的应用前沿技术研究,在2007年南加州森林火灾、非洲洪水、美国中东部龙卷风等重大自然灾害的监测与预警得到了应用; 美国军方开展的EC2008,更是把Sensor Web和地学处理工作流作为多国网络协同作战信息共享的核心技术。目前地学传感器工作流协同服务研究尚处于起步阶段,其核心思想是采用REST服务体系、Web2.0和流程引擎实现跨学科的传感器的资源、数据和服务的协同,提高传感器数据获取和处理的效率

工作流目前普遍接受的定义为: 工作流 (Workflow) 就是工作流程的计算模型,即将工作流程中的工作如何前后组织在一起的逻辑和规则在计算机中以恰当的模型进行表示并对其实施计算。工作流要解决的主要问题是: 为实现某个业务目标,在多个参与者之间,利用计算机,按某种预定规则自动传递文档、信息或者任务。工作流管理系统 (Workflow Management System,Wf MS) 的主要功能是通过计算机技术的支持去定义、执行和管理工作流,协调工作流执行过程中工作之间以及群体成员之间的信息交互。工作流需要依靠工作流管理系统来实现,工作流属于计算机支持协同工作 (Computer Supported Cooperative Work,CSCW) 的一部分。后者是普遍研究一个群体如何在计算机的帮助下实现协同工作的。

工作流技术发端于20世纪70年代中期办公自动化领域的研究工作,但工作流思想的出现还应该更早,1968年Fritz Nordsieck就已经清楚地表达了利用信息技术实现工作流程自动化的想法。20世纪70年代与工作流有关的研究工作包括: 宾夕法尼亚大学沃顿学院的Michael D.Zisman开发的原型系统SCOOP、施乐帕洛阿尔托研究中心的Clarence A.Ellis和Gary J.Nutt等人开发的Office Talk系列试验系统,还有Anatol Holt和Paul Cash-man开发的ARPANET上的“监控软件故障报告”程序。SCOOP、Officetalk和Anatol Holt开发的系统都采用Petri网的某种变体进行流程建模。其中SCOOP和Officetalk系统,不但标志着工作流技术的开始,而且也是最早的办公自动化系统。

20世纪70年代人们对工作流技术充满着强烈乐观情绪,研究者普遍相信新技术可以带来办公效率的巨大改善,然而这种期望最终还是落空了。人们观察到这样一种现象,一个成功的组织往往会在适当的时候创造性的打破标准的办公流程; 而工作流技术的引入使得人们只能死板的遵守固定的流程,最终导致办公效率低和人们对技术的反感。20世纪70年代工作流技术失败的技术原因则包括: 在办公室使用个人计算机尚未被社会接受,网络技术还不普遍,开发者还不了解群件技术的需求与缺陷。

含有工作流特征的商用系统的开发始于1983—1985年间,早期的商用系统主要来自于图像处理领域和电子邮件领域。图像处理许多时候需要流转和跟踪图像,工作流恰好迎合这种需求; 增强的电子邮件系统也采用了工作流的思想,把原来点对点的邮件流转改进为依照某种流程来流转。在这些早期的工作流系统中只有少数获得了成功。

进入1990年代以后,相关的技术条件逐渐成熟,工作流系统的开发与研究进入了一个新的热潮。据调查,截至1995年共有200多种软件声称支持工作流管理或者拥有工作流特征。工作流技术被应用于电讯业、软件工程、制造业、金融业银行业、科学试验、卫生保健领域、航运业和办公自动化领域。

1993年8月,工作流技术标准化的工业组织——工作流管理联盟 (Wf MC) 成立。1994年,工作流管理联盟发布了用于工作流管理系统之间互操作的工作流参考模型,并相继制定了一系列工业标准。

关于工作流技术的学术研究也十分活跃,许多原型系统在实验室里开发出来,人们从工作流模型、体系结构、事务、适应性、异常、安全、语言、形式化、正确性验证、资源管理、开发过程等各方面对工作流技术进行了广泛探讨。

2004年是工作流技术复苏的一年,各种工作流系统涌现出来,有开源的、嵌入式的工作流系统,也有基于B/S结构的商业工作流系统。

网络环境下地学传感器工作流需要实现异地传感器资源、处理模型、数据服务、处理服务和表现服务节点的流程设计、执行、管理和重用,且以服务的模式暴露给用户。目前主要有两种服务体系架构,即基于SOAPFul的SOA模式和RESTFul 的ROA模式。

ROA模式目前主要是基于REST框架,把工作流看做一种资源,通过其定义、发布、搜索和调用机制,实现工作流资源的定义、创建、修改、删除、执行和结果的管理。

REST框架: REST是由Roy Fielding于2003年在论文《Architectural Styles and the Design of Network-based Software Architectures》中提出的一个术语。REST 是英文 Repre-sentational State Transfer的缩写,可翻译为“具象状态传输”(参考: 《SIP/IMS网络中的Representational State Transfer (REST) 和数据分布》)。REST首先只是一种架构样式,不是一种标准。在REST的定义中,一个Web应用总是使用固定的URI向外部世界呈现(或者说暴露) 一个资源。URI是英文Uniform Resource Identifier的缩写,可翻译为“通用资源标志符”,是指唯一标识一个资源 (xhtml文件、图片、css样式表) 的字符串。基于REST的Web服务模式,我们把它称之为面向资源的服务模式 (ROA)。(www.xing528.com)

目前在Web应用中处理来自客户端的请求时,通常只考虑GET和POST这两种HTTP请求方法。实际上,HTTP还有HEAD、PUT、DELETE等请求方法。而在REST架构中,用不同的HTTP请求方法来处理对资源的CRUD (创建、读取、更新和删除) 操作, Head: 获取元信息,POST: 创建,GET: 读取,PUT: 更新和DELETE: 删除。

面向资源的服务体系架构包含了一系列标准协议,主要包含资源定义模式 (原子内容提供模式: Atom Sync Format (ASF))、资源发布协议 (原子发布协议: Atom Pub-lish Protocol,APP) 和资源发现机制 (Web应用描述语言: Web Application Description Language,WADL)。原子内容提供模式主要用于规范资源的描述的XML语言; 原子发布协议是一系列基于HTTP的Web资源创建和更新的协议。

目前支持REST框架的Java实现主要有: Restlet、Cetia4、Apache Axis2、sql REST和REST-art。Restlet最新版本为1.0.1,完全抛弃了Servlet API,自己实现了一套API,能够支持复杂的REST架构设计; Cetia4最新版本为1.0,基于Servlet API开发,可以运行于所有的Web容器中; Axis2最新版本为1.2,同时支持SOAP和REST风格的Web服务;sql REST最新版本为0.3.1,基于Servlet API开发,为任何可以通过JDBC访问的数据库提供Web服务访问接口,自动将REST风格的HTTP请求转换为相应的数据库SQL语句,并将数据库中的记录编码为XML格式传给客户端,是REST风格的HTTP请求到数据库中的数据的直接映射; REST-art最新版本为0.2,旨在替换复杂的SOAP框架的REST框架,用来作为替代SOAP方便地发布Web服务的工具。

表9-1 SOAPFul和RESTFul技术比较

如表9-1所示,目前SOAPFul网络服务的主要缺点是开发起点较高、安全性较低、服务无状态、结果无法管理; RESTFul网络服务的主要特点是资源可以自主创建、删除和更新。目前SOAPFul网络服务的应用范围较为广泛。因此,结合两者的优点,即面向资源的服务工作流体系将成为工作流的发展趋势之一。

使用WPS接口的服务既可以是一个简单服务,也可以是一个复合服务,原则上对使用了WPS接口的实施操作没有任何限制,因而留有充分的发挥空间,提供了服务编制的可能性。因此,可以使用WPS来进行OWS整合,这种方式定义的接口可以隐藏各种处理。

方法一是定义一个复合WPS作为激活其他服务的编制服务。复合WPS激活应用中所有需要涉及的OWS服务。复合WPS可以被看做是一个独立服务。这种方法需要在不同的OWS服务之间传输大量数据。这可以通过直接从其他服务中调用特定服务来避免。这种可能性可以通过HTTP GET方法传输的使用KVP编码的Execute请求的WPS接口而明确实现。根据WPS规范,KVP编码的Excute请求是可选的,但不幸的是,目前还没有对此进行实现的成熟范例。

使用“嵌套式”WPS编码的Execute请求就是基于WPS进行服务编制的第二种方法,即各种OWS服务通过使用WPS接口来进行嵌套,执行时依次调用各种服务。WPS接口是少数支持嵌套链的规范,可以通过KVP编码的Excute请求和在一个被调用服务中调用其他服务的方法来进行描述。

这两种方法体现两种不同的服务链概念,集中式服务链和嵌套式服务链。集中式服务链意味着一个中央WPS服务顺序调用所有其他服务并控制整个工作流。是通用技术目前最广泛支持的方法。嵌套式WPS服务链的请求可能会非常复杂,但其优势也是显而易见的。嵌套方法因为单个服务之间相互通信,因此服务间可以直接交换数据。数据可以直接从处理数据的地方请求而无需进行传输,尤其是有当大量GML编码数据进行传输时,可以增加性能,这样减少了集中式WPS服务链中的数据传输问题。但另一方面,这种嵌套式方法难以跟踪各种被调用服务的输出,当错误发生时,跟踪难以进行。

第三种方法就是把多个WPS功能合并为一个只调用类和每个类各自方法的实现来运行完成的工作流。整体功能暴露为一个独立的WPS处理,但同时,一个单独的构造模块仍然可以作为独立处理从外部获取。该方法的优势在于性能的提高,因为单个服务之间的数据交换不超过一次。其缺点在于不能用其他提供相同功能的实例来替换WPS处理实例,这对于分布式系统而言意义不大。因此,建设只有一个WPS实例用于提供整个场景功能,即时另一个服务提供者可能也开发了不同的WPS实例。在该方法中,不能突出WPS处理。然而现实中WPS处理都基于不同组织的分布式WPS处理。因此,前两种方法更容易替换WPS实例,体现分布式结构的优势,更具有现实意义。

但是,这三种方法都提供了通过WPS接口提供独立OGC服务的可能性。这种整合服务可以称为虚拟服务。它表现了终端用户并不关心OGC服务链的技术实现,而关注管理应用的任务执行。而且,为了与W3C相结合,可以使用WSDL文档来描述领域相关的服务。描述操作文档方法的选择与服务的开发者有关。领域专家偏向于配置文件,而IT用户更偏向于WSDL标准。

免责声明:以上内容源自网络,版权归原作者所有,如有侵犯您的原创版权请告知,我们将尽快删除相关内容。

我要反馈