GSFL:一种网格服务的工作流架构（一）
Sriram Krishnan12, Patrick Wagstrom13, Gregor von Laszewski1
1Mathematics and Computer Science Division, Argonne National Laboratory, Argonne, IL 60439
2Indiana University, Bloomington, IN, 47405
3Illinois Institute of Technology, Chicago, IL, 60616
摘要：开放网格服务体系（OGSA）力图使用网格和web服务领域的概念和技术来解决由于通过在分布式异构动态虚拟组织上集成服务而带来的挑战。web服务领域已意识到web服务的潜力已达到了极限，除非存在一种新的机制能描述服务间的各种交互作用并能动态地将已存在的服务组成新的服务。这在网格服务中也是如此。本文分析了现有的处理web服务工作流的技术，并努力将它们应用于网格服务，以满足其对标准web服务的不同需求。我们讨论了这些特殊需求并介绍了能在OSGA架构内解决它们的网格服务流语言(GSFL)。
关键字：Grid; OGSA; OGSI; Grid Services; Web Services; Workflow
1引言
网络服务方法在工业中迅速获得动力。W3C[9]将网络服务定义为通过URI[13]标识的软件应用。URI的界面和绑定（bindings）可被XML artifacts定义、描述和发现。后者使用基于internet协议的XML消息支持同其他软件应用的直接交互。更多的全面的描述性的定义可参看[20]，它将网络服务定义为一个平台，一个执行独立软件的组件：
l 可以用服务描述语言来描述；
l 向一个服务注册处发布；
l 可通过标准机制检测到；
l 利用声明的API函数调用，一般通过网络；
l 由其它服务组成。
网络服务的目标是实现协同工作能力。这要求请求者能通过使用标准机制访问网络服务。理想情况下，任何请求者都能与任何声明为网络服务的应用进行交互，而不需考虑它们使用的语言和环境。这使得网络服务方法对现代企业和内组织计算系统有着吸引力。
网格计算包含动态分布式虚拟组织[18]中的各种资源。网格技术是基础，支持对不同资源的共享和协调。目前它[16]正受到科学计算领域的广泛应用。网格技术除了要解决处理资源所固有的问题，如算法和问题解决技术、资源管理、安全、仪器和技术性能分析、网络设施等等，还要解决网络服务引起的问题，诸如描述、发现、交流、远程调用等。最近，随着开放网格服务体系（OGSA）[17]发展，这些情况已引起了网格领域的注意。
OGSA是Globus Toolkit发展的结果。Globus Toolkit已成为网格计算的事实标准。OSGA使用网络服务描述语言（WSDL）[14]实现自描述和可发现服务。WSDL定义了一个网格服务输出的标准界面集，能实现如发现、服务查找、生存时间管理、通知和信任书管理等特性。尽管如此，和网络服务技术相似，网格服务潜力也会达到极限，除非存在一种机制能动态地从已存在的服务体系中组成新的服务。为了此目的，我们不但要描述这些服务和其方法执行的顺序，而且需要寻求一种途径能使这样的体系将自身作为服务输出。在本文里，我们将“工作流”这一术语定义为一规则集，这些规则定义了服务集之间的交互作用以使其组成元服务。
本文介绍了网络服务工作流语言的现状以及网络服务如何和网格服务联系的，指出了这些语言在网格方面的缺点。为解决这些问题，我们还详细介绍了网格服务流语言（GSFL）和它带来的研究问题以及解决方案。
2技术概观
最近，网络服务的流语言领域已显现活力。主要的网络服务软件供应商已提出各种方法作为标准。由于这个领域的高速发展，我们不可能对所有现存的技术进行调查，只能集中在一些大的项目上。
2.1网络服务流语言（WSFL）
WSFL[21]由IBM提出，是网络服务工作流的方法之一。WSFL使用一种流模型（flowModel）和统一模型（globalModel）来描述网络服务的组成。流模型定义了一系列活动表现复合网络服务的运作，并确定活动执行的顺序。它分别使用controlLink和datalink定义各种活动之间的控制和数据流。大多数情况下，数据流会紧随控制流。但是，WSFL很灵活能处理可能不正确的案例。
统一模型（globalModel）定义了复合网络服务的活动是如何使用plugLinks将其映射到个人网络服务（individual Web services）的操作的。WSFL用locator识别工作流中的服务，支持下列绑定：
l static，提供WSDL或WSFL定义的参考；
l local,服务执行是本地的；
l uddi,使用UDDI [2] API可查出服务执行；
l mobility,服务提供者会在由一些活动产生的消息中提及；
l any,服务提供者不受流模型的限制。
WSFL也支持复合网络服务的流模型（flowModel）的生命周期操作。它支持诸如 spawn, call (一种阻塞spawn), suspend, resume, enquire和terminate。WSFL的优点是与WSDL的逻辑一致性和定义网络服务的能力。网络服务往往由其他网络服务递归组成。
IBM在2001年五月公布了WSFL1.0版本。但此后就没多大改进。尽管似乎有些工作组也在致力于推出可行的WSFL[15]，但还没有出现流行的应用。
2.2 XLANG: Web Services for Business Process Design
微软公司提出的XLANG[27]，是一种用于将业务流程模式转化为自主代理的语言。在WSDL中动作的单元是一个操作，这个操作能够应用在无状态服务(stateless service，如栈引用)上或在有用的有状态服务上（stateful service，交互定义了流程的开始和结束）。
存在第三种模型，业务进程可能是自主代理如供应链。在这个链中，输入和输出消息作为服务进程以特定的顺序发生。自连接和同步基于π-微积分（π-calculus）理论。
XLANG定义了下列操作集作为标准WSDL操作的扩充以辅助此模型：
l delays，使得一个线程延迟一定周期或直到满足其他条件。
l raise，对特定动作引发异常的方法。
l process，结合条件和迭代语句控制联合动作。
l correlation，提供了声明更长的运行会话的方法。
l transaction support，定义了回滚过程，当执行失败时发生。
l contracts创建块服务，利用端口间 one way bindings。
像许多技术一样，XLANG也正在发展。目前，它还缺少将服务动态加入业务流程的方法也还缺乏一种机制将这些服务作为工作流的一部分输出。这将在它未来的版本中实现。尽管如此，自从2001年5月公布以来，介绍XLANG的资料还是很少。
2.3 Web Services Conversation Language (WSCL)
WSCL[28]是Hewlett-Packard公司提出的一种会话语言架构，为一个界面的交互和操作的先后顺序建立模型。它弥补了界面定义语言间的鸿沟。界面定义语言没有说明任何choreography和更复杂的流程或流语言。流语言描述了复杂的统一多方会话和流程。WSCL规范的主要组成如下：
l 文件类型描述，涉及能被服务接受和传播的文件的类型，用XML Schemas定义[3]；
l 交互描述，为两个参与者之间的会话动作建立模型；
l 转换描述，说明交互之间的顺序关系；
l 会话描述，列出了所有组成会话的交互和转换。
会话是服务支持的公共界面。同样通过说明操作的可能顺序将语义学引入WSCL中，用于服务。但是，WSCL并不解决网络服务的递归问题，而这恰恰是我们对网格服务的目标。
2.4 其他相关工作
The Web Services Choreography Interface (WSCI) [11]由Sun, Intalio, SAP and BEA提出，希望实现比XLANG内聚性更强的应用级的集成。但是，WSCI是2002年6月提出的，在写本文时还属于非常新的。业务流程建模语言（BPML）[10]是一种为业务流程建模的元语言。BPML为协同事务性业务流程提供了一个虚拟执行模型，这基于一个叫做事务有限状态机的概念。DAGMan[6]是一种Condor[5]元调度程序，管理工作的依赖性。尽管DAGMan并不处理网络服务工作流，但用有向非循环图来表示输入输出和执行是内聚的程序集方法，能够描述网络服务的依赖性。The XCAT Application Factories [19]用基于通用组件体系（CCA）[12]架构的组件来解决工作流问题。XCAT允许组件相互动态连接，使得建立应用成为可能，而这在标准网络服务模型中是不可能的。
3 网格工作流的需求
经以上调查和对网格使用案例的分析，我们建立了网格工作流规范的需求集。这部分我们将展示这些需求及现存网络服务技术如何无法处理全部的需求，也提供了一些再次使用的无用技术。
正如网络服务技术所希望达到的，网格工作流规范应允许特殊活动作为工作流活动的输出应用于个人服务，也应能使输出的活动触发其他活动链。目前像WSFL的技术能有效地解决这个问题。因此，我们努力将WSFL的这些特性引入网格服务流语言。另外，以这种方式输出的活动也应像服务自身一样以相同的方式来描述。从这个意义上而言，规范应足以描述工作流，如规范应能自动为工作流实体（后面称为工作流协调者）产生WSDL。工作流协调者必须能运用作为各种工作流活动的动态输出的方法。这样，客户才能使用相同的处理个人服务的工具来访问他们。这是对服务的递归成分的重要需求。
正如我们观察到的和[19]中指出的，现有的网络服务定义他们的工作流时，工作流引擎必须在应用序列的每一步介入（如图1）。这是因为目前的工作流技术都是为业务对业务通讯而设计的，通过网络服务只能达到中等数据传输水平。结果，工作流引擎并不是因为真正的瓶颈中断的。然而，交换大量数据在基于网格的服务中是常事。使用中心工作流引擎在服务器间转发数据不是明智之举。工作流规范应能允许服务器间进行通讯（如图2）。像前面提到的，为满足网格的特殊需求，OGSA对WSDL进行了扩展，使用notificationSources 和notificationSinks解决网格服务器间的通讯，它们允许相互间的异步消息传输。这要求GSFL提供连接notificationSources 和notificationSinks的机制以避免工作流引擎介入每一步。此外，OGSA使用Registries和Factories分别查找和创建网格服务，这是GSFL应具备的。
（图2）
工作流中特定的网格服务不能执行是可以的，这可能是由于那些提前执行的服务要运行数周或那些稍后执行的服务需要前者的数据。网格服务流规范应能满足这种特殊需求。另外，也应能够解决在每一个方法或工作流实例上的个人网格服务的实例化。由于网格服务是在每一个工作流实例基础上实例化的，工作流输出的某些活动可能由于某一网格服务没运行完或还没实例化而无法运行。因此，WSCL建议应将特定语义加入输出活动的顺序中。
在下一节，我们描述网格服务流语言及如何解决列出的需求。
4 GSFL 综述
网格服务流语言基于XML，支持在OGSA架构下的网格服务的工作流描述规范。它使用XML Schemas定义。图3显示了简化的体系结构。下面是一些重要特点，随后会对其进行扩展：
l Service Providers，服务提供者，参与工作流的服务；
l Activity Model，活动模型，描述工作流中重要的活动；
l Composition Model，组合模型，描述个人服务间的交互作用；
l Lifecycle Model，生命周期模型，描述参与工作流的各种活动和服务的生命周期。
4.1 服务提供者（Service Providers）
参与工作流的所有服务器必须在Service Providers中声明。GSFL文档通过唯一的名字来识别服务提供者，这是定义的一部分。定义也包括服务提供者的类型，就如WSDL规范说明的网格服务类型。服务器提供者能通过查找元件以一系列方式找到。服务能通过静态URL查找。URL能指出正运行的服务。也可使用factories创建，这是GSFL文档中的句柄。使用registries也能找到服务。
4.2活动模型（Activity Model）
Activity Model列出了个人服务提供者的所有操作。提供者在工作流中扮演各种角色。Activity Model包含了活动的清单，每个活动都有名字和来源。名字用于识别，来源是网络服务的一个操作的参考，操作由endPointType定义。endPointType包括操作的名字，特定操作的端口类型、端口名字和服务名。
4.3组合模型（Composition Model）
Composition Model描述了不同的网格服务器是如何组成新的网格服务器的。它描述了服务操作之间的控制流和数据流，以及它们间的对等通讯。它包括下列部分：
4.3.1 输出模型（Export Model）
Export Model包括以工作流进程的操作输出的活动的清单。任何客户都能使用标准机制调用这些工作流实例上的操作。既然工作流实例能被看作一个标准网格服务，那么它也能递归的用于另一个工作流进程。对每一个输出的活动，控制流和数据流分别用ControlModel和DataModel表示。
ControlModel描述了当输出活动被客户调用时所调用的活动序列。每一个ControlModel元素都有属性controlIn，它涉及当输出活动被调用时将执行的第一个活动。同时每个ControlModel也含有一个controlLink的序列，作为输出活动的一部分。它是一个需要成功调用的所有活动的优先列表。
dataModel描述了输出活动被调用时产生的数据流。这个数据流可能并没有必要反映各种活动间的控制流。每个dataModel元素含有一个属性dataInto(图3中为“Data In”)。这个属性说明了将接收作为输出活动的输入数据的活动。dataOutFrom属性（在图中为“Data Out”）指派了数据的来源活动，这些数据被返回给调用者。
GSFL文件为dataModel和ControlModel提供足够的信息，这不仅为输出活动动态建立WSDL，而且支持动态调用。我们在第5节解释。
4.3.2 通知模型（Notification Model）
Notification Model解决了工作流引擎要在活动的每一步介入的问题。正如前面提到的，OGSA服务使用notificationSources和notificationSinks相互交流。Notification Model提供了一种从sources到sinks的双向链接机制，这是一个独特的议题，需使用notification Links。目前服务器可以相互传输大量的数据而不必通过工作流引擎。用户还能使用控制模型和数据模型在相互间传输控制消息和少量数据，但传输大量数据时还是推荐使用notification messages。
图4显示了Composition Model的一个简单例子。两个服务A和B组成了工作流。这个Notification Model由单独的notification link A ! B组成，表示从A到B的链接。输出模型由一对输出活动组成，其中一个在图中详细描述。它由服务A的操作P和R及服务B的操作Q执行。控制模型由控制链接P ! Q 和Q ! R组成。操作P是输出活动的controlIn。数据模型只由一个单独的数据链接P ! Q组成。这可能因为操作R不需要调用数据。这是一个数据链接并不像控制链接一样必须的例子。操作P作为dataInTo,Q则作为dataOutFrom。因此，输出活动的调用将伴随控制和数据流触发上述的操作集。
4.4 生命周期模型（Lifecycle Model）
Lifecycle Model处理服务和活动执行的顺序。服务生命周期模型serviceLifecycleModel包含描述服务执行顺序的优先链列表。因此，不是所有的服务都需要在开始时初始化，可以在前面的服务停止执行后再开始。
生命周期模型使用工作流的scope属性，可以是一个session或application。session表示对工作流引擎的调用之间是无状态的。所有的调用都是合法的。为每个调用，服务使用serviceLifecycleModel进行实例化，当调用时这些服务处于活动状态。
application表示调用状态将在服务流引擎中保存。对每个工作流实例，服务只使用serviceLifecycleModel实例化一次。由于执行这些活动的服务可能不是活动的，因此对工作流引擎的调用并不是所有都有效。所以，我们增加一个activityLifecycleModel来描述它们调用的顺序。换句话说，有些活动仅当某些特定的活动已成功调用时才能被调用，如在网上购物系统的checkout操作必须在一个或多个buy操作后才能调用。按照activityLifecycleModel可保证当按照适当的顺序调用时，所有的服务都会是活动的。
我们相信使用上述设计，我们能解决网格服务工作流的需求。现在，要讨论在GSFL引擎执行中的一些问题。
