毕业设计（论文）基于工作流的有状态服务研究与实现

1、第一章 引言第1章 引言近年来，工作流技术在各行各业中的成熟应用，使得企业内部的业务逻辑功能在使用上更为便捷，大大加强了企业的运行效率，同时也推动了工作流技术的成熟。但是，单纯的工作流技术应用只是使得企业的业务逻辑由原来的繁琐的纸质办公成长为了全自动化，在实现技术上，并没有降低开发的难度，每个企业的业务逻辑的不同导致在开发过程中必须为不同的企业开发具有针对性的业务流程，作为以工作流为中心的企业信息系统来说，这无疑是重新开发，因此，单纯的工作流技术并不能提高代码的复用；同时，随着经济的发展，领域型经济正在开始形成规模，这就大大加强了企业与企业之间的联系，这种趋势加强了企业间的业务流程的互联。单纯

2、的工作流技术不能实现企业与企业之间业务流程的互联互通 范玉顺.工作流管理技术基础实现企业业务过程重组，过程管理与过程自动化的核心技术m.北京:清华大学出版社,2000:28-40.。本文论述的基于工作流的有状态服务，来源于模型驱动的面向服务架构集成开发平台的核心部分，通过把工作流技术和soa技术结合实现了无状态的web服务到有状态的流程服务的转换，利用有状态流程服务的形式，实现了服务的可定制性和流程服务与流程服务的交互，满足了企业间业务流程交互的要求，显著增加了机构的机动性，加快新产品，新服务的应用速度，降低it成本，同时提高了运行效率。1.1背景介绍随着我国信息化的不断深入，各类型企业和事业

3、单位都迫切需要能够快速实施的信息化系统平台。 这种平台应能够动态调整，快速适应业务变化。 而且在目前信息社会环境中，分散的、孤立的应用系统渐渐地不能满足互联、互访、协作的经济发展需要，因此平台应能够提供不同单位之间应用系统的通信、信息共享与业务协作的支持。 本文所描述的有状态的流程服务正是基于这样的平台：模型驱动的面向服务架构集成开发平台。有状态的流程服务基于web service和工作流技术在面向服务架构模式下实现的 钱柱中,陆桑璐,谢立；基于petri网的web服务自动组合研究j. 计算机学报 2006年07期.。与过去的分布式计算技术相比，web服务具有自描述性，直接

4、绑定http协议等特征，使得面向服务的计算逐渐成为集成化应用开发的首选 王明文,朱清新,卿利；web服务架构j. 计算机应用研究 2005年03期.2004(11):88-89.。但是web service作为internet上的一种服务协议，是一种无状态的服务，仅仅可以针对服务请求者的单一请求提供快捷有效的服务，但是，在以业务流程为中心业务平台开发过程中，无状态的web服务已经不能满足要求，这也极大的限制了web服务和面向服务架构模式的应用范围。在以业务流程为中心的业务平台开发过程中，整个企业的业务数据在流程的运转过程中始终存在，即便是对于运行长时间的业务流程而言，在业务

5、流程的后续结点中，业务的状态也始终遗传自前序结点。如果把面向服务的架构模式应用到以业务流程为中心的开发中来，必须确保业务流程的状态性。在这种情况下，传统的web服务已经无法满足要求。目前来说，国内外的学者和专家也开始了对于这方面的研究和推广，但是，成效不是很大，难以做到对于业务流程的有状态性和web service无状态性之间的无缝结合。本文论述的基于工作流的有状态服务研究，即是在当前的研究基础上提出的针对业务流程和web service之间的无缝结合方案。本文所研究的有状态流程服务基于吉林省重大科技攻关项目模型驱动的面向服务架构集成开发平台。该课题基于模型驱动技术（model driven

6、architecture，mda）技术和面向服务架构（service oriented architecture， soa）来构建一个快速应用开发和应用集成平台。利用mda技术的优势可以实现快速应用开发，用户可以通过建模的方式构建所需要的应用系统，当业务发生变化时，可以通过修改现有模型实现系统对需求变化的动态适应，利用soa架构实现用户间信息通信，信息共享与应用协作。该平台旨在基于模型驱动技术，构建一个面向服务的分布式软件应用平台。通过该平台，开发人员可以通过业务流程建模，业务数据建模构建企业的业务流程，同时定制符合业务流程的界面管理。在此之后，通过模型转换技术，实现业务流程模型到服务模型的转

7、换，自动将转换后的流程服务部署到集成开发平台中。同时，在业务流程建模过程中，用户也可以通过服务集成平台检索本流程所需要的服务，然后将其集成到流程服务模型中。当然用户自定义的流程服务也可以发布到服务集成平台中供其他用户访问使用。通过该平台，实现了动态适应业务变化，提供了不同企业之间的信息共享和业务协作的支持，极大的推动了企业的信息化平台研究工作。1.2研究内容基于工作流的有状态服务是指利用流程建模技术建立业务流程，利用模型转换技术实现业务流程模型到流程服务模型转换，利用本地服务管理技术实现服务状态的管理，运行时监控，利用消息管理技术实现服务间协同工作。通过流程建模技术，模型转换技术，服务管理和消

