Java SOAP Web services

 

     Java SOAP Web services 管窥

            

摘 要： Web Service可以结构化的呈现信息，甚至是程序内部的讯息.本文系统地阐释了Web Service及其相关技术XML和XSD、SOAP、WSDL、UDDI、RPC及Web Service体系结构及工作流程，分析了Web Service角色、操作、设计栈；分析了Web Service特征；以Codehaus XFire框架为例全程解析了Java SOAP Web services开发；最后分析了Web Service的现状研究及存在的问题。

关键词：Java;SOAP ;Web Service

Abstract：Web Service can be structured presentation of message, or even which in internal programs.This paper explains Web Service and its technology relatively; XML和XSD、SOAP、WSDL、UDDI、RPC and illustrates Web Service architecture、work flow, The different roles associated with the Web services architecture and the programming stack for Web services are described;Then it takes Codehaus XFire as an example illustrateing the development of Java SOAP Web services;Finally it analyses the actual research and subsistent problems.

Key Words：Java;SOAP ;Web Service

一 ，Web services

(一）什么是Web services 

1 Web services是建立可互操作的分布式应用程序的新平台。Web services是一种新的Web应用程序分支，它们是自包含、自描述、模块化的应用，可以在网络(通常为Web)中被描述、发布、查找以及通过Web来调用；Web服务作为一种新兴的Web应用模式，是一种崭新的分布式计算模型，是Web上数据和信息集成的有效机制；Web services便是基于网络的、分布式的模块化组件，它执行特定的任务，遵守具体的技术规范，这些规范使得Web services能与其他兼容的组件进行互操作。它可以使用标准的互联网协议，像超文本传输协议HTTP和XML，将功能体现在互联网和企业内部网上。Web services平台是一套标准，它定义了应用程序如何在Web上实现互操作性。可以用任何语言，在任何平台上写Web services ，可以通过Web services标准对这些服务进行查询和访问。    

2 WebService是实现SOA的一些技术的集合。SOA (service-oriented architecture)是一个组件模型，它将应用程序的不同功能单元（称为服务）通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种这样的系统中的服务可以以一种统一和通用的方式进行交互。

3 WebService采用XML+ HTTP传递数据，目前流行的WebService协议主要有三种：（1）SOAP, SOAP是Microsoft提交给W3C的Web services协议。（3） XML RPC， Microsoft花费了7年的时间成功的把SOAP提交给W3C， 而Dave Winer（RSS之父亲）借鉴SOAP实现了一个更轻量级的协议，那就是XMLRPC。（3) REST ，REST 是Roy Fielding的博士论文中提出的概念，REST是一种Web based软件架构，一种基于Resource State的服务访问架构。

（二）Web services的相关技术Web services平台需要一套协议来实现分布式应用程序的创建。任何平台都有它的数据表示方法和类型系统。要实现互操作性，Web services平台必须提供一套标准的类型系统，用于沟通不同平台、编程语言和组件模型中的不同类型系统。

1、XML和XSD。可扩展的标记语言XML是Web services平台中表示数据的基本格式。除了易于建立和易于分析外，XML主要的优点在于它既与平台无关，又与厂商无关。XML是由万维网协会(W3C)创建，W3C制定的XML SchemaXSD定义了一套标准的数据类型，并给出了一种语言来扩展这套数据类型。Web services平台是用XSD来作为数据类型系统的。当用某种语言如VB.NET或C#来构造一个Web services时，为了符合Web services标准，所有使用的数据类型都必须被转换为XSD类型。如想让它使用在不同平台和不同软件的不同组织间传递，还需要用SOAP协议将它包装起来。

2、SOAP。SOAP即简单对象访问协议(Simple Object Access Protocol)，用于交换XML编码信息的轻量级协议。SOAP有三个主要方面：XML-envelope为描述信息内容和如何处理内容定义了框架，将程序对象编码成为XML对象的规则，执行远程过程调用(RPC)的约定。SOAP可以运行在任何其他传输协议上。如可以使用 SMTP来传递SOAP消息。在传输层之间的头是不同的，但XML有效负载保持相同。Web services 希望实现不同的系统之间能够用“软件-软件对话”的方式相互调用，打破了软件应用、网站和各种设备之间的格格不入的状态，实现“基于Web无缝集成”的目标。

