Huihoo Power! - 用J2EE开发WebService

用J2EE开发WebService

(by huihoo.com donyoung , Allen制作)

英文原文：http://www.theserverside.com/resources/article.jsp?l=WebServices-Dev-Guide

I. 概要

基于XML的Web服务是参照B2B通信协作模式制定的新的规范。它提供了概念上和结构上的，适用于各种不同平台和产品的基础。现在，开发者可以利用J2EE技术来开发基于XML的Web服务。他们可以利用现存的J2EE技术来开发完整的，遵从XML标准的，能完全共通的WEB服务。无需重新设计或者构造现有的J2EE系统，开发人员就可以构建复杂的强大的Web服务应用。

II. 介绍 Web服务是一种可以接收从Internet或者Intranet上的其它系统中传递过来的请求，轻量级的独立的通讯技术。这种技术允许网络上的所有系统进行交互。随着技术的发展，一个Web服务可以包含额外的指定功能并且可以在多个B2B应用中协作通讯。

Web服务正在不断完善，并且以一种非常智能的动态的方法来进行。这些灵活的Web服务可以理解请求中上下文的关系，并且在每一个特定的情况下产生动态的结果。这些服务会根据用户的身份，地点以及产生请求的原因来改变不同的处理，用以产生一个唯一的，定制的方案。这种协作机制对那些只对最终结果有兴趣的用户来说，是完全透明的。

这种Web服务所遵循的XML标准可以增进事物通信的性能。开发人员将可以利用不同的平台，产品和标准来实现很多种可能。通过这种标准，开发人员可以建立一个系统使他们的Web服务提供最大的协同工作的能力。

这份白皮书描述了如何方便地利用Java和XML技术来实现Web服务构架。它说明了Web服务中的每一个关键部分以及如何使他们结合在一起。你将会对基于XML的Web服务的结构以及如何与J2EE结合，有一个更加深入的了解我们从如何利用J2EE建立Web服务开始。这部分将使你对如何建立一个Web服务有一个了解。

III. 总结 一般来说，在不同的事务之间进行电子通信协作会有很多阻碍。全异的系统，安全限制和不相同的数据格式，导致很多B2B系统在他们自己的领域或者客户群中形成唯一。Web服务将改变这一切，使不同的事务互相通信变为可能，值得注意的是，这会降低建立商业站点的开发和维护成本。

在建立Web服务的时候，有三个主要步骤：

1. 建立客户端联接为了允许Applets，Applications，商业合作伙伴，浏览器和PDAs 使用Web服务。

2. 实现Web服务包括工作流，数据传送，商业逻辑以及数据访问。这些功能是隐藏在Web服务后，并且为客户端工作的。

3. 联接后台系统这个系统可能包括一个或多个数据库，现存的企业信息系统，商业合作伙伴自己的系统或者Web服务，以及在多个系统中共享的数据。

你可以利用J2EE来实现这三个目标。用J2EE开发Web服务基于以下两个技术：

XML 技术.
在Web服务中，XML标准是非常重要的。XML是一种数据格式，它可以以一种连贯的方式来表现数据，并且可以在网络中以点对点的形式传送。这些不同的XML标准连同指定的处理方法是设计来支持特定的行为的。

Java 技术.
Developers开发人员利用 J2EE APIs来创建事务和表现的逻辑，访问XML文档，以及对XML文档进行操作。信任被证实可行的Java技术是非常重要的，因为它允许开发者利用现有的下部构造，在其上构建新的功能。开发者可以继续利用J2EE的标准API以及各种优秀的组件来开发系统。现在，开发者可以利用J2EE中提供的Java API for XML Parsing (JAXP) 来开发Web服务，我们将在稍后介绍。这个新的APIs主要用来处理XML数据格式以及服务，将使开发变得更容易，效率更高。
图 1 表现了基于J2EE的Web服务的核心构架。请注意，很多APIs在这里并没有全部表示出来，象用来解析或者传送消息的。但是，那些基于J2EE的标准，协议以及主要的子系统都表示出来了。

图 1让我们进一步看一下利用J2EE来创建Web服务的细节。

IV. 客户端联接

客户端联接是关于Web服务的使用者如何来使用你的系统。表格 1 显示了三种主要使用系统的客户。

客户类型	样例	如何联接
商业合作伙伴	代理商，客户群	基于XML的Web 服务技术 (SOAP, UDDI, WSDL, ebXML)
瘦客户端	浏览器，PDAs，无线设备	HTTP 协议
胖客户端	应用小程序，应用程序，已经存在的系统	IIOP协议

表格 1商业合作伙伴的联接

第一种访问Web服务的客户类型是商业合作伙伴。他们可能使用很多种类型的编程语言，中间件或者硬件。当他们访问尼的系统的时候，Web服务要求返回一个XML文件。这个文件具有标准的标记来表示商业数据，并且允许不同的系统通过这个来交互。