8、息管理四大模块的系统工作，实现流程服务集成工作流和web服务的双重优点，方便用户使用，提高了系统间的交互，实现了快速的应用开发，动态的适应业务变化，提高了企业间的访问与交流。有状态的流程服务研究来源于吉林省省长基金项目模型驱动的面向服务架构集成开发平台，该平台包括三个部分：服务开发平台，服务运行平台，服务集成平台。其中，有状态流程服务的研究跨越了服务开发平台，服务运行平台以及服务集成平台这三个部分。在服务开发平台中，以工作流为中心实现业务管理，通过在基于petri网技术的web界面流程建模工具下建立流程模型来实现业务管理逻辑的定制。流程建模之后，通过利用有状态流程服务研究中所提出的模型转换技术

9、，实现流程模型到服务模型的转换，同步生成了流程服务的描述文件，并把转换之后的流程服务部署到服务集成平台以供用户访问。在服务运行平台上，有状态的流程服务研究过程中首先提出了状态管理独立分层的技术，将流程服务的状态管理部分从业务流程和web服务中独立出来，实现状态控制和状态转换的独立性，从而避免了业务流程的有状态特性和web服务的无状态原则之间的冲突。状态管理层利用服务管理器技术实现以服务的方式组织应用服务器上的业务流程，服务管理器定义了业务流程的标准服务接口，并把这些标准化的服务接口利用axis2部署成为服务，以供用户访问。同时由于这些标准的服务接口也代表了现阶段总结出的所有流程服务的状态特性，

10、因此服务管理系统对流程服务全生命周期的管理即是对这些标准服务接口的管理。其次，在研究过程中提出了消息传输机制，消息传输机制用来管理服务之间的通讯，实现服务的交互与协同。在消息传输机制中，提出了流程服务交互所使用的消息编码规则，该消息编码规则包括统一的soap消息格式规则和存储流程服务消息数据的数据存储规则，实现了所有的流程服务的消息数据均可通过一种方式进行数据传输，同时消息转换规则也屏蔽了复杂参数类型对于消息格式的影响。第三，在服务集成平台中，有状态的流程服务研究摒弃了传统的企业服务总线模式的消息分发机制，提出了路由分发功能服务化思想，通过把分发功能服务化，可以在多台服务器上部署该路由服务，用

11、户可以选择转发服务请求的路由器地址，这样，用户的服务请求就可以通过部署到该地址上的路由服务转发到实际的目的地址，减轻了单一的企业服务总线的压力，也降低了应用平台使用上的复杂性，提高了平台的运行效率和运行速度。本文所研究的有状态的流程服务的架构图如下所示：图1.1 模型驱动的面向服务架构集成开发平台系统图本文所研究的有状态的流程服务依据开源的工作流引擎jbpm为基础，结合web service技术，基于面向服务的架构模式主要实现了以下功能：1. 依据业务流程实现业务流程模型到服务模型的转换；包括服务程序的转换，服务描述的转换以及流程描述的转换工作。其中服务程序的转换工作中定义了标准的流程服务接口

12、，并把这些接口部署成为服务，使得所有的流程服务均可以使用这些服务接口管理本流程服务的状态；服务描述文件基于服务程序的转换工作，利用模型实例方式，由唯一的模版产生具有针对性的流程实例的服务描述文件。2. 实现了本地服务的状态管理工作；由部署到每个应用服务器上的服务管理器管理应用服务器上的流程服务以及每个服务实例的生命周期，所有的服务管理器构成了状态管理层。3. 实现了用于服务交互的消息管理系统，提出了消息编码规则与消息转换规则，实现了消息在服务集成平台和服务运行平台之间的数据传输与转换工作。同时与服务管理系统之间进行交互，为服务管理器与外界交互提供了消息接收和消息发送两个接口。4. 实现了路由分

13、发功能服务化技术，服务之间的交互以及用户对于服务的访问请求均可通过该路由服务进行安全可靠的转发。web服务作为新一代的分布式计算模型，由于其松散耦合，语言中立，平台无关，开放性等特征已经成为了电子商务平台模型。一直以来基于工作流的企业信息系统平台模型已经渐趋成熟，但是这种基于业务流程的平台模型也具有构建的复杂性，交互的困难性以及不可重用性。因此，与web服务结合创建高可重用性和动态变化的企业信息系统平台模型成为发展的趋势。但是web服务作为一种松散耦合的分布式计算技术，本身并不支持有状态的服务对象，这与业务流程的有状态特性截然相反。为了解决这一难题，本文提出了基于工作流的有状态服务，在研究过程

14、中，通过状态管理层的提出，不但实现了web服务无状态特性与业务流程有状态特性的结合，同时避免了二者之间的冲突，为新一代的企业信息平台模型创造了基础，提高了企业信息系统平台的重用性，降低了以业务流程为基础的企业应用平台的复杂性；通过消息编码规则和路由服务技术的提出，实现了流程服务级别的交互，为企业间的交流提供了安全可靠的消息传输机制。这些技术的研究与实现，不但从技术的角度为新一代的应用系统平台模型提供了可能性，而且扩大了web service标准的应用范围，为其在更多更广的领域内得到应用提供了思路。1.3本文的组织结构本文的组织结构如下：第一章：引言，介绍了有状态web服务的研究背景，国内外研究