3、WSDL，WSDL即Web services描述语言（Web servicesDescription Language）。WSDL是用机器能阅读的方式提供的一个正式描述文档而基于XML的语言，用于描述Web services及其函数、参数和返回值。基于XML的WSDL既是机器可阅读的，又是人可阅读的。一个WSDL文档将服务定义为一个网络端点或端口（End Point）的集合。在WSDL里，端点及消息的抽象定义与它们具体的网络实现和参数格式绑定是分离的。这样就可以重用这些抽象定义：消息——需要交换数据的抽象描述；端口类型——操作的抽象集合。针对一个特定端口类型的具体协议和数据格式规范构成一个可重用的绑定。一个端口定义成网络地址和可重用绑定的连接，端口的集合定义为服务。一个完整的WSDL在定义网络服务时包含如下的元素：类型，使用某种类型系统（如XSD）定义数据类型；消息，通信数据抽象的带类型的定义；操作：服务所支持动作的抽象描述；端口类型：一个操作的抽象集合，该操作由一个或多个端点支持；绑定：针对一个特定端口类型的具体协议规范和数据格式规范；端口：一个单一的端点，定义成一个绑定和一个网络地址的连接；服务：相关端点的集合。
　  4、UDDI 即统一描述、发现和集成标准（Universal Description, Discovery and Integration）。UDDI 的目的是为电子商务建立标准；UDDI是一套基于Web的、分布式的、为Web services提供的、信息注册中心的实现标准规范，同时也包含一组使企业能将自身提供的Web services注册，以使别的企业能够发现的访问协议的实现标准。UDDI的核心组件是UDDI业务注册，它使用一个XML文档来描述企业及其提供的Web services。UDDI业务注册所提供的信息包含三个部分：白页（White Page），包括地址、联系方法和企业标识；黄页（Yellow page），包括基于标准分类法的行业类别；绿页（Green Page），包括该企业所提供的Web services的技术信息，其形式可能是一些指向文件地址或URL的指示器，而这些文件地址或URL是为服务发现机制服务的。
　　5、远程过程调用RPC与消息传递
　　 Web services本身其实是在实现应用程序间的通信。现在有两种应用程序通信的方法：RPC远程过程调用和消息传递。使用RPC的时候，客户端的概念是调用服务器上的远程过程，通常方式为实例化一个远程对象并调用其方法和属性。RPC系统试图达到一种位置上的透明性：服务器暴露出远程对象的接口，而客户端就好像在本地使用的这些对象的接口一样，这样就隐藏了底层的信息，客户端也不需要知道对象是在哪台机器上。

6、体系结构及工作流程：

Web services的体系结构描述了三个角色（服务提供者、服务请求者和服务中介者）及三个操作（发布、查找和绑定）。服务提供者通过在服务中介者处注册并发布服务，服务请求者通过查找服务中介者发现并定位到服务，服务请求者绑定服务提供者并使用特定的服务。发布服务使用UDDI查找服务使用UDDI和WSDL；而绑定服务使用WSDL和SOAP。

图1  Web services角色、对象和操作（图来源：《Introduction to Webservices architecture》 IBM SYSTEMS JOURNAL, VOL 41, NO 2, 2002）

Web services设计栈是指一组标准化协议和API接口，通过它们可以来查找和使用Web services。网络层是基础，所有Web services在通过网络时必须是可用的。网络通常是基于HTTP协议，也包括其他的网络协议，如IIOP、IBM的MQSeries等。在网络层之上是基于XML的消息层，该层为web服务和它们的客户之间进行通信提供便利。消息层基于SOAP

协议。其上三层对Web services的互操作是必不可少的，Web services流语言(WSFL)促进了 将Web services组合成工作流的进程。竖条表示Web services提供企业级的基础设施，包括安全、管理和服务质量等，实际应用中可扩展。

                       

图2  Web Service设计栈（图来源：《Introduction to Webservices architecture》 IBM SYSTEMS JOURNAL, VOL 41, NO 2, 2002）

（三）           Web Service特征：

1  完好的封装性，Web Service既然是一种部署在Web上的对象，自然具备对象的良好封装性，对于使用者而言，能且仅能看到该对象提供的功能列表。

2松散耦合，这一特征也是源于对象/组件技术，当一个Web Service的实现发生变更的时候，调用者是不会感到这一点的，对于调用者来说，只要Web Service的调用界面不变，Web Service的实现任何变更对他们来说都是透明的，甚至是当Web服务的实现平台从J2EE迁移到了.NET或者是相反的迁移流程，用户都可以对此一无所知。对于松散耦合而言，尤其是在Internet环境下的Web服务而言，需要有一种适合Internet环境的消息交换协议。而XML/SOAP正是目前最为适合的消息交换协议。

