Web Service

什么是Web Service

你可能早就听说过Web service了，你也可能已经对Web service有一些概念了。一时间，好像所有的计算机期刊、书籍和网站都开始提及Web service。然而，当前大多数对Web service的介绍都没能清楚的说明Web service到底是什么。他们只是鼓吹Web service是多么多么的好，简直就像是在做广告。在本文中会讲清楚两件事：Web service到底是什么；在什么情况下你应该使用Web service。

分布式应用程序和浏览器
研究一下当前的应用程序开发，你会发现一个绝对的倾向：人们开始偏爱基于浏览器的瘦客户应用程序。这当然不是因为瘦客户能够提供更好的用户界面，而是因为 它能够避免花在桌面应用程序发布上的高成本。发布桌面应用程序成本很高，一半是因为应用程序安装和配置的问题，另一半是因为客户和服务器之间通信的问题。
传统的Windows富客户应用程序使用DCOM来与服务器进行通信和调用远程对象。配置好DCOM使其在一个大型的网络中正常工作将是一个极富挑战性的 工作，同时也是许多IT工程师的噩梦。事实上，许多IT工程师宁愿忍受浏览器所带来的功能限制，也不愿在局域网上去运行一个DCOM。在我看来，结果就是 一个发布容易，但开发难度大而且用户界面极其受限的应用程序。极端的说，就是你花了更多的资金和时间，却开发出从用户看来功能更弱的应用程序。不信？问问 你的会计师对新的基于浏览器的会计软件有什么想法：绝大多数商用程序用户希望使用更加友好的Windows用户界面。
关于客户端与服务器的通信问题，一个完美的解决方法是使用HTTP协议来通信。这是因为任何运行Web浏览器的机器都在使用HTTP协议。同时，当前许多防火墙也配置为只允许HTTP连接。
许多商用程序还面临另一个问题，那就是与其他程序的互操作性。如果所有的应用程序都是使用COM或.NET语言写的，并且都运行在Windows平台上， 那就天下太平了。然而，事实上大多数商业数据仍然在大型主机上以非关系文件(VSAM)的形式存放，并由COBOL语言编写的大型机程序访问。而且，目前 还有很多商用程序继续在使用C++、Java、Visual Basic和其他各种各样的语言编写。现在，除了最简单的程序之外，所有的应用程序都需要与运行在其他异构平台上的应用程序集成并进行数据交换。这样的任 务通常都是由特殊的方法，如文件传输和分析，消息队列，还有仅适用于某些情况的的API，如IBM的"高级程序到程序交流(APPC)"等来完成的。在以 前，没有一个应用程序通信标准，是独立于平台、组建模型和编程语言的。只有通过Web Service，客户端和服务器才能够自由的用HTTP进行通信，不论两个程序的平台和编程语言是什么。

什么是Web Service
对这个问题，我们至少有两种答案。从表面上看，Web service 就是一个应用程序，它向外界暴露出一个能够通过Web进行调用的API。这就是说，你能够用编程的方法通过Web来调用这个应用程序。我们把调用这个 Web service 的应用程序叫做客户。例如，你想创建一个Web service ，它的作用是返回当前的天气情况。那么你可已建立一个ASP页面，它接受邮政编码作为查询字符串，然后返回一个由逗号隔开的字符串，包含了当前的气温和天 气。要调用这个ASP页面，客户端需要发送下面的这个HTTP GET请求：
http://host.company.com/weather.asp?zipcode=20171

返回的数据就应该是这样：
21,晴

这个ASP页面就应该可以算作是Web service 了。因为它基于HTTP GET请求，暴露出了一个可以通过Web调用的API。当然，Web service 还有更多的东西。
下面是对Web service 更精确的解释： Web services是建立可互操作的分布式应用程序的新平台。作为一个Windows程序员，你可能已经用COM或DCOM建立过基于组件的分布式应用程 序。COM是一个非常好的组件技术，但是我们也很容易举出COM并不能满足要求的情况。
Web service平台是一套标准，它定义了应用程序如何在Web上实现互操作性。你可以用任何你喜欢的语言，在任何你喜欢的平台上写Web service ，只要我们可以通过Web service标准对这些服务进行查询和访问。

