GSFL:一种网格服务的工作流架构 (zt,英文文档有了，这里保存下中文的)_cnfee的博客-程序员秘密

技术标签：文档活动网格网络工作工作流引擎

http://www.caip.rutgers.edu/~zhljenny/workflow_bib.htm

作者Blog： http://blog.csdn.net/dbmining/ 谢谢作者了，在这里冒昧转贴保存了

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引擎执行中的一些问题。

5 执行细节

我们选择OGSI Technology Preview[22]作为GSFL原型发展的基础。这是目前网格服务规范[29]利用Apache Tomcat [23]和Apache Axis [24]基于java的应用。Tomcat是servlet容器，用于办公相关应用中的Java Servlet [26] and JavaServer Pages [25]技术。Axis是W3C中简单对象访问协议（SOAP）[1]的一个应用。在下面小节中，我们给出一些GSFL应用的重要部分。

5.1 GSFL剖析

我们用Castor[4]分析GSFL schema，并产生java绑定。Castor是一个java的开放资源数据绑定架构，产生java类源并以XML schema展现。它也提供方法配置XML文档与相应的java对象相一致，反之亦然。使用Castor能为我们的XML schema自动产生java绑定，以避免编写代码。这大大减少了开发代码的时间。

尽管Castor能将GSFL schema映射成java类，但它还无法理解与组件相关的语义，如Castor不知道GSFL schema中的Import类型有足够的信息（namespace和location）将另一个GSFL文档导入。它只能使用适当的获得和安装方法将如Import的类型映射为具有namespace和location字段的java类。因此，我们不得不为Castor产生的类增加封装以解决此问题。但是这要比自己写代码好得多。

5.2 自动产生WSDL

除了使用Castor，我们还可以用WSDLAJ[8]处理个人服务的WSDL文档。WSDLAJ是一种可以创建、展现和操作WSDL文档的工具包。

正如我们在第4节中介绍的，GSFL文档包含有关输出活动的足够信息。既然WSDL能参与工作流，那就很容易找出输入输出信息的Types及Messages自身。WSDL的其他信息如Operations、Ports等能轻易地从GSFL自身获得。为工作流自动产生WSDL的关键是提供GSFL schema的足够信息。

5.3 GSFL 协调者（Coordinator）

GSFL Workflow的核心是GSFL Coordinator服务。这个服务创建虚拟端口和服务器，它们将内部进程映射到工作流。这些端口是虚拟的，因为它们在GSFL Coordinator中并不物理存在。尽管如此，客户能通过这些端口调用方法，因为它们映射到GSFL Coordinator一个别的调用的集合上。

图5展示了常用控制流。一个希望执行GSFL工作流的客户，先以GSFL实例开始（通过标准OGSA厂商方法）。然后协调者（Coordinator）实例被送到表示工作流的GSFL。在GSFL文档收据之上，协调者实例动态产生WSDL文档，包括所有新输出的操作。然后WSDL能就能被想执行工作流和动态输出操作的客户们使用了。当一个客户调用一个GSFL Coordinator输出的操作时，请求通过servlet容器发送到OGSA webapp（网络应用程序）。OGSA webapp利用服务器上的映射config.wsdd发送GSFLProvider/Intercepter调用，这已作为标准OGSA RPCURIProvider类的一个扩展在应用。OGSA RPCURIProvider类负责根据请求的URL，将引入的请求分配到正确的服务实例。既然操作并不物理存在于GSFL Coordinator上，如果这个标准提供者已被使用，调用将会失败。但是，自定义提供者可以中断这个调用，并发送到协调者中的一个通用的配置功能。基于GSFL文档提供的信息，协调者处理请求，将操作映射到一个调用集。这些调用实际由参与工作流的服务执行。

提供者能区分调用是在动态的还是在静态端口执行。感兴趣的静态操作之一是generateWSDL。包括动态端口，它自动为协调者产生WSDL（5.2节）

6 GSFL的例子

考虑以下下面的情形，为了达到一个共同目标，网格服务间需要相互通信。概念方面的描述在第4节定义过了，这在可读性上强于XML。图6描述了个人服务间的交互。

6.1 服务提供者