15、现状以及本文的研究内容。第二章：soa和工作流技术介绍，详细介绍了有状态web服务研究的技术背景，包括soa技术和工作流技术，并且结合web service的无状态原则和业务流程的有状态性提出了本文的研究内容。第三章：本地服管理的研究与实现，介绍了流程模型到服务模型的转换过程和状态管理层的研究与实现。第四层：服务交互的研究与实现，介绍了消息编码规则，消息转换规则以及路由服务技术。通过对这些规则的介绍，详细阐述了消息的传输机制。第五章：总结与展望：有状态的web服务的提出在一定程度上违反了web服务的无状态原则，因此本身必然存在着一些漏洞和不足，该章提出了本文的不足和缺陷，指出了有状态web服务

16、的发展前景和研究方向。1.4 本章小结本章首先介绍了基于工作流的有状态服务的研究背景，从业务流程的无状态特性和web服务的有状态原则两个角度阐述了有状态服务产生的原因和背景；其次介绍了有状态服务的研究内容，阐述了本文在研究过程中为实现有状态的流程服务而提出的状态管理层，消息编码规则和路由服务等技术，同时阐述了有状态的流程服务实现对于企业应用系统平台模型和web service标准发展的重大意义；最后介绍了本文的组织结构。5第二章 流程服务背景知识第2章流程服务背景知识本文所研究的有状态的流程服务指的是在soa架构模式下，把业务流程服务化，同时能够管理业务流程的状态特征。在研究过程中，把企业的所

17、有业务流程通过模型转换技术实现其服务化，并部署到相关的服务集成开发平台上，以供他人检索使用。有状态的流程服务基于web service和工作流技术，通过把二者的优势结合起来应用于soa架构模式，实现了一个快速适应业务动态变化的应用平台。2.1.面向服务架构模式目前，面向服务的架构（service oriented architecture，soa）在国内外已经迅速成为技术主流。几乎每一个it公司都有基于soa的解决方案，有支持web service的产品以及符合xml的数据标准。相比于已往的分布式计算技术，web服务具备有自描述、可直接绑定http协议等特征，这使得面向服务的计算逐渐成为松耦合

18、集成化应用开发的首选 w3c web services architecture working group.web services architectureseb/ol.:w3c working group note,2004-2-11.。 面向服务的架构模式是一种与以往不同的软件应用模式，该模式使用以服务为中心的软件设计方式。面向服务的架构模式提高了对业务的响应能力，使企业能够实时支持业务的动态变化，最终使得企业成为服务驱动型企业 岳昆，王晓玲，周傲英；web服务核心支撑技术:研究综述j. 软件学报 2004年03期.。soa本质上是一种面向服务的架构模式，不局限于任

19、何编程语言和编程方法，既是一种软件架构模式又是一种业务架构模式。这种面向服务的体系结构可以用来整合业务流程和支持it基础设施，其通过服务复用和服务组合来解决业务优先级的改变问题。面向服务的架构模式如下图所示：图2.1 面向服务的架构模式图从技术的角度来说，soa是一种软件工程方法，在该方法下，实现了跨平台，跨语言的开发模式。使得开发人员可以独立的开发属于自己的服务，并利用统一的服务发布平台发布出去，以供用户使用 任捷,吴明晖,应晶；web services技术在异构系统集成中的应用研究j计算机应用, 2004,(01).。从业务的角度来说，soa是一组流程，一组业务，一种组织，一种管

20、理，可以使业务驱动的it环境和设施更敏捷，更高效，从而具备更高的竞争优势。soa提供了处理业务流程和it基础结构的灵活性，利用服务复用和服务组合将其处理成为可以被重用和重新组合的其他组件，以解决不断变化的业务优先次序的问题。soa不是一个新的思想，但是随着web服务标准的产生，基于soa的解决方案才更具效率和成果。开放的web服务标准非常重要，因为他们打破了软件程序和供应商之间的私有化屏障。这种新的技术标准使得soa在大范围内实现和使用。2.2.web service介绍 2.2.1web service定义web service本质上是一种利用uri标识的应用程序组件，利用xml标准定义，描

21、述和发现其接口和绑定，通过iternet协议与其他的网络应用程序组件进行交互 谢宝宁,谭庆平；基于web服务的分布式工作流框架a.第一届全国web信息系统及其应用会议(wisa2004)论文集c.武汉:湖北省科学技术协会,2004:278-284.。基础的web service平台是http协议和xml，http协议是最常用互联网协议，xml提供了跨平台跨语言的编程方式。在http和xml的基础之上，web service利用三大元素实现了其透明性，自描述性等特征。首先利用简单对象访问协议(soap：simple object access protocol)进行服务之间的交互与通信。soap

22、是一种基于xml的通信协议，独立于平台与语言，既是一种消息发送的格式，又是一种用于应用程序之间的网络通信协议。web service利用soap协议的特性实现了服务对于客户的访问透明和地址透明 张文斌,陈恩红；基于soap协议实现系统互联j计算机应用, 2002,(05) .。通过soap协议实现了web service之间的协同工作，使得web service的实现脱离了底层的硬件和软件实现，进一步提高了其松散耦合的特性，方便了开发人员的开发和维护。同时也方便了客户的使用，让客户从复杂的业务功能中脱离出来，真正做到所见即所得，所见即所要。其次web service利用we