Java Servlets

当一个商业合作伙伴向Web服务发布一个请求的时候，接收请求的是一个Java servlet. 这个Servlet是一个在管理容器中运行，负责接收请求和响应的Java对象。它可以以很多种协议返回请求结果，象HTTP, FTP或者POP。在这个例子中Servlet通常使用HTTP来响应请求，这样的话，Web服务就可以利用HTTP来通过防火墙了。

当一个请求到达J2EE Web服务的时候，以下操作会发生，见图2

1. Java servlet接收XML 文档。

2. Servlet 处理传入的基于XML的请求

3. Servlet调用一个或者多个Enterprise JavaBeans (EJB) 组件来处理数据。

4. EJB组件进行他们自己的处理，可能会调用其他存在的系统。

5. EJB 组件把结果返回给Servlet。

6. Servlet 把结果汇集到XML文档中。

7. Servlet 把XML传送到客户端。

图 2为了实现商业合作伙伴的联接，必须有一种方法来发布，描述，定位以及调用一个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格式来封装各种不同类型的数据，并且发送到注册中心或者由注册中心来返回需要的数据。

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来完成这些操作，这将使开发变得更加容易。

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文档中的和标记来传送。
· 标记中表示了消息传送机制。 (e.g. request-only, request-response, response-only) 。
· 标记指定了编码的规范。
· 标记中表示服务所处的位置 (URL)。

WSDL在UDDI中总是作为一个接口描述文档。因为UDDI是一个通用的用来注册WSDL规范的地方，UDDI的规范并不限制任何类型或者格式描述文档。这些文档可能是一个WSDL文档，或者是一个正规的包含导向文档的Web页面，也可能只是一个包含联系信息的电子邮件地址。

现在Java提供了一个 Java API for WSDL (JWSDL)规范。它提供了一套能快速处理WSDL文档的方法，并且不用直接对XML文档进行操作，它会比JAXP更方便，更快速。

图 3 显示了如何使用WSDL 和 UDDI。

图 3

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>

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会调用商务方法，并且把结果回复给商业伙伴。

ebXML 对于具有高扩展性的商业交易来说，他们需要一种可信任的结构来实现商业事务，多请求的事务，计划以及文档流程，应用的需求经常超越了基于纯SOAP的实现。因为SOAP只是提供了一个底层的结构，而你可能需要一个更高级的框架结构。

ebXML就是为了这个目的的，它是一套处理B2B应用间的合作与通信的XML规范。以下是ebXML中的关键组件：

Collaboration Protocol Profile (CPP)

CPP提供了一种标准并且简单的方法描述了公司提供的产品。另外，它还描述了消息交换的能力以及公司支持的商务合作。它也描述了公司的商务处理方法，包括合伙人如何与公司合作。CPP定义了B2B交易中双方的商务协作。例如，它同时定义了买卖双方的商务处理方法。

Collaboration Protocol Agreement (CPA)

CPA描述了两个公司之间进行交易时的详细需求以及机制。它包含有由手工或者自动从经过买卖双方认可的CPPs中的信息。这个CPA是双方进行指定交易的合约。 CPP和CPA的样例，以及关于规范的细节可以从以下网站获得：

http://ebxml.org/project_teams/trade_partner/cpp-example.xml
http://ebxml.org/project_teams/trade_partner/cpa-example.xml
http://www.ebxml.org/specs/ebCCP.pdf

Business Process and Information Modeling

ebXML还以XML的形式描述了商业事务处理的规范。它包括交易，文档流程，数字通信，数据封装格式以及其他更多。这些规范是用来建立CPPs，描述以及共享商业事务和信息时用的。

Core Components

ebXML中另外一个重要的部分是一系列的XML标记，我们叫它核心组件。这些标记包含了商务数据，象日期，税，账户，交易合同以及其他的。它指明了商业合约和实体，但对每个不同的行业，可能都不一样。

Messaging

ebXML消息格式包含了所有相关的消息导向信息（同步或者异步，可靠性）。一般来说，一个ebXML消息包含了CPA中的可视化内容，并强制执行交易规则。 EbXML是建立在SOAP消息封装机制上的。它扩展了SOAP的协议，增加了多层框架结构来支持附件，安全性以及传送的可靠性。

Registry/Repository

EbXML注册中心是存储CPPs, CPAs, ebXML核心组件和与ebXML相关的文档的服务。它具有强大的查询功能，允许用户查找相关的组件以及发掘潜在客户。JAXR API也可以用来访问ebXML注册中心。商业服务定义了CPPs，并且被存储在ebXML注册中心，然后发布到UDDI中。一个关键的概念是，UDDI提供了一个全球唯一的Web服务的描述信息，但那些真实的信息，还是保存在本地的ebXML库中。这样的话，一个潜在的客户首先到UDDI中查找相关内容，然后根据这些到ebXML库中找CPPs或者其他相关文档。

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是用来完成远程过程调用的。以下是图解。