3使用协约的规范性，这一特征从对象而来，但相比一般对象其界面规范更加规范化和易于机器理解。首先，作为Web服务，对象界面所提供的功能应当使用标准的描述语言来描述(比如WSDL)；其次，由标准描述语言描述的服务界面应当是能够被发现的，因此这一描述文档需要被存储在私有的或公共的注册库里面。同时，使用标准描述语言描述的使用协约将不仅仅是服务界面，它将被延伸到Web服务的聚合、跨Web服务的事务、工作流等，而这些又都需要服务质量(QoS)的保障。其次，我们知道安全机制对于松散耦合的对象环境的重要性，因此我们需要对诸如授权认证、数据完整性(比如签名机制)、消息源认证以及事务的不可否认性等运用规范的方法来描述、传输和交换。最后，在所有层次的处理都应当是可管理的，因此需要对管理协约运用同样的机制。

5使用标准协议规范，作为Web Service，其所有公共的协约完全需要使用开放的标准协议进行描述、传输和交换。这些标准协议具有完全免费的规范，以便由任意方进行实现。一般而言，绝大多数规范将最终有W3C或OASIS作为最终版本的发布方和维护方。

6高度可集成能力。由于Web Service务采取简单的、易理解的标准Web协议作为组件界面描述和协同描述规范，完全屏蔽了不同软件平台的差异，无论是CORBA、DCOM还是EJB都可以通过这一种标准的协议进行互操作，实现了在当前环境下最高的可集成性。

(四) SOAP框架
             1、Apache Axis.Axis  是Apache的一种Java SOAP框架，目前版本已是2.0。Apache Axis 是Apache WebService项目中的子项目，其最初起源于IBM的"SOAP4J"，应该属于最早的一批用于构造基于SOAP应用的Framework。 目前Apache Axis已经发展到了第三代，其核心是一个SOAP处理器，用于开发包括客户端，服务器端，SOAP Gateway等各种应用。事实上Apache Axis在了1.0版后，其发行版本还包括了完整的J2EE服务器插件, WSDL支持和生成，TCP/IP监视器等组件，从这个意义上来说Apahce Axis已不仅仅是个SOAP框架了，它包含了除了UDDI外对整个Web services协议栈(Protocol Stack)的支持。官方主页： http://ws.apache.org/axis/ 。

2、Codehaus XFire ， Xfire 是一个获得MIT许可的下一代Java SOAP框架。XFire是与Axis 2并列的新一代WebService框架。具有如下：支持一系列Web services的新标准--JSR181、WSDL2.0 、JAXB2、WS-Security等 ; 使用Stax解释XML,性能有了质的提高。XFire采用Woodstox 作Stax实现; Easily Create Services from POJOs; 易于与Spring框架结合; 灵活的Binding机制包括,默认的Aegis,xmlbeans,jaxb2,castor.官方主页：http://xfire.codehaus.org/ 。

3、 SOA .net ，SOA .net是微软的SOAP框架。官方主页：http://msdn.microsoft.com/architecture/soa/，还有Indigo（Windows Communication Foundation ）框架。

二，在Spring中使用XFire开发Web services

XFire是Web services开发者的首选框架，XFire对Spring提供了强大的支持，可以在Spring中使用XFire实施Web services。XFire可以通过多种方式将Spring容器中的Bean导出为Web services，这包括使用XFireExporter导出器或JSR 181注解。JSR 181和STAX一起都将融入到JDK 6.0中， JSR 181 Web services定义方式将成为标准的实现。XFire为客户端提供了多种访问Web services的方式，可以采用获取的窄接口类调用Web services，也可以采用动态反射机制调用Web services。XFire为Eclipse提供了一个可以根据WSDL生成客户端存根代码的插件，XFire也将为其他非Java语言提供类似的插件.WS-Security是专门为解决Web services应用安全而制定的规范。XFire通过注册一系列的InHandler和OutHandler对接收和发送的SOAP报文进行安全处理，Web services的业务逻辑对WS-Security是透明的。