23、b服务描述语言(wsdl:web service description language)实现其自描述性。wsdl基于xml，用来描述web服务以及访问web服务方式的语言。wsdl本质上说是一个利用xml语言编写的文档，该文档可以用来描述某个具体服务，规定了服务的位置，服务提供的操作方法，以及访问服务的方式等马殿富,葛声,刘旭东；wsdl表示模型与实现方法 北京航空航天大学学报j.2003(10).。通过wsdl语言，web service实现了其自描述性。同时，wsdl语言是用户唯一了解web服务的方式，通过wsdl文档，服务请求者可以了解到所请求的服务的一切信息，并根据该信息

24、访问具体的服务。最后web service通过uddi（universal description, discovery and integration）进行注册发布，以供互联网用户搜索访问。uddi是一种目录服务，其中存储的是由wsdl描述的服务接口目录。从另一个角度来说，web service指的是一种用于建立业务功能提供者和请求者之间松散耦合关系的技术，在这种技术下，web service被划分为三个部分：服务提供者，服务请求者，服务注册中心 官荷卿; 张文博; 魏峻; 黄涛;一种应用敏感的web服务请求调度策略j. 计算机学报 2006年07期，其架构图2.2如下所

25、示：图2.2web service结构图在这种结构下，服务提供者提供的服务通过在一个中间者服务注册中心进行发布，服务请求者通过在该服务注册中心检索合适的服务，如果发现符合条件的服务，则利用发布到服务注册中心服务描述文件实现和服务提供者之间的连接工作，连接建立之后，服务请求者可以请求使用该服务。在这种架构下，由于服务注册中心的存在，服务请求者和服务提供者之间构成了松散耦合的关系，web服务对于服务请求者来说，是地址透明，实现透明的。web service的实现主要依托于一系列开放的标准和协议，下图2.3展示了web服务协议栈：图2.3web服务协议栈2.2.2web服务的无状态性状态指的是某些事

26、务的一般情况，一般是由状态数据表示，状态管理则是如何管理标识状态的数据。过去的技术架构将状态管理的职责在客户端和服务端进行转移，因为web service不仅仅作为一个程序，需要与多个服务请求交互来处理特定的业务，还需要能够具有处理大量客户交互的能力，以支持多个数量的业务任务，另外web service 基于internet协议进行通信，也使得web服务的标准原则之一必须是无状态原则。服务的无状态原则指的是服务本身不保留任何与状态有关的数据，服务请求者提供服务执行所需的全部参数数据，服务只进行业务逻辑处理，把结果返回给请求者。服务本身不保留所处理的数据信息，处理完毕之后马上进入下一个服务请求。

27、两个连续的服务请求之间没有任何联系 张乐伟；基于axis的web服务有状态框架的研究与实现d. 浙江大学, 2006.。服务的无状态原则强调减少以至消除状态管理所带来的系统资源消耗，尽可能的实现对于web服务的可复用性和透明性。该原则主要的目的是为了提高服务的可复用性和重新组合服务来说的。web服务的无状态原则在一定程度上提高了其灵活性和独立性，任何客户可以任意的访问需要的服务，不需要提供任何状态信息，这一原则极大的促进了公共资源服务化的进程，比如公共信息服务，企业结构信息服务等。但是在一些需要提供状态信息和保存状态信息的软件应用程序和业务功能上，很难做到把其中的状态信息集成到web

28、服务中。比如企业的业务流程的服务化就是其中一个典型的例子，web服务的无状态特性和业务流程的有状态特性相冲突，依据传统的服务标准无法提供流程服务，本文就是针对web服务的无状态原则基础上进行研究，提出了把状态管理层作为web服务和业务流程的适配器，使web服务在遵守无状态原则的基础上实现了对业务流程状态的集成功能。2.3工作流技术2.3.1工作流介绍工作流技术是指使用计算机技术实现业务流程的技术,其表示的是业务过程的自动化，其中文档，信息或者任务按照事先定义好的规则，从一个参与角色到另外一个参与角色进行处理，直到整个业务过程的结束。工作流技术让我们从繁琐的业务过程逻辑处理中找出一种统一的解决途

29、径。而工作流管理系统则指的是利用计算机技术定义，执行和管理工作流，协调业务流程执行过程中的任务以及角色之间的关系。在工作流管理系统中，业务流程被抽象成为三个部分：业务处理逻辑，业务交互逻辑和执行者 缪晓阳,石文俊,吴朝晖；工作流过程定义规范j.计算机科学,2000,27(11):53-56.。目前来说，国内的it公司对于工作流的研究主要集中在工作流的实现技术和应用技术两个方面，即支持工作流管理系统的流程引擎和工作流管理系统两个方面。这样的厂商主要有普元eos，oracle中国的ow4j，用友的uap，金蝶bos等等。顾名思义，工作流引擎是用来支撑整个业务流程系统运行的底层基础。工作流管理系统和

30、工作流引擎的关系可以如下图2.4所示：图2.4工作流引擎的位置在开源方面，目前市场是主要有三大主流开源的工作流引擎：jbpm,shark和osworkflow。本文所论述的流程服务的流程模型由jbpm流程引擎驱动执行的。jbpm是一种基于j2ee的轻量级工作流引擎，它在2004年10月发布2.0版本，并加入jboss，成为jboss中间件产品的一个组成部分。jbpm的流程建模模型是基于活动图（activity diagram），并在引擎构建上融入了有限状态机（fsm）和petrinet的思想，本文所使用的jbpm引擎是jbpm3.4版本。目前来说，jbpm已经推出了成熟的jbpm4.4版本。j

