用J2EE开发WebService（3）

答案：请注意，在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服务的时候，如何与后台系统相连，象数据库，原先的系统和其他的商业伙伴。 

上一个：用J2EE开发WebService（2）
下一个：用J2EE开发WebService（4）