使用GT4实现基于WSRF的Web服务

摘要：状态在网格计算中是一个重要的概念，WSRF的出现为网格应用系统的状态管理问题提供了标准的方法，而GT4则完全实现了WSRF。本文介绍了Web服务、状态和WSRF，以及他们之间的关系。介绍了GT4平台和WSRF核心：WS-Resource。通过相关的实例，探讨了利用GT4实现基于WSRF的Web服务的过程。

关键词：Web服务；状态；WSRF；GT4

中图分类号：TP393文献标识码：A文章编号：1009-3044(2007)16-30975-02

Developing WSRF-based Web Service Using GT4

DING Xiao-hui,GAO Shu

(Department of Computer,WuHan University of Technology,Wuhan 430063,China)

Abstract:State is an important concept in Grid Computing.The appearance of WSRF provides the state management for grid application systems with a standard method. And GT4 has completely implemented the WSRF specifications. This paper introduces Web Service, state and WSRF, and the relationship among them. Then,it introduces GT4 and the core of WSRF: WS-Resource. By means of the case study,the paper finally discusseshow to use GT4 to developWSRF-based Web Service.

Key words: Web Service; state; WSRF; GT4

1 Web服务、状态和WSRF[1][2]

1.1Web服务与状态

今天，Web Service的发展已经到了很成熟的阶段。我们已经从这项技术中获得了很大的利益。长期进行Web技术工作的人员会发现，不论何时和如何处理HTTP，实际上我们面对的都是一个无状态的协议，发送一个请求得到一个响应，仅此而已。服务器并不知道你的某个请求是你发出的第几个请求，即使是人为的将一系列请求组成一个序列，需要按照顺序进行处理，服务器对此也一无所知。我们可以通过在 HTTP 协议结合其他工具来响应用程序中加入状态信息，从而实现有状态的Web服务。由此看来，我们说HTTP的无状态性很糟糕是不过分的，因为，每个需要使用状态信息的人都要在应用程序中加入其他功能，而这些功能原本是可以在内部处理的。显然这样就存在以下一些问题了：第一，每个人的处理状态的方式是不同的。第二，对应用程序而言，不存在什么简单的方法可以用来发现其他应用程序正在做的事情。另外一个很重要的方面，就是由于服务有状态，这就意味着在进行任何操作之前必须花费很多的代价，同时在Web服务失败时，由于记忆了之前的交互，要重新启动服务是非常困难的。因此，这种使得Web服务具有状态的方法受到很多质疑，在Web服务社区中，服务通常被认为是无状态的。这似乎是件很矛盾的事情，状态对我们如此重要，然而，到底该怎么实现呢？随着网格服务的出现，这样的问题就很好的解决了。

1.2WSRF与状态

OGSI作为OGSA的核心规范已经有三年了，OGSI设计的目的在于提供一个标准的方式通过WEB服务接口来管理状态。这在网格计算中是一个重要的必不可少的条件，然而在实践当中，很多人在Web服务领域中发现OGSI与现在主流Web服务思想过于独立，与现代流行的WEB服务技术存在着许多矛盾，这也被认为是OGSI的一个明显的不足，正是因为这点不足，WEB服务资源框架WSRF的提出似乎也成了必然的事情。WSRF的提出帮助解决了这种局面下存在的问题，它的核心观念就是Web服务资源（WS-Resource）。Web服务资源可以定义为一个实体，该实体在反复调用过程中将维持一些状态，同时可以通过Web服务来访问这些实体，因此，Web服务资源也被定义为Web服务与有状态资源的组合。Web 服务资源框架（WS-Resource framework）通过约定的 Web 服务机制来声明、创建、访问、监测改变和销毁Web 服务资源，同时又不要求 Web 服务资源的 Web 服务组件作为有状态资源处理器来实现。

Web 服务资源框架（WSRF）由六种 Web 服务规范组成，它们通过定义“Web 服务资源法”，在 Web 服务的上下文中实现对状态的建模和管理。这种方法的内容包括：