图 4

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

以上是对于让商业合作伙伴访问你的Web服务的讨论。下面我们来讨论瘦客户端和胖客户端。

Thin Client Connectivity

瘦客户端（象浏览器或者无线设备）只对浏览页面感兴趣。Web服务的职责是执行需要处理的Web请求，象运行B2C交易，然后给出订单确认。为实现这个，开发者用JSP来写动态页面。JSP组件技术时一种可以根据后台数据处理的结果，来动态生成页面的技术。它们在提供JSP组件的容器中运行。 JSP可以表现后台用各种方法来实现的业务逻辑（e.g. EJBs，普通的Java对象，或者标准的JavaBean）。它可以生成标准的HTML或者XHTML来显示结果。 JSP组件与其说是可编程接口，不如说是用户界面。比方说，一个股票报价服务可能需要调用一个统计股票平均报价的应用中的Web服务，然后利用JSP技术把最终结果显示出来。以下显示了JSP组件的角色。

图 5

Thick Client Connectivity

有些Web服务的连接适合用胖客户端。比方说，公司的内部网。用户界面的响应以及功能可能更加重要。

一个胖客户端可以用很多种方法来联接Web服务。比方说，可以用UDDI, WSDL, SOAP以及ebXML。这是一个性能比较低的例子，因为客户端和服务端可能是由同样的开发组开发的，所以不需要处理很多的XML传送或者解析。

一个提高性能的方法是，胖客户端通过其他更有效的端口来联接，象Java RMI-IIOP。

V. Implementing Web Services

现在我们来看，如何在内部实现Web服务。

数据传送和转换

在进入Web服务之前，我们必须解决如何把传送进来的XML数据转换成我们自己的服务能够方便处理的格式，然后再把处理结果转换成XML格式返回给客户。因此一个开发人员需要一个强壮的机制来解析XML文件，绑定到Java对象，生成XML文件，并且传送各种不同的XML格式文件。有时由于我们的应用程序支持不同的接口（例如：B2B伙伴的SOAP，基于浏览器的HTML格式，或者是无线的WML访问同样的Web服务）我们可能需要不同的服务接口来处理这些不同客户端传送过来的请求。

JAXP

用来处理XML的Java APIs是一套Java本地接口，它提供了可插入到XSLT引擎中的接口SAX，DOM。这些构成了解析和处理XML文档的基础。这些APIs对Web服务来说，是非常底层的，它给了我们用Java来访问，修改以及创建XML文档的全部功能。

For more information, please see:

http://java.sun.com/xml/tutorial_intro.html
http://java.sun.com/xml/xml_jaxp.html

JAXB

XML绑定技术可以把XML文档和Java对象进行自由转换。用JAXB，你可以在后台的EJB层，把XML文档转换成Java对象。同样你也可以把从EJB中取出的Java对象转换成XML文档返回给用户。

JAXB接口提供了比SAX和DOM更高级的方法来处理XML文档。它提供的特性可以在XML数据和Java类之间互相映射，提供了一个简单的方法来转换XML数据。它比逐个解析标记更简单。

XSLT

从商业伙伴那里传送过来的XML文档可能和内部使用的格式不相同，比方说商业伙伴那里用"OrderNum"，而内部使用"OrderID"。

我们经常为了响应不同的客户请求，而重新格式化XML数据文档。举例来说，一个商业伙伴的请求可能传送一个SOAP表单，而一些浏览器用户可能是一个XHTML。在一个更复杂的系统中，我们可能需要支持很多种不同的表现形式，象WML表单或者VoiceXML。这要求我们有一种机制来把各种XML以基本的XML响应格式来传送给我们系统中不同的接口。

XML Stylesheet Language Transformations (XSLT)

是一种转换XML格式的机制。一个stylesheet可以指定一系列的模版对应规则，并把它们赋给一个可递归的，象DOM这样的模型。一个XSLT引擎可以用stylesheet来转换XML文档。XSLT stylesheet的语法是非常有表现力的，包含了循环，条件和数学表达式等。还有类似于函数（function）的机构和概念上的递归。

Shared Context

当两个商业发生交易的时候，通常有一个上下文的关系。这个关系是指定给合作伙办的一个协议，或者是一种商业规则，这样就可以给不同的合作伙伴进行交易。此外，一个商业协作在一段时间内可能调用不同的接口。每一个这样的调用都是处理同一个商业关系的，可能出现在整个商业生命周期中。