31、bpm作为目前最具有竞争力的流程引擎，其自身具备的优点也是本文的研究选择其作为流程建模工具的原因。首先，jbpm引擎的最小依赖特性，使其具有高度的可移植性，它可以很容易作为java库来使用，当然也可以很容易的部署到不同的应用服务器上，例如本文的研究是基于jboss4.4.2服务器，jbpm可以顺利的部署到上面，当然jbpm也可以部署到比如tomcat等应用服务器环境中。同时，jbpm使用hibernate来管理它的数据库，hibernate是目前java领域最成功的持久层解决方案。利用hibernate，jbpm将数据库职能分离出去，只专注于业务流程的驱动工作。同时，还可以支持目前流行的主流关

32、系型数据库。本文所做的研究正是基于jbpm的这些优良特性选择其作为流程模型的建模工具，当然，在jbpm之上，本文在研究过程中也做了大量的改进和优化，比如jbpm的图形化设计器本身只提供了eclipse下的建模工具，而本文在研究过程中则提出了基于web的工作流建模方式，增强了流程建模的独立性，使其在建模过程中不在以来于开发环境，大大提高了流程建模的应用性。2.3.2 业务流程模型的有状态特性与无状态的web服务不同，业务流程模型在整个生命周期中是有状态的。流程模型的本质是一系列相互连接，自动进行的业务活动。流程执行的一个重要功能就是控制过程实例和活动实例的状态转换，实现此功能，必须实现对活动状态

33、所需要的资源和活动状态执行的上下文环境进行控制 姚志林；基于本体的工作流为中心协调工作关键技术的研究d.长春:吉林大学,2008.。，整个业务流程的生命周期中包含启动，运行中，中止，重启动，终止，异常。状态之间的转换过程如下图：图2.3 业务流程生命周期2.4本章小结本章主要论述了有状态web服务研究的出发点和前提背景，包括soa技术，工作流技术，web service等知识。其中着重介绍了web service的无状态原则和流程模型的有状态特性，通过二者的对比，为下文提出的有状态web服务的研究工作做了铺垫。41吉林大学硕士学位论文第3章本地服务管理的研究与实现soa架构在企业中的应用由两个

34、部分组成，一是业务流程化，二是业务服务化。服务的无状态原则和流程的有状态特性是两个不可调和的矛盾，因此必须找一个契合点使二者统一，和谐的组合成一个完整的soa架构模式。在这种前提下，本文基于模型驱动的面向服务架构的集成开发平台，在研究过程中提出了状态管理独立分层的思想，利用独立于每一个应用服务器上的服务管理系统，实现对于流程状态的服务化管理。所谓流程状态的服务化管理指的是，把业务流程的标准状态封装成为web服务，每一个状态对应一个web服务，一个流程服务则是由这些独立的状态服务组成。对于流程服务状态的管理，即是管理这些独立的无状态的web服务。这样，既不违反web服务的无状态原则，同时又实现了

35、业务流程的有状态特性，真正实现了面向服务架构模式中的业务流程和业务服务的统一 b.benatallah,m.dumas,m.fauvet.overview of some patterns for architectingand managing composite web servicesj.acm sigecom exchanges,2002,3(3):9-16.。3.1.服务模型服务是指用户可以远程访问的业务应用，其粒度与日常经济生活中所指的服务一致，从而可以轻易被用户理解与应用，本文所论述有状态的web服务指的是企业应用中的业务流程服务。流程服务的模型要能够全面的描述在信息系统中完成一

36、个业务逻辑处理所需要的全部基础信息，在有状态的流程服务的研究过程中，本文提出了流程服务模型模块化的方式，将流程服务模型中抽象出了业务数据模型，业务对象呈现模型，业务流程模型，业务操作模型四个方面。其关系图如图3.1所示：图3.1服务模型架构图3.1.1业务数据建模业务数据模型用来描述与流程服务相关的业务数据。通过系统的可视化业务数据建模工具，用户可以根据领域知识，把所需的的业务数据在系统中建立模型。从而在通用平台的基础之上，衍生出特定领域的应用，满足不同用户的业务流程的需求。不同领域的数据通过建模的方式集成到系统平台中，成为系统平台业务处理的基础。平台利用内部的通用数据管理框架可以根据模型的定

37、义对业务数据进行统一的维护和管理，包括数据的显示，修改，删除，统计，报表等操作。这些业务数据就是流程服务运行的基础，也就是流程服务实例在运转过程中所需要携带的业务数据。业务数据建模的过程如图3.2所示：图3.2 业务对象建模流程图3.1.2对象呈现建模对象呈现模型用以描述如何在平台中展示和管理业务数据对象。系统可以根据业务数据建模中建立的数据模型自动生成相应的特定领域的数据管理界面，通过该界面可以实现上一节所论述的数据的管理功能。此外，通过可视化的呈现工具定制，实现了支持用户设计业务数据的呈现界面。通过定制，用户可以设定业务数据的呈现布局，数据取值范围，数据校验规则，以及数据之间的逻辑关系等，