1，XFire 体系及重要API：ServiceFactory是XFire的核心类，它可以将一个POJO生成为一个Web services；还有Handler类，Handler可以看成是XFire的一个加工套件，XFire通过它们定义SOAP发送和接收之前的各种加工处理逻辑。Handler可以注册到Service或Transport（代表SOAP输入输出的传输对象）中，在服务请求和响应管道里，Service和Transport注册的Handler将执行额外的处理操作。XFire是完全基于流数据处理进行工作的系统，这意味着XFire不是将整个SOAP文档缓存在内存中，而是以管道的方式接收SOAP流数据。XFire从管道中接收一个SOAP请求到返回一个SOAP响应，会经历一系列的阶段。在管道调用的任何一个阶段，XFire都可以添加一些额外的Handler，在对消息进行加工处理后再传到下一个阶段进行处理。

2，将POJO Bean导出为Web services：通过XFire为Spring提供的服务导出器可以轻松地将POJO导出为标准的Web services，此外，XFire还允许我们使用JSR 181注解对POJO进行标注，无须使用XML配置就可以导出为Web services。XFire为Spring提供了方便易用的导出器XFireExporter，借助XFireExporter的支持，我们可以在Spring容器中将一个POJO导出为Web services。另外，使用JSR 181注解导出Web services，用户只需要在业务类和窄接口标注JSR 181注解，不管有多少需要导出为Web services的业务类，只需要在Spring中配置一个XFire提供的JSR 181注解增强Bean就可以了。注解增强处理器会对Spring容器中所有标注JSR 181注解的业务类进行处理，并分别将它们导出为Web services。使用JSR 181时，必须将XFire的依赖类库xfire-jsr181-api-1.0-M1.jar添加到类路径中。

配置：通过HTTP作为Web services的传输协议，用户只需要启动一个Web服务器（如Tomcat），客户端就可以通过HTTP访问到Web services服务了。为了集成Spring容器，XFire专门提供了一个XFireSpringServlet，可以在web.xml中配置该Servlet。

3，访问：XFire为访问服务端Web services提供了各种方便的方式，在可以获取服务端窄接口类的情况下，可以根据服务地址和窄接口类创建客户调用程序。如果不能获得服务窄接口类，XFire允许用户通过WSDL文件生成客户端调用程序，通过指定服务接口的方式调用服务。鉴于这种调用方式不够面向对象，XFire提供了一个根据WSDL生成客户端存根代码的工具，这样用户就可以方便以面向对象的方式编写客户端程序了。另外，XFire允许仅通过Web services对应的WSDL文件构造客户端访问程序。这无疑给创建客户端程序带来了极大的便利性，用户可以直接通过URL指定WSDL，也可以将WSDL保存在本地系统中，通过InputStream的方式获取WSDL内容。

4，测试：XFire通过AbstractXFireTest极大地简化了Web services的测试。AbstractXFireTest允许我们无须构造客户端调用程序，在SOAP报文层面开展对服务端代码的测试，AbstractXFireTest提供了一系列方便的方法对SOAP报文进行验证。XFire还特别为Spring环境下进行Web services测试提供了一个AbstractXFireSpringTest子类，仅通过启用Spring容器就可以完成Web services的测试。通过XFire精心设计的测试工具类，对Web services的测试工作便成为一项可以轻松应对的工作。另外，保证客户端和服务端的Web services都位于同一JVM中，xfire提供不启动Web服务器的情况下通过客户端程序测试Web services的功能。

5，安全：Web services是分布式的应用，SOAP报文可能在不安全的传输层传输，应用安全受到极大的挑战。WS-Security是专门为解决Web services应用安全而制定的规范。XFire通过Apache的WSS4J对WS-Security提供支持，XFire完整发布包中包含了WSS4J的类包。XFire在发送和接收SOAP报文前拥有多个阶段，每个阶段都可以注册Handler，对SOAP报文进行前置和后置处理的加工操作。XFire即通过Handler实施WSS4J，当发送SOAP报文时，通过注册一系列OutHandler，对SOAP报文进行加密、签名、添加用户身份信息等后置处理操作。而在接收SOAP报文时，则通过注册一系列的InHandler对SOAP进行解密、验证签名，用户身份认证等前置操作。请求和响应的SOAP在发送之前可以通过注册的OutHanlder进行加工处理，让SOAP转换为WS-Security的保护格式。而服务端和客户端在接收SOAP 报文之前，可以通过注册的InHandler，将WS-Security格式的SOAP转换为正常的SOAP进行处理。由于XFire在SOAP收发过程中定义了多个不同的生命阶段，所以可以在发送前和接收前完成SOAP报文安全处理的工作，这些操作完全独立于业务处理逻辑，实施WS-Security对于Web services的业务操作是透明的。

图3  XFire应用WS-Security的方案