服务提供者由一个工作队列服务、一个资源管理服务和一个执行服务集组成。工作队列服务负责为用户要执行的工作排队；资源管理服务负责为网格上的各种资源预存信息及为执行工作的目标资源制定只能决策；执行服务集运行在每个各人机器上并负责工作的执行及向资源管理服务报告资源信息。

6.2活动模型

活动模型由工作队列服务的排队（Queue）操作、出队列（Dequeue）操作、获取资源（GetResource）操作和执行工作（ExecuteJob）操作组成。队列操作负责为工作请求排队，工作需求信息要以合适的格式提供；出队列操作从队列中获得一个工作，取决于队列规则；资源管理服务中的获取资源操作使用出队列工作信息获得执行特定工作的最好资源；执行服务中的执行工作操作负责工作的执行

6.3 组合模型

组合模型内的输出模型由一个输出的操作Execute组成。它由控制和数据模型一致的模型组成。同属这两个模型的操作有Dequeue、GetResource和Execute-Job。因此当客户调用工作流实例上的Execute操作时，工作流引擎从工作队列服务中获得下一个工作然后将工作信息通过GetResource调用传递给资源管理服务。GetResource调用返回目标资源以使工作继续运行。使用这个调用上的信息及ExecuteJob操作，工作得以在原定的资源上执行。

此外，每一个执行服务（Execution Services）通过使用异步周期通告向资源管理服务发送soft-state资源信息。这就是资源管理服务如何拥有每一个资源信息的方法。它跟据这些信息为工作决定最好的目标资源。Notification Links的集合组成了通告模型（Notification Model），它们将执行服务连接到资源管理服务。

6.4生命周期模型

在这个例子中，我们要求所有的服务都同时是活动的，所以我们不需要利用生命周期模型提供的所有特性。

因此，为了创建更复杂并且需要比每个个人服务更多值的组合服务，我们发现可以使用GSFL使个人服务（Job Queue Service、Resource Manager Service和Execution Services）协同工作。

7未来的工作

网格服务流语言在应用和增强方面还可能有广阔的空间。这还是一个发展工作，这种语言将继续根据网格方面的需求来改进。未来的特性中将包含处理加工异常的特性，和XLANG中的相似；，增强的工作流中任务排序功能，其中可能会用到循环和选择结构；自动集成图形化工作流编辑器。

8结论

我们在本文中描述了网格服务流语言（GSFL），一种基于网格服务的工作流架构。我们概览了现有的处理网络服务工作流的技术并研究了他们在网格服务中的应用。现有的网络服务技术提供了一些很好的可以利用的特性，尽管还无法解决某些需求，如对等服务交互和在服务中应用生命周期管理。我们设计了GSFL来处理这些问题，而且还集成了现有的网络服务技术的特性。

参考文献：

[1] Condor : High Throughput Computing. http://www.cs.wisc.edu/condor/, 2002.

[2] DAGMan (Directed Acyclic Graph Manager). http://www.cs.wisc.edu/condor/dagman/, 2002.

[3] Assaf Arkin. Business Process Modelling Language. http://www.bpmi.org/bmpi-downloads/BPML-SPEC-

1.0.zip, June 2002.

[4] Assaf Arkin, Sid Askary, Scott Fordin, Wolfgang Jekeli, Kohsuke Kawaguchi, David Orchard, Stefano Pogliani,

Karsten Riemer, Susan Struble, Pal Takacsi-Nagy, Ivana Trickovic, and Sinisa Zimek. Web Services Choreography

Interface. http://wwws.sun.com/software/xml/developers/wsci/index.html, June 2002. Version 1.0.

[5] R. Armstrong, D. Gannon, A. Geist, K. Keahey, S. Kohn, L. McInnes, S. Parker, and B. Smolinski. Toward a

Common Component Architecture for High-Performance Parallel Computing. In Proceedings of High Performance

Distributed Computing, pages 115–124, Redondo Beach, California, 1999. CCA Forum, .

[6] T. Berners-Lee, R. Fielding, and L. Masinter. Uniform Resource Identifiers (URI): Generic Syntax.

http://www.ietf.org/rfc/rfc2396.txt, August 1998.

[7] Don Box, David Ehnebuske, Gopal Kakivaya, Andrew Layman, Noah Mendelsohn, Henrik Frystyk Nielsen,

Satish Thatte, and Dave Winer. Simple Object Access Protocol (SOAP) 1.1. http://www.w3.org/TR/SOAP, May

2000.