38、这些共同构成了对象呈现模型。3.1.3业务流程建模业务流程建模用来定义特定领域的业务逻辑操作过程。业务流程模型是平台中业务处理的依据。在有状态的流程服务研究过程中，在b/s架构下，使用了基于petri网模型的web界面的流程建模技术 james l.peterson,彭澄廉,陈廷槐；petri网j. 计算机工程与应用 1980年05期.。该建模技术兼顾了严格语义和图形语言两个方面，模型的所有元素都是具有严格定义，具有规范的模型语义，并且具有足够丰富的表达能力。并且把该建模工具集成到了模型驱动的面向服务架构集成开发平台中，实现了业务流程建模的热部署，适应了不断发展变化的业务逻

39、辑，极大的增强了该平台的动态适应性 汤宪飞，蒋昌俊，丁志军，王成；基于petri网的语义web服务自动组合方法j. 软件学报 2007年12期.。在业务流程模型中集成了业务数据模型，业务数据模型是业务流程模型的基础。业务数据通过在业务流程中流转处理，实现了企业业务逻辑。企业的业务逻辑正是由业务流程模型构成的框架和业务数据构成的内容组成。业务流程建模过程如下图：图3.3 业务流程建模流程图业务流程建模过程中，通过web下的可视化图形界面创建业务流程模型，包括流程模型的各个结点任务，执行角色，是否是服务结点等。当定义服务结点时，要输入服务的名字和wsdl地址，这样流程服务执行到

40、该结点时，自动根据需要访问的其他服务的地址，请求被访问服务的参数信息，以此来发出服务请求消息。建模完毕得到的流程模型首先利用模型转换技术实现流程模型到服务模型的转换，同时生成流程服务描述文件，部署相关服务信息到服务集成平台中。然后部署流程模型到jbpm流程引擎上，当产生流程实例时，该实例可以在jbpm引擎的驱动下进行流程的运转。3.1.4业务操作建模业务操作建模用来来定义如何在业务处理过程中处理业务对象，本文所基于的项目中，基于自主设计的建模语言实现业务对象的操作模型建模，并对模型实现解释和执行，并呈现到业务流程模型的每个结点中。3.2.模型转换在业务流程模型建立完毕之后，需要把流程模型转换为

41、流程服务模型，并部署到服务集成平台中。其中，业务数据模型和对象呈现模型可以在流程服务模型中实现无缝使用。为此，在有状态的流程服务研究过中提出了模型转换技术，该技术分三个部分实现了业务流程模型到流程服务模型的转换工作，首先服务程序的转换，把标准的服务接口与现有流程绑定，实现业务流程的服务程序生成；其次服务描述的转换，提出了模型实例技术，实现由统一的服务描述文件模版生成具体流程模型的服务描述文件；最后流程描述的转换，在建模的时候，根据业务流程的逻辑过程生成可供jbpm引擎识别的xml流程描述文件。3.2.1服务程序转换服务程序的转换，负责生成业务流程模型服务程序接口。服务程序是指自身的业务流程向外

42、部提供服务的入口程序 叶春杨.基于web服务的流程协作研究d.中国科学院研究生院（软件研究所）,2003,(01).。研究过程中，基于业务流程模型的状态特征以及业务流程可被使用的方式，本文对服务程序的接口进行了统一和标准化。实现了start(),stop(),receoveasy(), getinfo(), querystate(), queryparameter()标准接口来管理流程服务。在这些标准接口中，start，stop接口代表了流程服务生命周期中的启动服务和终止服务两个状态；getinfo接口则与具体的流程服务相关。这些标准的服务接口与具体的流程服务结合后通过流程服务描述文件发布到服

43、务集成平台中，服务请求者可根据这些接口访问流程服务的功能。start()接口用以启动流程服务，通过识别用户请求的流程服务，查找到该流程服务并生成新的流程实例，根据用户需求可以决定是否返回流程实例的唯一标识；stop()接口用来结束一个已经处于运行状态的流程服务实例，返回结果；getinfo()接口是与特定领域的业务知识相关的服务接口，用来得到相关的业务数据；receiveasy()接口用来在服务交互过程中接受异步消息，接收到异步消息后通过对异步消息进行识别，然后初步处理后将其放入消息队列，等待流程服务执行者对消息进行处理；querystate()用来查询当前流程服务所处于的状态，这是流程服务不

44、同于其他web服务，所独有的功能接口，通过该接口，用户可以得到当前流程实例的状态，以便用户做出判断；queryparameter()服务接口不是用来提供给用户使用的，而是在用户启动一个流程服务时，自动调用的一个服务接口，通过该接口，为用户提供使用该流程服务所必须提供的业务数据参数。上述服务接口是本文在研究过程中根据实际需要所做的总结，在此基础上可以扩展实际业务所需要的各种接口，实现与原有服务接口的无缝结合。平台通过采用统一，标准的服务接口使得所有的流程均服务可以通过标准的方式进行访问，降低了流程模型到服务模型转换的复杂性，大大提高了代码的重用性。3.2.2 服务描述的转换流程服务的wsdl文件