（图来源：《精通Spring 2.x：企业应用开发详解》电子工业出版社, 陈雄华）

（1）准备工作：在使用XFire的WS-Security之前，准备性的工作安装Java策略文件、安装SecurityProvider、创建密钥对和数字证书。策略文件被JDK使用，用以控制加密的强度和算法。策略文件包括local_policy.jar和US_export_policy.jar文件。WSS4J使用了BouncyCastle的SecurityProvider，所以需要事先在java.security文件中进行配置。签名和加密需要使用到数字证书和密钥对，可以使用JDK提供的KeyTool工具创建密钥对和数字证书。

 (2) 使用用户名/密码进行身份认证，对SOAP报文进行身份认证是通过在SOAP报文头中添加一些安全凭证（Security Token）信息来完成的. 主要包括以下一些身份凭证：用户名/密码、X.509证书、Kerberos票据和认证者、SIM卡的移动设备安全性凭证。

（3）对SOAP报文进行数字签名，数字签名可以解决保证报文在传输过程中没有被篡改，保证交易的完整性和不可抵赖性。客户端通过私钥对SOAP报文进行数字签名，由于私钥只为个人拥有，因此不可抵赖性得到了保证。数字签名其实是使用私钥对报文的摘要进行加密，只有报文在传输过程中不被篡改，接收端在进行数字签名验证时才可能成功，因此完整性又得到了保证。

（4）对SOAP报文体进行加密，通过对SOAP报文体进行加密，即可解决保密性的问题。客户端使用服务端的公钥对请求SOAP报文进行加密，服务端公钥包含在服务端的数字证书中。clientStore.jks中服务端数字证书的别名为server，访问服务端数字证书不需要密码。服务端需要使用私钥进行解密，服务端私钥包含在服务端的密钥对中，在serverStore.jks中服务端密钥对的别名为server，访问私钥的密码为serverpass。在XFire中对SOAP报文体进行加密解密需要解决的主要问题就是注册相应的Handler，并为其提供相应的访问密钥信息。

（5）组合安全策略，实际应用中把以上三种单一安全策略机制组合的安全策略。从请求和服务的角度上看，Web services的交互两端分为客户端和服务端，但在实施安全策略时两者是对等的。即请求SOAP一方使用WS-Security，注册并配置OutHandler，另一方则相应地注册并配置InHandler。

三 Java SOAP Web services未来发展和挑战

1 SOAP 和 WSDL 。

SOAP+WSDL 快速崛起的同时仍存在很多问题成功。第一个方面就是互操作性，实际应用中它的互操作性承诺进展并不明显。这是由于对 rpc/encoded 样式的 Web 服务（也称为 rpc/enc）的强调所造成的，对象模型将序列化为 XML 然后再在接收端重新构造。此自动序列化/反序列化功能使得 rpc/enc 非常易用却导致生成无法用于任何目的的 XML。另外，语言和平台支持的差异导致了实现之间大量的不兼容现象。目前 Web 服务实践正倾向于使用doc/lit样式 (document/literal) 替代 rpc/enc 样式。 doc/lit 中的XML 消息格式是由 W3C XML Schema 定义所定义的。理论上讲这能消除互操作性方面的任何问题，因为模式实例定义 XML 的实际结构，而每个平台负责恰当地处理该 XML。实际中极为复杂的 W3C Schema 标准的支持程度参差不齐会带来另外一些互操作性问题。另外转向 doc/lit 的部分原因是希望能利用企业或行业标准模式。但这些标准模式的设计通常没有考虑会在 Web 服务中使用，它们会使SOAP 框架不能提供良好支持的特性。SOAP Web services的另一个问题是基础结构扩展和基本 SOAP 处理——添加的可在一系列 Web 服务上应用的处理层——之间不断的混淆不清。SOAP 的设计运行方便地添加此类扩展，但这些扩展通常仅在其为受多个框架支持的标准时才有用。这要求整个行业进行协作，但通常很难办到。即使最基础的扩展（如附件和安全性），也需要若干年进行开发，但仍然不受所有框架支持。

2         Indigo

Indigo即Windows Communication Foundation (WCF)框架，由于Microsoft 台式机系统占有率的绝对优势，这个来自Java 技术的竞争对手:Microsoft® .NET的新框架对Java SOAP Web services有巨大的挑战。通过 WCF，Microsoft 将向基本 .NET 平台添加XOP/MTOM、WS-Addressing、WS-Trust、WS-SecureConversation、WS-ReliableMessaging、WS-Coordination、WS-AtomicTransaction 和 WS-Policy等新技术，整个行业的方向无疑是将 WCF 技术作为下一代 SOAP 框架的核心部分加以支持。