[8] Roberto Chinnici, Martin Gudgin, Jean-Jacques Moreau, and Sanjiva Weerawarana. Web Services Description

Language Version 1.2. http://www.w3.org/TR/2002/WD-wsdl12-20020709/, July 2002. W3C Working Draft 9.

[9] Erik Christensen, Francisco Curbera, Greg Meredith, and Sanjiva Weerawarana. Web Services Description Language.

http://www.w3.org/TR/wsdl, March 2001. Revision 1.1 - March 15, 2002.

[10] Francisco Curbera, Yaron Goland, Yohannes Klein, Frank Leymann, Dieter Roller, and Sanjiva Weerawarana.

Business Process Execution Language for Web Services. http://www.ibm.com/developerworks/library/ws-bpel/.

Version 1.0 - July 31, 2002.

[11] Distributed Systems Department Pervasive Collaborative Computing Environment Project (PCCE), LBL. PCCE

Quarterly Reports. http://www-itg.lbl.gov/Collaboratories/quarterly-reports.html, April 2002.

[12] David C. Fallside. XML Schema Part 0: Primer. http://www.w3.org/TR/xmlschema-0/, May 2001.

[13] I. Foster and C. Kesselman, editors. The Grid: Blueprint for a Future Computing Infrastructure. Morgan

Kaufmann Publishers, July 1998.

[14] Ian Foster, Carl Kesselman, Jeffrey Nick, and Steven Tuecke. The Physiology of the Grid: An Open Grid Services

Architecture for Distributed Systems Integration. http://www.globus.org/research/papers/ogsa.pdf, January 2002.

[15] Ian Foster, Carl Kesselman, and Steve Tuecke. The Anatomy of the Grid: Enabling Scalable Virtual Organizations.

International Journal of Supercomputing Applications, 15(3), 2002.

[16] Dennis Gannon, Rachana Ananthakrishnan, Sriram Krishnan, Madhusudhan Govindaraju, Lavanya

Ramakrishnan, and Aleksander Slominski. Grid Web Services and Application Factories.

http://www.extreme.indiana.edu/xcat/AppFactory.pdf, June 2002.

[17] The Globus Project. http://www.globus.org/, June 2002.

[18] Steve Graham, Simeon Simeonov, Toufic Boubez, Doug Davis, Glen Daniels, Yuichi Nakamura, and Ryo

Neyama. Building Web Services With Java. SAMS, 2002.

[19] IBM. The Web Services Description Language for Java Toolkit (WSDL4J). http://www-

124.ibm.com/developerworks/projects/wsdl4j, July 2002.

[20] Frank Leymann.Web Services Flow Language. http://www-4.ibm.com/software/solutions/webservices/pdf/WSFL.pdf,

May 2001.

[21] OGSI Technology Preview Release. http://www.globus.org/ogsa/releases/TechPreview/, June 2002.

[22] Apache Jakarta Project. Apache Tomcat. http://jakarta.apache.org/tomcat/, June 2002.

[23] Apache XML Project. Apache Axis. http://xml.apache.org/axis/, June 2002.

[24] Sun Microsystems Inc. Java Server Pages. http://java.sun.com/products/jsp, 2002.

[25] Sun Microsystems Inc. Java Servlet Technology. http://java.sun.com/products/servlet/index.html, 2002.

[26] Satish Thatte. XLANG: Web services for Business Process Design.

http://www.gotdotnet.com/team/xml wsspecs/xlang-c/default.htm, 2001.

[27] The Hewlett-Packard Company. Web Services Conversation Language (WSCL) 1.0.

http://www.w3.org/TR/wscl10/, March 2002.

[28] Steven Tuecke, Karl Czajkowski, Ian Foster, Jeffrey Frey, Steve Graham, and Carl Kesselman. Grid Service

Specification (Draft 2). http://www.gridforum.org/ogsi-wg/drafts/GS Spec draft02 2002-06-13.pdf, June 2002.

[29] UDDI Technical White Paper. http://www-3.ibm.com/services/uddi/pubs/Iru UDDI Technical White Paper.pdf,

September 2000. Universal Description, Discovery and Integration is for discovering web services.

[30] Keith Visco and Assaf Arkin. Castor. http://castor.exolab.org/, 2002.

[31] World Wide Web Consortium. http://www.w3.org/, June 2002.