新平台
Web service平台需要一套协议来实现分布式应用程序的创建。任何平台都有它的数据表示方法和类型系统。要实现互操作性，Web service平台必须提供一套标准的类型系统，用于沟通不同平台、编程语言和组件模型中的不同类型系统。在传统的分布式系统中，基于界面 (interface)的平台提供了一些方法来描述界面、方法和参数（译注：如COM和COBAR中的IDL语言）。同样的，Web service平台也必须提供一种标准来描述Web service，让客户可以得到足够的信息来调用这个Web service。最后，我们还必须有一种方法来对这个Web service进行远程调用。这种方法实际是一种远程过程调用协议(RPC)。为了达到互操作性，这种RPC协议还必须与平台和编程语言无关。下面几个小 节就简要介绍了组成Web service平台的这三个技术。

XML和XSD
可扩展的标记语言(XML)是Web service平台中表示数据的基本格式。除了易于建立和易于分析外，XML主要的优点在于它既是平台无关的，又是厂商无关的。无关性是比技术优越性更重要的：软件厂商是不会选择一个由竞争对手所发明的技术的。
XML解决了数据表示的问题，但它没有定义一套标准的数据类型，更没有说怎么去扩展这套数据类型。例如，整形数到底代表什么？16位，32位，还是64 位？这些细节对实现互操作性都是很重要的。W3C制定的XML Schema(XSD)就是专门解决这个问题的一套标准。它定义了一套标准的数据类型，并给出了一种语言来扩展这套数据类型。Web service平台就是用XSD来作为其数据类型系统的。当你用某种语言(如VB.NET或C#)来构造一个Web service时，为了符合Web service标准，所有你使用的数据类型都必须被转换为XSD类型。你用的工具可能已经自动帮你完成了这个转换，但你很可能会根据你的需要修改一下转换 过程。在第二章中，我们将深入XSD，学习怎样转换自定义的数据类型(例如类)到XSD的类型。

SOAP
Web service建好以后，你或者其他人就会去调用它。简单对象访问协议(SOAP)提供了标准的RPC方法来调用Web service。实际上，SOAP在这里有点用词不当：它意味着下面的Web service是以对象的方式表示的，但事实并不一定如此：你完全可以把你的Web service写成一系列的C函数，并仍然使用SOAP进行调用。SOAP规范定义了SOAP消息的格式，以及怎样通过HTTP协议来使用SOAP。 SOAP也是基于XML和XSD的，XML是SOAP的数据编码方式。第三章我们会讨论SOAP，并结识SOAP消息的各种元素。

WSDL
你会怎样向别人介绍你的Web service有什么功能，以及每个函数调用时的参数呢？你可能会自己写一套文档，你甚至可能会口头上告诉需要使用你的Web service的人。这些非正式的方法至少都有一个严重的问题：当程序员坐到电脑前，想要使用你的Web service的时候，他们的工具(如Visual Studio)无法给他们提供任何帮助，因为这些工具根本就不了解你的Web service。解决方法是：用机器能阅读的方式提供一个正式的描述文档。Web service描述语言(WSDL)就是这样一个基于XML的语言，用于描述Web service及其函数、参数和返回值。因为是基于XML的，所以WSDL既是机器可阅读的，又是人可阅读的，这将是一个很大的好处。一些最新的开发工具 既能根据你的Web service生成WSDL文档，又能导入WSDL文档，生成调用相应Web service的代码。

 

Web Services是什么?

Web Services突然热起来了,特别是M$.net为我们描述了一个互联共享的世界,其实这些美好前景当初在Java诞生时早已经憧憬过,但理想的实现过程总是崎岖漫长.

我们从一个应用看看Web Services是怎么运作的:

有一个咖啡连锁店的老板叫Coffee Break,要拓展自己销售的咖啡品种,他指示他的采购经理去寻找一些新的咖啡提供商,得到他们的咖啡全部价格,并且在需要时能够立即下订单,Coffee Break能够分析他们的价格,并决定选用哪一种咖啡,从哪个公司进货.

询价
采购经理就将具体任务分配给软件工程师,软件工程师认为寻找新的咖啡提供商的最好办法是搜索UDDI注册中心.

UDDI注册中心:(Universal Description, Discovery, and Integration (UDDI) registry),UDDI Registry是一个逻辑上的统一体，在物理上则是以分布式系统的架构实施的，而不同站点之间是采用P2P(对等网络)架构实施的，因此访问其中任意一个站点就基本等于访问了UDDI Registry。

当然,Coffee Break也在UDDI注册中心注册了自己.

软件工程师就用JAXR(Java API for XML Registries )发出了一个查询所有咖啡提供商的指令,JAXR在后台使用JAXM(Java API for XML Messaging)发出消息,也就是基于SOAP发送XML文本.

UDDI注册中心接受了这个XML文本,并开始精确的搜索,但搜索完成后,注册中心将发回那些有关怎样联系那些符合条件的咖啡经销商的信息.也是基于SOAP发回XML文本.

工程师的下一步工作就是从这些分销商名单中列出他们的咖啡销售价格,这个工作分两步:

1.通过JAX-RPC(Java API for XML-based RPC )完成获取和分析WSDL文本(Services Description Language (WSDL) document).这也是一个XML文本,它给出了所有关于Web service的信息:告诉访问者自己提供哪些服务,服务内容是什么,怎样获取这些服务内容等.

2.工程师分析了WSDL文本后,得到了获取咖啡销售价格的方法和相应的网址.他就向那些具体的咖啡经销商网址发出请求,以获得其销售的咖啡价格.

每个咖啡分销商都会接受到这样的请求,在他发出销售价格之前,他也会先去查询一下产品的当前期货价格,这样Coffee Break就得到了最新的XML文本格式的咖啡价格.如下面:

<coffee>

<单价>
<哥仑比亚咖啡>19.20</哥仑比亚咖啡>
</单价>

....

</coffee>

XML是即将取代HTML的最新的浏览器语言,我们平时通过浏览器上网浏览,看到的都是HTML编写的文件,将来都是XML编写的文件.

分析价格并订购
读取XML文本有两种方式:SAX和DOM,对于简单比价,使用SAX比DOM更有效率,但是如果要修改价格表,就要使用DOM,Coffee Break的工程师使用SAX比较了这些分销商发来的价格表,并得出了一张结果表,报送到采购经理或老板Coffee Break.一旦决定订购咖啡,也是通过发送XML文本和经销商联系.

通过Internet销售
Coffee Break 已经准备好了新的咖啡品种,需要在他的网站上发布这个咖啡品种新的价格.Coffee Break当然不能以自己进货的价格销售咖啡,工程师就使用DOM修改了一下上面的XML文档,将每个价格乘125%,这就是Coffee Break的咖啡销售价格.

工程师使用JSP做了一个订单表单.在这个JSP程序里,他可以从上面修改后的XML文档中读取每个咖啡的名称和价格.顾客只要选择购买数量,然后按Submit就当前咖啡放入自己的购物车,开始了网上购物.

Web Service是将XML文本在各个网站之间传送和接受,以达到信息交换的目的.在接受和传送时有一个协议,就是SOAP(Simple Object Access Protocol),这是个XML+http的协议.当前我们网站公布信息,都是通过http协议发送到用户的浏览器上,因此SOAP有广泛的应用基础,现在就差XML的普及.

不过,因为XML是纯粹的数据结构,但只有数据的互联网将倒退到学术科研时代,因此,类似Frontpage Dreamweaver基于XML的强大的页面设计工具是重要的,但是这样的可视化工具很难设计.

所以XML的普及有时间问题,那么Web Services提供的上述美好前景的真正实现,恐怕不是一两年内会达到的.

但 是Web Services为专门从事互联网服务的公司带来的机会,因为他们的客户是一个个商业网站,因此,他们可以开发一个个商业应用,而不必将这些应用象普通软 件一样安装在他们客户的服务器上,而是让他们的客户网站通过SOAP来调用这些软件功能,并支取一定的使用费.

对于作为客户的网站来说,购买了某个互联网服务,不必专门设立服务器,购买大量软件,还要维护他们,只要通过直接调用提供该功能的Web Services就可以，比如购物车功能，这是每个网上商店都必须的，但每个商家不一定去购买这个软件，只要在自己网页中直接调用网上商店的Web Services就可以。

但现在最致命的是Web Services的安全性。

Sun的Web Service:http://java.sun.com/webservices/docs/ea2/tutorial/index.html

Open source的Web Service服务器,需Tomcat同时运行:http://xml.apache.org/axis

WebService的基本概念 

WebService是一种可以接收从Internet或者Intranet上的其它系统中传递过来的请求，轻量级的独立的通讯技术。

这种技术允许网络上的所有系统进行交互。随着技术的发展，一个Web服务可以包含额外的指定功能并且可以在多个B2B应用中协作通讯。 Web服务可以理解请求中上下文的关系，并且在每一个特定的情况下产生动态的结果。这些服务会根据用户的身份，地点以及产生请求的原因来改变不同的处理， 用以产生一个唯一的，定制的方案。这种协作机制对那些只对最终结果有兴趣的用户来说，是完全透明的。  

UDDI

在用户能够调用Web服务之前，必须确定这个服务内包含哪些商务方法，找到被调用的接口定义，还要在服务端来编制软件。所 以，我们需要一种方法来发布我们的Web服务。 UDDI (Universal Description, Discovery, and Integration) 是一个主要针对Web服务供应商和使用者的新项目。UDDI 项目中的成员可以通过 UDDI Business Registry (UBR) 来操作Web服务的调用，UBR是一个全球性的服务。 Web 服务供应商可以在UBR中描述并且注册他们的服务。 用户可以在UBR中查找并定位那些他们需要的服务。 UDDI是一种根据描述文档来引导系统查找相应服务的机制。 UDDI包含标准的“白皮书”类型的商业查询方式， “黄皮书”类型的局部查找，以及 “绿皮书”类型的服务类型查找。 UDDI 利用SOAP 消息机制（标准的XML/HTTP ）来发布，编辑，浏览以及查找注册信息。它采用XML格式来封装各种不同类型的数据，并且发送到注册中心或者由注册中心来返回需要的数据。  

WSDL

对于商业用户来说，要找到一个自己需要使用的服务，他必须知道如何来调用。 WSDL (Web Services Description Language) 规范是一个描述接口，语义以及Web服务为了响应请求需要经常处理的工作的XML文档。这将使简单地服务方便，快速地被描述和记录。以下是一个WSDL的样例：

<?xml version="1.0"?>
<definitions name="StockQuote"
                targetNamespace="http://example.com/stockquote.wsdl"
                xmlns:tns="http://example.com/stockquote.wsdl"
                xmlns:xsd1="http://example.com/stockquote.xsd"
                xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
                xmlns="http://schemas.xmlsoap.org/wsdl/">
<types>
   <schema targetNamespace=http://example.com/stockquote.xsd
                 xmlns="http://www.w3.org/2000/10/XMLSchema">
      <element name="TradePriceRequest">
        <complexType>
           <all>
                <element name="tickerSymbol" type="string"/>
              </all>
           </complexType>
        </element>
        <element name="TradePrice">
            <complexType>
                <all>
                   <element name="price" type="float"/>
                 </all>
              </complexType>
           </element>
        </schema>
     </types>
     <message name="GetLastTradePriceInput">
         <part name="body" element="xsd1:TradePriceRequest"/>
     </message>
     <message name="GetLastTradePriceOutput">
         <part name="body" element="xsd1:TradePrice"/>
    </message>
    <portType name="StockQuotePortType">
        <operation name="GetLastTradePrice">
            <input message="tns:GetLastTradePriceInput"/>
            <output message="tns:GetLastTradePriceOutput"/>
         </operation>
      </portType>
      <binding name="StockQuoteSoapBinding"
                    type="tns:StockQuotePortType">
         <soap:binding style="document"
                                 transport="http://schemas.xmlsoap.org/soap/http"/>
        <operation name="GetLastTradePrice">
            <soap:operation
                           soapAction="http://example.com/GetLastTradePrice"/>
            <input>
               <soap:body use="literal"/>
            </input>
            <output>
                <soap:body use="literal"/>
            </output>
         </operation>
      </binding>
     <service name="StockQuoteService">
        <documentation>My first service</documentation>
        <port name="StockQuotePort" binding="tns:StockQuoteBinding">
            <soap:address location="http://example.com/stockquote"/>
        </port>
     </service>
  </definitions>

它包含了以下的关键信息： 消息的描述和格式定义可以通过XML文档中的<types>和<message> 标记来传送。 <portType> 标记中表示了消息传送机制。 (e.g. request-only, request-response, response-only) 。 <binding> 标记指定了编码的规范 。 <service> 标记中表示服务所处的位置 (URL)。 WSDL在UDDI中总是作为一个接口描述文档。因为UDDI是一个通用的用来注册WSDL规范的地方，UDDI的规范并不限制任何类型或者格式描述文 档。这些文档可能是一个WSDL文档，或者是一个正规的包含导向文档的Web页面，也可能只是一个包含联系信息的电子邮件地址。现在Java提供了一个 Java API for WSDL (JWSDL)规范。它提供了一套能快速处理WSDL文档的方法，并且不用直接对XML文档进行操作，它会比JAXP更方便，更快速。  

SOAP

当商业用户通过UDDI找到你的WSDL描述文档后，他通过可以Simple Object Access Protocol (SOAP) 调用你建立的Web服务中的一个或多个操作。 SOAP是XML文档形式的调用商业方法的规范，它可以支持不同的底层接口，象HTTP(S)或者SMTP。 之所以使用XML是因为它的独立于编程语言，良好的可扩展性以及强大的工业支持。之所以使用HTTP是因为几乎所有的网络系统都可以用这种协议来通信，由 于它是一种简单协议，所以可以与任何系统结合，还有一个原因就是它可以利用80端口来穿越过防火墙。 SOAP的强大是因为它简单。SOAP是一种轻量级的，非常容易理解的技术，并且很容易实现。它有工业支持，可以从各主要的电子商务平台供应商那里获得。 从技术角度来看，SOAP详细指明了如何响应不同的请求以及如何对参数编码。一个SOAP封装了可选的头信息和正文，并且通常使用HTTP POST方法来传送到一个HTTP 服务器，当然其他方法也是可以的，例如SMTP。SOAP同时支持消息传送和远程过程调用。以下是一个SOAP请求。

POST /StockQuote HTTP/1.1
Host: www.stockquoteserver.com
Content-Type: text/xml; charset="utf-8"
Content-Length: nnnn
SOAPAction: "Some-URI" <SOAP-ENV:Envelope
    xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
    SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>
    <SOAP-ENV:Header>
        <t:Transaction xmlns:t="some-URI" SOAP-ENV:mustUnderstand="1">
           5
        </t:Transaction>
    </SOAP-ENV:Header>
    <SOAP-ENV:Body>
        <m:GetLastTradePrice xmlns:m="Some-URI">
            <symbol>SUNW</symbol>
        </m:GetLastTradePrice>
    </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

JAXR

为了支持UDDI在Java平台上的功能，Java APIs for XML Registries (JAXR)允许开发者来访问注册中心。 值得注意的是，JAXR 并不是建立Web 服务必需的，你可以利用其他常用的XML APIs 来直接集成这些协议。 JAXR是一个方便的API，它提供了Java API来发布，查找以及编辑那些注册信息。它的重点在于基于XML的B2B应用，复杂的地址本查找以及对XML消息订阅的支持等Web服务。 它也可以用来访问其他类型的注册中心，象ebXML 注册中心。这些对Web服务的注册信息进行的操作，可以使用当前的一些Web服务工具来完成（例如第三方的SOAP和ebXML消息工具）。另外，当JAXP提供了一致并具有针对性的API来完成这些操作，这将使开发变得更加容易。

JAX/RPC

为了使开发人员专注于建立象SOAP那样的基于XML的请求，JCP正在开发基于RPC (JAX/RPC) 的Java API。JAX/RPC是用来发送和接收方法调用请求的，它基于XML协议，象SOAP，或者其他的象XMLP (XML Protocol，要了解更多可以参考 http://www.w3.org/2000/xp/)。 JAX/RPC使你不用再关注这些协议的规范，使应用的开发更快速。不久，开发人员就不用直接以XML表示方法调用了。目前有很多第三方实现了SOAP， 开发人员可以在不同的层次上调用SOAP，并选择使用哪一种。将来，JAX/RPC会取代这些APIs并提供一个统一的接口来构造以及处理SOAP RPC请求。在接收一个从商业伙伴那里过来的SOAP请求的时候，一个Java servlet用JAX/RPC来接收这个基于XML的请求。一旦接收到请求后，servlet会调用商务方法，并且把结果回复给商业伙伴。

JAXM

当从商业合作伙伴那里接收一个Web服务的请求时，我们需要Java API实现一个Servlet来处理ebXML消息，就象我们用JAX/RPC来处理SOAP请求一样。 Java API for XML Messaging (JAXM) 是集成XML消息标准（象ebXML消息或者SOAP消息）的规范。 这个API是用来推动XML消息处理的，它检测那些预定单的消息格式以及约束。它控制了所有的消息封装机制，用一种直观的方式分割了消息中的信息，象路由 信息，发货单。这样，开发人员只要关注消息的有效负载，而不用去担心那些消息的重复处理。目前的开发人员用JAXP来实现JAXM将要提供的功能， JAXM将会提供一套非常具有针对性的API来处理基于XML的消息传送。这将大大简化开发人员的代码，并使它们具有统一的接口。 JAXM和JAX/RPC的差别在于处理消息导向的中间件以及远程过程调用的不同。JAXM注重于消息导向，而JAX/RPC是用来完成远程过程调用的。

请注意，在JAXM 和 JAX/RPC技术成熟之前，开发人员还是依赖于第三方的SOAP APIs，象Apache SOAP, IdooXOAP, 以及 GLUE。当JAXM 和 JAX/RPC正式发布后，它将为当前不同的SOAP和ebXML消息提供统一的接口。就象JDBC位多种不同的数据库提供统一的接口。  

JAXB

XML 绑定技术可以把XML 文档和Java 对象进行自由转换。 用JAXB，你可以在后台的EJB层，把XML文档转换成Java对象。同样你也可以把从EJB中取出的Java对象转换成XML文档返回给用户。 JAXB接口提供了比SAX和DOM更高级的方法来处理XML文档。它提供的特性可以在XML数据和Java类之间互相映射，提供了一个简单的方法来转换 XML数据。它比逐个解析标记更简单。

Webservice 的设计和模式

本文是篇译文（原文在 devx），对于想初步了解webservice的朋友可能有些帮助。

Webservice 作为一项新的技术出现在我们面前，它的出世是用于解决在不同的平台下的应用的协同的。目前几乎每家厂商都要去开发Webservice 应用，然而如果缺乏对Webservice更深的了解，不能很好的在设计阶段处理好一些重要的问题，那么最终完成的系统必然是效率低下，没有可靠性的产 品。

 

在设计Webservice 应用时，以下几点务必要考虑到：

l         管理好与外系统的协同关系

l         掌握底层的传输模型

l         提供与应用相适应的安全策略

l         计划好部署的相关事项

 

以下，将就这几条相关的设计需求和一些常用模式是如何应用于Webservice模型展开详细讨论。在讨论中，你会发现Webservice这项新的技术是如何与我们在以往的软件开发相结合的。

 

l         标准提供了协同的能力

 

Webservice的一个最基本的目的就是提供在各个不同平台的不同应用系统的协同工作能力。

为了使得一个公司的网络应用达到最高的效率，存在它自己和它的合作伙伴，供应商以及客户之间的Webservice，应该能够实现无缝的交互。 如果在众多的Webservice之间不能轻松的实现交互，那么该应用的效率将大打折扣。但是，在现实中这种情况是极有可能出现的。由于各个公司对业务的 理解各不相同，就是理解相同的情况下，对于相同的概念也可能用不同的形式加以表现，具体而言就是对于同一数据可能采取不同的xml表示。由于以上的原因， 对于协同性的问题应该在设计应用架构时就加以考虑，而不是留待以后去改变。

 

Webservice 主要由以下几块技术所构成，SOAP (Simple Object Access Protocol), WSDL (Web service Description Language), 以及UDDI (Universal Description, Discovery and Integration)。

 

在这里我们不会去详细研究这些技术，而是揭示他们的一些重要特性，这些特性需要在Webservice的设计时详加考虑。

 

WSDL是实现协同能力的关键，它提供了一份契约用于与新老的应用之间交互。这项技术使得各个组织可以将标准的制定集中在Service的外部 接口，而不用考虑各组织的具体实现。简而言之，它实现了Webservice的接口与实现的分离。从而使得标准的制定，更加容易。并且，基于这份接口描 述，很多工具可以从中自动生成客户端代码，减少了开发者的工作量，并使得大部分开发者摆脱了编写SOAP消息传递代码过程。

 

SOAP是实现在各个Webservice组件之间传递消息的传输层。因此，SOAP应该是一项透明的协同技术。但是，由于很多的SOAP实现 方法却与标准背道而驰，要么添加了新的扩展功能要么删减了一些标准功能。由于对SOAP标准的支持程度不同，使得Webservice的协同能力大打折 扣，实现协同的困难加大了。基于这种情况，当开发者需要Webservice运行在不同平台上时，就要对具体情况加以了解并相应的编码以解决这种不一致 性。如果所有的SOAP实现组织都能够遵循标准的话，那么Webservice的开发者就不需要考虑使用该Webservice的底层平台了。

 

尽管如此，不同SOAP实现的协同还是相当困难，因为协同标准的制定存在大量的分歧，目前一些组织正致力于标准的制定，比如SOAP Builders 和 WS-I。然而，现在Webservice开发者只有针对不同平台，给予不同的实现，使得开发的成本和负担加大了。

 

l         理解传输模型

 

SOAP并不是完全透明的解决方案，它把一些复杂的实现细节隐藏起来。Webservice的开发者必须深入的了解SOAP，了解底层的传输机 制以及模型,从而知道SOAP是如何实现的。在一些简单的应用中，某些工具可以帮助Webservice的开发者生成SOAP消息传递的代码，但是这只在 最简单的应用中有效。真正的情况不可能那么简单，可能在某些方面你需要有特殊的处理（这种情况在实际开发中是很常见的），这个时候，你就需要直接操纵 SOAP的消息传递代码，以及一些底层的XML内容。因此，Webservice的开发者需要深入了解SOAP和XML层的内容。

 

在开发Webservice的接口的时候，不要以为使用XML技术，协作性的问题就迎刃而解了，XML并不是解决集成问题的灵丹妙药。这里同样 需要标准的制定，需要一个在业界公认的词汇表。仅仅在你的设计框架中引入XML技术并不能保证系统具有协同性，XML仅仅是用来描述数据的语言，XML自 己并不提供语义去理解数据。就如同英语和德语都使用拉丁字母，但是他们的语义却并不相同。

 

即使你使用相同的语言，也不能保证具有良好的协作性。比如你的公司可能使用Order描述一个订单，但你的合作伙伴可能使用 Purchase_Order，而另一个伙伴可能又不相同。你不可能强迫你所有的合作伙伴都采用和你相同的词汇。因此需要有一项技术可以在众多的描述之间 充当翻译的角色。XSLT就是这么一种技术，它用于不同语言的转换。和XSLT的配合使用XML才能解决协同性的问题。

 

l         DOM vs. SAX

许多的Webservice开发环境，将开发者从底层的XML文档的解析和处理中解放出来，他们提供了自动化或者很方便的工具，使得这一过程变 得很简单。但是对于一些有特殊要求的Webservice应用，比如需要更好的柔性或者对速度要求特别高的应用，就需要手工处理XML文档。这时候两种 XML解析的模型－DOM 和SAX的选择，将成为重要的问题。

 

    

DOM使用树状图的方式解析XML文档，而SAX则更多的采用事件驱动的模型。

 

DOM先将XML文档映射成一颗树，然后通过采用一系列与树相关的操作去处理这份文档。这种方法有很多的好处，首先开发者很容易理解，使用一颗 树这对于开发者来说是最常见不过的了。DOM最常用于XML在Service中需要频繁修改的场合。当然DOM也有它的缺点，在处理XML文档的时候，它 需要载入整个文档，而不管你需要修改的是否只是其中的一小部分。因此它的运行效率以及对内存的使用显然是不能接受的，尤其是面对很大的XML文档。

SAX使用事件驱动的模型来处理XML文档。通过一系列事件的触发，来完成对XML的解析，你可以只关心你所要处理的事件，当这些事件发生时， 会调用到相应的回调函数来通知到你。采用这种方式就可以在很大程度上提高XML文档解析的效率。但是它的缺点在于难于使用，以及对同一文档的多次处理会存 在一些问题。

总而言之，DOM更适合处理那种文档型的XML文件，而SAX则适于那种想直接将XML结构映射成在你系统中的一个对象的操作。（比如将一个XML结构直接映射成JAVA中的一个Class）或者那种针对XML文件中特殊Tag的操作。

 

l         文档交换vs. RPC模型

这两种交互方式应该在应用架构的设计初始就应该详加考虑，因为它将在很大程度上决定系统的耦合程度。

RPC（Remote Procedure Call）本质上就是远程方法的调用。尽管Webservice是基于XML的但是你仍然可以使用远程方法调用这种模式来进行Webservice的实 现，尤其是在那种简单的请求相应的模型中。在这个过程中，传输中的XML文件所描述的更多是有关远程方法的信息，比如方法名，方法参数等等。

而文档交换方式，与RPC相比较在XML文件中不是做远程方法的映射，而是一份完整的自包含的业务文档，当Service端收到这份文档后，先 进行预处理（比如词汇的翻译和映射），然后再构造出返回消息。这个构造返回消息的过程中，往往不再是简简单单的一个方法调用，而是多个对象协同完成一个事 务的处理，再将结果返回。

这两种方式的区别，类似与打电话和发邮件的不同处理方法。在目前，对于第一种方法提供了很多自动化的工具使得远程方法的调用能够很容易的完成，而后一种方法缺少一系列工具的支持，需要开发者手工完成。

尽管如此，在此还是推荐使用文档交换的方式。由于它在以下方面具有RPC所不具备的优点。

使用文档方式，你可以充分利用XML文件的功能去描述和验证一份业务文档，而在RPC模型中XML仅仅被用于描述方法的信息。

使用文档方式，在客户的Service的提供者之间不再需要紧密的约定，而RPC模型需要客户和Service的提供者紧密相连，一旦方法发生变化，客户端就需要做相应的改动。这不符合低耦合系统的要求，而在文档交换方式中则灵活的多。

由于业务数据是自包含的，显然文档模型更利于采用异步处理。

 

 

l         利用设计模式

设计模式在设计Webservice的时候显然可以起到相当大的作用。设计模式的主要目的就是为解决某些在类似环境下的相像问题提供已有的较为成熟的设计方案。在这里，只简单的提及一些很常用的模式，让我们了解到模式在Webservice中可以起到的作用。

Adapter ：为内部系统提供一个不同的接口

Façade： 封装复杂的内部实现，提供一系列简单的接口

Proxy： 作为其他对象的代理，代替它提供服务

 

Adapter模式用于将一个组件的接口转化成客户所需要的样子，这里的客户就是Webservice。一个常见的情况就是将原有的老的系统包 装成一个Webservice。比如现在使用的是J2EE的平台，而原来有一个C++的系统实现了某些功能，现在需要将它发布成Webservice，那 么就需要利用JNI技术做一个Adapter，为原来的C++组件提供一个Java的接口，然后再转化为Webservice。

 

Façade模式用于构建粗粒度的服务，它包装了细粒度的服务，从而为复杂的系统提供了一个简单的接口。在J2EE中，Session Bean就象是一个Façade，而Entity Bean则是细粒度的服务。在Webservice中也一样，使用Façade模式可以将已有的组件的功能发挥殆尽。

 

Proxy 模式用于充当其他对象的代理，类似于中间人的作用，将处理工作从一个对象传递到另一个对象。在Webservice中，它主要用于隐藏Soap消息构造的过程。也可以用于模拟对象（Mock Object）的创建。

 

以上仅仅是一些可以用于Webservice开发的模式，如果你熟练的将这些模式应用于Webservice开发，你将会发现开发Webservice应用，将好像做一种特殊的面向对象设计。

 

l         安全

Webservice为作为方便的服务被用广大领域使用的同时，也成为了黑客们的美食。在这里，本文将就目前对Webservice安全所能做的改进做简单介绍。

在Webservice中的安全主要分为以下三个方面。

传输      SSL/HTTPS 对连接加密，而不是传输数据

消息      数据加密(XML Encryption)   数字签名(XML-DSIG)

底层架构  利用应用服务安全机制

 

传输时的安全是最容易被加入到你的Webservice应用中的，利用现有的SSL 和HTTPS协议，就可以很容易的获得连接过程中的安全。

 

然而这种安全实现方法有两个弱点。一是它只能保证数据传输的安全，而不是数据本身的安全，数据一旦到达某地，那么就可以被任何人所查看。而在 Webservice中，一份数据可能到达多个地方，而这份数据却不该被所有的接受者所查看。二是它提供的是要么全有要么全无的保护，你不能选择哪部分数 据要被保护，而这种可选择性也是在Webservice中所常要用到的。

 

第二层的保护是对于消息本身的保护。你可以使用已有的XML安全扩展标准，实现数字签名的功能，从而保证你的消息是来自特定方并没有被修改过。 XML文件的加密技术从更大程度上加强了Webservice的安全，它能够定制数据传输到后，能否被接受者所查看，进一步完善了传输后的安全，业界也在 不断的制定Webservice的安全标准，比如SAML 和 WS-Security。

 

最后一层保护就是依靠底层架构的安全，这更多的来自于操作系统和某些中间件的保护。比如在J2EE中，主持Webservice的应用服务器。 目前很多的J2EE应用服务器都支持Java Authentication and Authorization Service (JAAS)，这是最近被加入到J2SE 1.4当中的。利用主持Webservice的服务器，实现一些安全机制这是很自然的做法。另一种利用底层架构的安全方法就是，做一个独立的负责安全的服 务器，Webservice的使用者和创建者都需要与之取得安全信任。

推荐资料
Web Services Security