45、描述的是封装好的业务功能接口，用户可以通过标准化的消息传输机制访问并使用这些功能。流程服务的有状态特性决定了流程服务的使用跟普通服务的差别。传统意义的无状态web服务描述文件只需要描述一种服务，用户在使用时，只需要根据wsdl的描述访问并使用该服务，得到所需的结果即可。但是在流程服务中，整个业务流程在执行过程中，不仅仅包括服务的执行，还包括了服务状态的转换，服务请求这与服务的交互（一次或者多次），服务本身的异常反馈以及处理机制等，这些特性是所有流程服务都必须具备的特征。因此必须针对这些特性实现统一的流程服务描述文件 欧阳森林,庄毅,苏圣辉,高源晴；基于web service的工作流管理系统的研

46、究与应用j.计算机工程与应用,2006(15):200-203.。由于流程服务具有标准服务接口的特性，使得在研究过程中，本文提出了模型-实例的生成流程服务描述文件的技术。模型-实例指的是定义统一的wsdl描述文件模版，该模版文件描述的是服务程序转换中生成的标准的服务接口的绑定地址以及其他服务访问信息。利用该接口生成有特定领域知识的服务描述文件，特定领域的流程服务描述文件中添加了和该服务相关的信息，包括该服务的绑定地址，服务名称等。转换生成的服务描述文件包括与web service兼容的web服务描述符文件以及本地服务的配置文件。wsdl描述符文件用来说明服务的功能以及访问方法等信息，该文件生成

47、之后，提供到服务集成平台注册。服务配置文件用来保存到本地，指明服务的管理方式。3.2.3流程描述的转换流程描述的转换是以xml形式标识流程定义。在图形化的建模完成之后，以图形表示的流程模型必须转换成可供计算机识别的规范的文本形式，本文所做研究中将图形化的流程模型转换成xml形式的文本数据，并将其保存在服务器中，以供用户使用。3.3.状态管理层有状态的流程服务的核心技术之一是对流程服务全生命周期中的状态管理，因此，在研究过程中，本文提出了状态管理层的概念。状态管理层由部署到每个应用服务器上的服务管理系统组成的，在该层次中每个服务管理器以服务的方式组织应用服务器上的流程服务，每个应用服务器上都有一

48、个服务管理器，用来管理本地的流程服务。同时，服务管理系统和消息管理系统一起，可以实现本地服务与服务之间的交互以及与其他应用服务器上的服务进行交互。服务管理器的功能是运行时管理，控制流程服务的状态。这也是状态管理层的主要功能。3.3.1流程服务的状态有状态的流程服务的生命周期，继承自业务流程的生命周期，其状态也继承自业务流程的状态性，不过在此基础上，添加进了web服务的自描述性，独立性和松散耦合特性。本文基于以上特点，提出了流程服务在整个生命周期中的七大状态：准备状态，启动状态，运行状态，交互状态，中止状态，重启状态和终止状态 龚晓庆.基于web服务的分布式工作流管理系统研究d.西安:西北大学,

49、2004.。在实现有状态的服务时，把整个流程以服务的形式发布，把服务状态以服务功能接口的形式提供给客户，客户可以在服务描述文件中明确的看到有状态服务的各个状态和并可利用我们提供的功能查询服务当前的状态。由于流程服务具有web服务的特性，所以不同于业务流程的状态特性，其中一个表现就在于流程服务的状态的界限模糊性，状态与状态之间没有明确的界限。比如在终止状态下，可能存在交互状态，在运行状态下，也可能存在交互状态。有状态流程服务的状态转换图如下所示：图3.4流程服务状态转换图·准备状态：服务请求者在开始发起服务请求时，流程服务处于准备状态。状态是为第一次访问流程服务的客户或者流程准备的，在

50、客户端第一次访问流程服务时，由于有状态流程服务的描述文件的特殊性，服务请求者无法得到使用流程服务所需要的全部信息。这个时候流程服务进入准备状态，该状态属于自动状态，是由客户端自动启动，自动执行，自动处理返回值，对于服务请求者是透明的，用户并不知道流程服务进入准备状态。该状态下，流程服务为服务调用者准备参数信息并以表单的形式把参数信息呈现给用户，以供服务请求者请求服务时输入。·启动状态：经过准备状态之后，服务请求者根据服务描述文件和服务执行的参数信息提供必须的信息后,开始请求启动流程服务，流程服务进入启动状态，等待流程业务人员推动流程的运转。在这个过程中，服务请求者请求服务的soap消

51、息首先通过网络被传输到路由服务上。服务请求这的请求消息被发送到该路由服务后，通过解析soap消息，得到请求者要访问的流程服务的实际地址，然后将该消息发送到流程服务所在地，服务管理器接受到该消息后，对消息进行解析，对该服务请求以及请求参数进行有效性检查，合法的请求被发往流程引擎，启动业务流程，产生流程实例，使得流程服务进入启动状态，也就是说进入流程实例的开始结点。·运行状态：流程服务启动后，进入运行中状态，该状态下，服务请求者可以通过查询服务查询流程服务所处的节点，以及该节点的消息。·交互状态：本质上说，流程服务的交互状态，是在流程服务在运行过程中与服务请求者之间的交互过程。

52、在交互状态下，流程服务本身会由运行状态暂停，直到交互结束才继续向前执行。该状态应用的范围比较广，可以是服务请求者向服务提供者发送请求状态消息，也可以是服务提供者向服务请求者发送参数更新消息，也可以是确认消息，该状态提供了服务请求者和服务提供者交流的渠道，该状态不是一个特定存在的状态，而是存在于流程服务的其他状态中，交互状态可以和除准备状态之外的任何状态共存。交互状态的这种特性使得服务请求者可以随时监控流程服务运行过程，以便于及时做出调整，并把这种调整直接反馈到流程服务实例上。·中止状态：服务请求者执行中止服务时，流程服务进入中止状态，该状态下，流程服务暂停执行，保存服务执行的会话信息