(1)在已经建立起来的 Web 服务标准上下文中发现和观察状态资源，并与之交互的能力。

尽管 Web 服务提供了 UDDI、WSDL和其他一些基于 XML 的工具，用它们来发送、接收和处理消息，甚至还可以用它们来回传递状态信息，但它没有为那些需要理解相互状态信息的系统提供一种标准的可互操作的方法。而正是WSRF的提出实现了这一点，处理了Web服务的上下文。

(2)将服务和作用于该服务的状态资源的分离。

在 Web 或网格服务中，任何关于状态的讨论都会引发一些问题，就如上文所描述的，我们很多人都不能接受在某个服务中设置状态所付出的代价和带来的限制，觉得在 Web 服务标准中引入这些累赘极大地伤害了现有的成百上千的 Web 服务。WSRF的出现就改变了这种局面，有了WSRF我们不需要将状态直接嵌入Web 服务中，只要保持 Web 服务接口的无状态性，同时使之与独立的状态资源交互。用这种方式，Web 服务就可以重新启动，并重新与提供状态信息的外部组件连接。同时，WSRF允许Web 服务提取出状态信息，并对齐进行修改，而不必考虑用何种资源（如：XML文档等）来保存这些状态信息。状态信息被惟一标识，并插入到服务使用的消息流中，这与来回传递的 XML 构造文档中的其他部分是一样的。

1.3Web服务与WSRF

WSRF的目的就是使得资源成为Web服务框架下的有状态的资源。WSRF使用了不同的结构来模型化有状态资源和相应的Web 服务，允许Web服务和任何相关联的有状态资源之间可以形成多对多的映射。从这里，我们可以看出，正是WSRF的提出促进了网格与Web服务的融合。

2 Globus Toolkits 4实现WSRF

2.1GT4简介

2005年4月Globus联盟正式了Globus Toolkits 4.0（GT4），较之以前的版本，GT4的最大特征在于实现了WSRF和WS-Notification标准。Globus Toolkits 4的体系结构中主要包括资源调度组件、安全管理工具、信息服务工具、数据管理组件，并支持Java Web服务的开发部署。

2.2GT4与WSRF的关系

在网格服务体系结构中有4个主要角色:OGSA, WSRF,GT4, Web服务。它们之间的关系如图1所示：

图1 OGSA,WSRF,GT4,Web服务四者之间的关系

2.3GT4实现基于WSRF的Web服务

有了GT4，我们可以发现，开发一个基于WSRF的Web服务并不想我们想象的那么困难了。我们只需遵循以下5个步骤：

(1)定义服务接口（用WSDL来完成）。

(2)实现服务。（用JAVA来完成）

(3)定义参数（用WSDD和JNDI来实现）

(4)编译已完成的部分并产生GAR文件（利用ANT实现）

(5)服务（用GT4工具来实现）

以下我们将以一个简单的Web 服务（我们把它称为ProvisionDirService）为例子来说明这5个步骤的具体实现。ProvisionDirService可以向远程的网格客户机展现本地文件系统的目录层次结构。（采用一个服务或一组服务向网格提供文件系统数据对于现有的很多网格基础设施产品来说都是一个非常常见的特性。）它还可以允许您显示当前工作目录中的内容，并切换当前工作目录。在本例中，惟一的资源是一个 Java 类，它保存了当前工作目录资源属性的信息，并返回该目录中的文件/目录清单。

第一步：定义服务接口

我们有两种方法来定义服务接口：一是用JAVA编写，然后生成WSDL portType接口描述文件，二是自己直接编写WSDL portType接口描述文件。在这个例子中如果用JAVA来编写，那就成了很简单的事情，如下所示：

public interface ProvisionDir

{

public void listDir();

public void changeCwd();

}

