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。