53、和上下文环境。·重启状态：服务请求者对于处于中止状态的流程服务，可以通过调用重启服务，重新启动流程服务的执行，流程服务根据保存的会话信息和上下文环境，在中止节点开始继续进入运行状态。·终止状态：流程服务执行到结束节点时，自动进入终止状态，该状态下，流程服务需要处理流程执行完毕的会话信息以及向服务调用者发送流程结束确认消息和返回值消息。3.3.2流程服务全生命周期管理对于流程服务生命周期的管理控制本质上说就是对流程服务的七大状态的运行时控制与管理。但是，目前来说，有状态web服务的研究中关于状态管理，一般都是通过web服务提供者自身维护，没有统一的管理。这种方式有两个缺点：首

54、先服务状态由web服务提供者负责，加重了web服务提供者的负担；其次大量的状态信息被保存在web服务进程中，造成服务提供者的资源竞争激烈，系统效率明显下降。基于这些缺点的存在，本文提出了由状态管理独立分层的思想，利用服务管理系统，来管理流程服务的状态，服务管理系统运行于服务运行平台上，管理位于服务开发平台上的流程服务。服务管理系统的主要功能是负责流程服务的定义、转换、发布，并且在运行时管理、控制流程服务的状态，以及状态的转换。而部署在每个应用服务器上的服务管理系统共同组成了平台的状态管理层。服务管理系统定义了访问服务所需要的soap消息结构，所有对于流程服务的访问都通过一个统一的通用的soap

55、结构进行访问，soap里数据信息根据具体的服务状态的不同而不同。服务管理系统既可以作为服务器端，又可以作为客户端，作为服务器端时，服务管理系统负责接受消息，解析消息，执行消息内容；作为客户端时，服务管理系统负责封装消息参数，发送消息。服务管理系统另外一个重要功能是对于流程服务状态的通用性管理，系统提供了一个服务代理，该代理控制，管理流程服务的状态转换。由于流程服务的状态是有限性和固定性，服务代理提供了对于流程服务所有状态的控制，包括启动流程服务，中止流程服务，重启流程服务，发送通知服务，异步消息更新服务，同步参数更新服务，终止服务等。服务代理将这些状态分为两种，同步消息状态请求，异步消息请求。

56、同步消息状态请求包括：启动，终止，中止，重启。异步消息请求包括：通知服务，异步消息更新，同步消息更新等。服务管理系统有一系列相互关联的模块组成，其类图如图3.5所示：图3.5服务管理系统类图在服务管理系统的类的结构图中，采用了命令模式的思想，命令模式的本质是将来自客户端的请求传入一个对象，无需了解这个请求激活的 动作或有关接受这个请求的处理细节。命令模式的优点是解耦了发送者和接受者之间联系。 发送者调用一个操作，接受者接受请求执行相应的动作，因为使用命令模式解耦，发送者无需知道接受者任何接口。在服务管理系统的实现中，采用了解耦命令发送者和执行者的思想，利用srvcontroller接收服务请求

57、者发送的服务请求，然后解析命令类型，根据请求类型，把请求发送到预存在该类中的请求执行对象。这些执行对象可能是startservice，stopservice，breakservice，startagservice中的一个或几个。这些对象得到请求后根据同时传送进来的参数信息执行相应的操作，并反回结果给srvcontroller对象，由该对象处理后续事宜。利用这种方式，进一步封装了底层由业务流程引擎执行的部分，降低了模块与模块之间的耦合性，保证了系统的安全，同时提高了系统的可重用性。3.3.3 服务状态的转换在有状态的流程服务研究中，服务状态之间的转换工作是有一个核心内容，为了实现状态与状态之间的

58、转换，本文在研究过程中为业务流程服务添加了交互状态。服务状态之间的转换工作是基于交互状态的存在。不论流程服务处于何种状态，执行到何种节点，都可以建立服务请求者和服务提供者之间的交互通道，在二者之间进行信息传递，随时变化流程服务的状态。交互状态是一种存在于业务流程的特殊状态，其存在的意义就是使得流程服务可以在不同的状态之间进行转换。通过信息的沟通，服务管理器及时调正流程服务的状态，实现服务状态的转换工作。为了进一步说明服务状态之间的转换工作，下面举例说明如何利用交互状态使得流程服务由一个状态运转到另外一个状态。在开发过程中，曾经定制过一个定制机票和客房的流程服务，该流程服务对外提供定制机票和客房两种服务，而这两种服务分别由两个服务结点来完成。当流程运行到这两个服务结点时，服务管理系统根据绑定在服务结点上的服务名称和服务地址，主动创建服务请求，分别请求机票预定流程服务和客房预定流程服务，由这两个流程服务分别完成机票预定任务和客房预定任务。机票和客房预定流程服务的流程图如下所示：图3.6机票预定流程图在该流程中，当预定机票结点请求执行机票预定流程服务之后，流程服务进入中止状态，等待机票预定流程服务的执行结果，当机票预定服务执行完毕之后根据预定结果会返回