相比用WSDL来定义接口，这种方法容易产生很多问题，所以最佳选择是直接用WSDL来定义，由于篇幅有限，我们只列出部分代码，与编写普通的web服务接口不同，编写WSRF有态web服务接口需要定义用于保存状态信息的资源属性:使用portType元素的wsrp:ResourceProperties属性指定服务的资源属性。如:

......

......

......

第二步：实现服务和资源

(1)定义QName接口：当客户必须引用与这个服务相关的所有事物时，需要使用qualifiednames（QNames )，它包含了一个namespace和局部名称。一个Qnames在Java中使用Qname类来进行描述。本例中定义了一个叫ProvisionDirQName.java的类：

public interface ProvisionDirQNames {

......

public static final QName RESOURCE_PROPERTIES = new QName(NS,"ProvisionDirResourceProperties");

......

}

(2)实现无状态的Web服务： 这个例子中，我们的服务很简单，它就是一个简单的JAVA类，叫做ProvisionDirService.java,这个类实现了服务和资源。最终我们得到ProvisionDirService.java的部分代码如下：

public class ProvisionDirService implements Resource, ResourceProperties {

......

public ProvisionDirService(){}//初始化资源属性

......

public String getCwd() {}

public void setCwd(String cwd) {} //获取和设置资源属性

......

}

第三步：定义参数

这里我们使用Web服务部署描述器（WSDD）来编写服务部署描述文件。WSDD文件告诉Web服务容器应该怎样我们的Web服务（例如：告诉它我们的服务的URI是什么）。这已经是我们很熟悉的内容了，在这里不再累述。

第四步：利用ANT生成GAR文件

完成以上三步后，我们就有了用WSDL描述的服务接口、用JAVA实现的服务和WSDD描述的部署文件，使用ANT产生GAR文件，这和我们通常的做法是一样的。而在GT4中，提供了globus-build-service这一工具，它是Globus Service Build Tools (GSBT) 项目的一部分，通过它我们可以生成脚本和构建文件，它允许我们花最小的工夫来生成GAR文件。在这个示例中我们才用下面的简单语句来生成GAR文件：

./globus-build-service.sh -d -s

第五步：服务

第四步中生成的GAR文件中包含了Web服务器Web服务所需所有的文件和信息。我们使用下面的命令来服务：

globus-deploy-gar D:\org_globus_examples_services_core_first.gar

同样我们有取消的命令：

globus-undeploy-gar org_globus_examples_services_core_first

这样，通过这五个必要的步骤，可以说我们就基本实现了一个基于WSRF的Web服务。

接下来我们就可以编写自己的客户端来测试已经好的Web服务了。编写一个叫Client.java类，它是一个简单的命令行类，它对我们的网格服务执行一组简单的操作。启动服务器端容器程序：

Globus-start-container-nosec,之后我们就可以对Web服务资源进行访问

java org.globus.cxamplcs.clients. ProvisionDir_ instancc.Client

127.0.0.1:8080/wsrf/services/myex/ProvisionDirService

3 结束语

Web服务是无状态的实体，而实践中，客户和服务器之间的互操作往往需要维护、存取和管理状态，传统的做法使得Web服务具有了状态属性，而这并不是我们想要的。WSRF的规范定义了有状态资源，实现了对有状态资源的管理。GT4实现了WSRF，通过引入WSRF，使我们可以很方便的申明和实现Web服务和一个或多个有状态资源之间的关联。在开发网格应用的过程中，GT4已经成为首选。

参考文献：

[1]孙炜,任长明,朱江,吴艳玮.基于Web SERVICE的网格资源架构WSRF.微机处理,2005年2月.

[2]刘挺.WSRF规范以及基于WSRF的GT4的资源管理系统分析.中国科技信息,2006年11月.

[3]Ian Foster,Jeffrey Frey,et al. Modeling Stateful Resources with Web Services,Version 1.1 2005,05,03.

[4]Borja Sotomayor.The Globus Toolkit 4 Programmer's Tutorial.2005.

注：本文中所涉及到的图表、注解、公式等内容请以PDF格式阅读原文。