在J2EE Web服务中，为这个关系建一个离散的位置是一种建议的实现方法。作为一个开发人员，你应该在复杂的Web服务中需要这样的关系，并且为你的系统结构设计一个离散的组件来控制它。目前这种关系是通过数据库访问（JDBC）来实现的。但是，Context API可以把Web服务中需要对这种关系的访问操作作为一种流控制。这样，这些共享的数据就可以由各种组件来访问，象Servlet, JSP或者EJB组件。

Business Layer

当传送进来的XML数据被转换成Java对象后，这个数据已经准备被传送到EJB商务层做处理。EJB技术是一种用Java来创建商业组件的标准。用EJB组件，你可以从容器中得到一些服务，象安全性，状态保持，连接池，负载平衡以及失败恢复。

在EJB2.0标准中有3中EJB组件：

Session Beans

进行客户端的工作。一般来说，Session Bean生命周期短，执行快速的操作，象提交订单，计算交易税额。

Entity Beans

表现商业数据。一般来说，Entity Bean生命周期长，并且映射到后台的存储介质内，象RDBMS或者OODBMS系统。Entity Bean分为两种类型：bean-managed persistent 和container-managed persistent

MessageDriven Beans

是消息导向组件。它们通过消息导向中间件来接收消息象IBM MQSeries或者TIBCO Rendezvous。消息也可以通过Java客户端利用Java Message Service (JMS) 标准来发送。当消息到达后，一般用JMS API来访问。

一般来说，session beans 通过调用entity bean来完成希望的操作。比方说，一个用来计算订单价格的session bean，可能调用到表示产品和订单的entity bean。 Message-driven beans 用来接收消息，或者传送消息到那些session beans 或者 entity beans.

图6显示了一个EJB组件交互的机制。

你可以用Java Naming和JNDI API来创建，查找以及删除EJB组件。这个API是用来访问J2EE发布系统中外部资源的标准API，可以访问包括数据库驱动，消息中间件，或者创建EJB的程序。

更多 EJB资料，请查阅:

· http://java.sun.com/products/ejb/white/white_paper.html
· http://java.sun.com/products/ejb/
· http://www.theserverside.com
· "Mastering Enterprise JavaBeans" by Ed Roman, published by John Wiley & Sons.

VI. Performing Back-End Integration

最后来讨论用J2EE来开发Web服务的时候，如何与后台系统相连，象数据库，原先的系统和其他的商业伙伴。

Database Connectivity

为了联接关系数据库，开发人员必须选择APIs: The JDBC API 是一个用来访问支持SQL的关系数据库API.。（这个相信大家都知道了。）

SQL/J

是用Java编写的标准的嵌入式SQL。类似于在HTML中嵌入JSP组件。

Legacy System Connectivity

在企业级开发中，与现存的系统相连接，一直都是一个比较困难的任务。大部分企业应用都是一个大杂烩，包含象SAP R/3, Siebel, i2以及一些客户服务系统。整合工作是一个手工任务，因为对现存的系统可用方案并不多。软件独立开发商被要求编写一个在任何平台上都可以运行的客户适配器，但这缺乏一个统一的标准平台。

J2EE Connector Architecture (JCA)

是在工业中应用的，一个针对现存系统的适配器。你可以用它来连接现在的系统，或者编写你自己的适配器。它可以运行在与任何J2EE兼容的环境中。用JCA，你只要编写一个适配器，就可以在任何J2EE环境中运行。对于软件独立开发商来说，这为他们提供了一个整合现存系统的方案。事实上，这些适配器正在开发中，对最终开发者来说，这的确是令人激动的。

Business Partner Connectivity

后台系统的最后一个类型是商业伙伴的Web服务。商业伙伴用全球认定的XML标准来暴露出一些他们自己的系统，在我们发布自己的Web服务时，可能会用到他们的这些服务。一般来说，UDDI用来注册Web服务，WSDL用来描述Web服务，SOAP和ebXML用来处理商务交易。

你的EJB组件可以调用JAP套件来访问商业伙伴的Web服务，这在之前已经介绍过了。

用 Java API for XML Registries (JAXR) 在UDDI注册中心查找商业伙伴的Web服务。

用 Java API for XML RPC (JAX/RPC) 处理到外部Web服务的请求。

用 Java API for XML Messaging (JAXM) 发送SOAP 或者 ebXML 消息到外部Web服务。

用 Java API for XML Parsing (JAXP) and the Java API for XML Binding (JAXB)

把Java数据转换成适用于合作伙伴的XML格式。同样可以用来把合作伙伴那边的数据转换成易于自己处理的XML格式，或者进行XSLT数据转换。

结合使用Java标准APIs和J2EE Web服务构架，我们就可以建立强大的跨平台的系统。利用它们，我们可以与商业伙伴共享数据，提供完整的end-to-end的Web服务解决方案。见图7。