3         Apache 方法

Apache 当前的 Java SOAP Web 服务生产平台是第三代 Axis 框架。Axis是使用最广泛的 Java SOAP Web 服务平台。Axis 的缺点：首先，它是基于 JAX-RPC 1.0 标准设计的，这在很大程度上约束了 Axis 体系结构，限制了其灵活性。同时，转向 doc/lit SOAP 服务也带来了对更好模式支持的需求，但这对 Axis 代码而言是非常不实际的。Axis2设计为轻量 SOAP 处理引擎，可以采用很多方式进行扩展。Axis2 并不刻意对实现任何特定 API 进行约束。Axis2的特性之一就是为 SOAP 消息使用的 AXIOM 对象模型。AXIOM利用新的 XML 解析器提供的灵活性来允许按需构造对象模型。这意味着，只有为实际需要通过模型访问的 XML 文档部分构建对象模型才会带来性能损失。另一个主要 Axis2 特性是对可插入数据绑定的支持,此特性允许选择最简单的方式来处理 SOAP 文档的 XML 有效载荷，对生成的代码进行自定义，以使用所选择的方法。可能的选择包括，直接使用 AXIOM，使用与原来的 Axis 相似的简单数据绑定方法，或使用 XMLBeans、JiBX 或 JAXB 2.0 等专用数据绑定框架。

 

    四，系统的数学模型分析：

    马尔科夫链的高效性：

在该系统中，设客户端访问是参数为λ的最简单流，客户端访问的时间间隔相互独立同分布，各客户端访问的服务时间，Y1Y₂，L之间独立同分布且： ，b(s)为L-S变换，并且与输入之间相互独立。当服务器服务完一个客户端，若发现系统中没有客户端连接时，服务器停止服务。当服务器停止服务结束时，若发现系统中有客户端连接等待，则立即开始服务，一直工作到另一次没有客户端连接，进行另一次服务停止。服务停止长度V为一随机变量且 ，-V（Ｓ）为L-S变换，进一步设t=0时刻服务器中无客户端连接，服务器不停止服务，而是等待第一个客户端的连接　，当第一个客户端连接服务器，则立即开始服务。并且设当服务器处于停止服务时，到达的客户端以P（0<P<1）连接服务器进行等待，以1-p的概率离开而连接服务器。一个完整的服务包括多次服务器停止服务，即V_G=V₁+V₂+…+V_j，J是一随机变量，它不仅与有关，而且依赖于到达过程，令表示假期内到达的第一个客户端的时刻，则有：

        令D_n（t）表示服务器对第n个客户端的服务时间，令 ，易得：

式中 为第一个在休假期内到达顾客的等待时间；S为第一个顾客的服务时间；其分布函数为B（t），由于在休假期内到达顾客数服从参数 泊松流，所以与 无关，令 。设第一个顾客的等待时间为w(t)，其L-S变换为-w(s)，则对于Re(s)≥0，有： .该系统是高效的。

 

 

 

 

 

 

附件：河北省法人库信息服务系统，系统信息映射部分采用Web services完成。

参考文献：

[1] FreemanA，JonesA．．NET XML Web服务程序设计[M]．北京：清华大学出版社，2003：3—15．

[2] Kao J．构建基于XML的web服务开发者指南[S／OL] 2001．http：//geeclub.sun.com.cn/ staticcontent/html／j2ee／J2EEWebserciesDev.html

[3] Ferrara A，Maclnald M．．NET Web服务编程[M]．北京：清华大学出版社，2003：32—66．

[4] 刘 洋，魏 飞．精通JBOSS-EJB与Web Services开发精解[M]北京：电子工业出版社，2004：300—330．

 [5] 张颖峰，李毓麟，基于进化算法的网格计算资源管理调度系统[J]．计算机工程，2003，29(15)：110—175．

 [6] K. Gottschalk　S. Graham　H. Kreger　J. Snell．《Introduction to Webservices architecture》 IBM SYSTEMS JOURNAL, VOL 41, NO 2, 2002．

[7] 《精通Spring 2.x：企业应用开发详解》电子工业出版社, 陈雄华

[8] The document Web Services Conceptual Architecture, http://www.ibm.com/software/solutions/webservices/

documentation.html.