将 EJB 组件作为商务服务提供

核心提示：设计模式对于面向服务的体系结构具有深远的影响（人们对此尚熟悉不足），因此请明智地选择您的设计模式当机构使用 Web 服务技术构建、部署和组织业务服务时，将 EJB 组件作为商务服务提供，显然必须进行仔细、全面设计 java 2 平台企业版 (J2EE) 应用程序，在这方面，也无法回答下面这个问题：如何在分布式处理元素中

　　设计模式对于面向服务的体系结构具有深远的影响（人们对此尚熟悉不足），因此请明智地选择您的设计模式
　　
　　当机构使用 Web 服务技术构建、部署和组织业务服务时，显然必须进行仔细、全面设计 java 2 平台企业版 (J2EE) 应用程序。在这方面，最有效的帮助是严格应用旨在实现面向服务的体系结构 (SOA) 的体系结构模式。当公开 EnterPRise JavaBean (EJB) 时，此类模式尤其有用。
　　
　　人们通常把模式仅仅看作是为非凡设计问题提供指导的参考工具；而事实上，应将模式看作是体系结构要求的组成部分。它们是影响业务服务（封装了业务规则验证、计算、数据访问以及其他驱动 J2EE 应用程序的核心功能的逻辑）组织决策的起点。除其他适用于 J2EE 的模式和思考方式以外，一些学术界人士、供给商和用户还从 SOA 的角度对闻名的Design Patterns一书（由 Addison-Wesley 出版社于 1994 年出版，作者是 Erich Gamma、Richard Helm、Ralph Johnson 和 John Vlissides —— 通常称之为“四人帮”或“GoF”）中的许多模式进行了再计算和研究。
　　
　　本文将从体系结构的角度介绍最重要的模式及其应用，假设您熟悉以下 Web 服务基础知识：简单对象访问协议 (SOAP)、HTTP、xml、J2EE、EJB、Java 消息服务 (JMS) 等。
　　
　　走进 Web 服务世界
　　从 J2EE 的角度而言，Web 服务基本上是 J2EE 编程模型的扩展（参见图 1），具体体现在：
　　
　　Web 服务继续了符合 J2EE 的应用服务器的容器功能。
　　远程过程调用 (RPC) 样式的 Web 服务通过非会话状态 EJB 公开。
　　消息样式的 Web 服务通过 JMS（JMS 监听程序）和消息驱动的 bean 公开。
　　非会话状态 EJB 或 JMS 被定义为 Web 服务定义语言 (WSDL) 的应用程序入口点，并被部署为 Web 服务。
　　Web 服务客户机使用 WSDL 生成服务请求程序基于 SOAP 的代码。
　　　
　　图 1：J2EE/Web 服务模型
　　首先，我们将简要概述将 EJB 应用程序公开为业务服务的过程。尽管本文使用 Oracle application Server Containers for J2EE (OC4J) 环境，但对于任何其他符合 J2EE 的应用服务器也同样适用。
　　
　　下面，我将介绍一个企业对客户 (B2C) 商务领域中的示例。（参见图 2 和图 3；图 2 描绘了角色交互，图 3 描绘了系统分解。）在该示例中，客户登录到“电子商店”网站，点击感爱好的商品，选择某些要购买的商品，查看订单信息，提供支付信息，最后注销。为简单起见，我省略了大量具体信息—例如，所有表示（Web 层）组件、安全支持等。
　　　
　　图 2：“电子商店”示例—协作图表
　　　
　　图 3：“电子商店”示例—分解图表
　　
　　如图 3 所示，该解决方案包含四种 EJB 子系统（每个子系统包含多个 bean）：
　　
　　客户验证治理： 负责登录/注销、站点注册和客户首选项
　　客户体验治理：负责客户可以在“电子商店”站点执行的所有功能—查看目录、购买商品、付款、查询订单状态等
　　产品清单治理： 负责提供商品可用性和更新存货/脱销数据库以及触发实现进程
　　财务治理： 负责帐目治理和其他财务处理，如开发票。
　　
　　此处最简单的服务可能是基于非会话状态会话 bean SystemIdEJB 的 GetSystemIdService。该 bean 是称作“验证客户”的一组对象类的一部分。假如客户已经成功通过验证，则该 bean 提供稍后用于获取其他客户信息（例如，与商品目录的呈现方式相关的客户首选项）的系统用户 ID。假如客户未成功通过验证，则该 bean 发出例外。
　　
　　以下是发送至该服务的 SOAP 1.1 请求以及该服务发出的响应的示例：
　　
　　POST /SystemId HTTP/1.1
　　Host:eStore.com
　　Content-Type:text/xml; charset="utf-8"
　　Content-Lengthnnnn
　　SOAPAction:"http://eStore.com/getSystemId"
　　
　　<soapenv:Envelope
　　xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
　　<soapenv:Body>
　　<m:GetSystemIdRequest
　　xmlns:m="http://eStore.com/GetSystemId.wsdl/"
　　xmlns:xsd="http://eStore.com/GetSystemId.xsd/">
　　<xsd:logon>LogonID</xsd:logon>
　　</m:GetSystemIdRequest>
　　</soapenv:Body>
　　</soapenv:Envelope>
　　
　　..........
　　<soapenv:Envelope
　　xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
　　<soapenv:Body>
　　<m:GetSystemIdResponse
　　xmlns:m="http://eStore.com/GetSystemId.wsdl/"
　　xmlns:xsd="http://eStore.com/GetSystemId.xsd/">
　　<xsd:authenticatedId>SystemID</xsd:authenticatedId>
　　</m:GetSystemIdResponse>
　　</soapenv:Body>
　　</soapenv:Envelope>
　　
　　从以上示例可以清楚地看到：WSDL 和 XML 消息表示是启用服务的主要元素。最重要的是，WSDL 描述了该服务的消息和端口、绑定以及服务定义： EJB 2.1 和 EJB 3.0
　　
　　J2EE 和 EJB 体系结构的改进速度很快；主要供给商正致力于实现与 J2EE 1.4 和 EJB 2.1 规范保持完全一致。
　　
　　增强对 Web 服务的支持是 EJB 2.1 规范背后的驱动力。例如，EJB 2.1 为将非会话状态会话 bean 公开为 Web 服务提供了显式支持（对于基于 Java 的客户机通过 JAX-RPC API 提供支持，对于非 Java 客户机通过 SOAP 1.1 提供支持）。具体地说，EJB 2.1 规范为非会话状态会话 bean 定义一个新端点，从而显式指示：“端点”实际上是一个通过 SOAP 访问的非会话状态会话 bean。建议的 EJB 3.0 规范通过从 bean 类生成接口进一步改进了该设计思想。
　　
　　尽管 EJB 2.1 使 Web 服务开发的效率得到了显著提高，但对可重用性和灵敏性的要求仍是将 J2EE 组件公开为 Web 服务的主要因素，并且在大型 SOA 实现中仍需要进行仔细的设计。
　　
　　<message name="GetSystemIdInput">
　　<part name="body" element="xsd:logon"/>
　　</message>
　　
　　<message name="GetSystemIdOutput">
　　<part name="body" element="xsd:authenticatedId"/>
　　</message>
　　
　　<portType name="SystemIdPortType">
　　<operation name="GetSystemId">
　　<input
　　message="tns:GetSystemIdInput"/>
　　<output
　　message="tns:GetSystemIdOutput"/>
　　</operation>
　　</portType>
　　.....................
　　
　　<service name="GetSystemIdService">
　　<port name="SystemIdPort"
　　.....................
　　<port>
　　</service>
　　
　　但这些 WSDL 和 XML 消息表示究竟如何映射到 Java 对象，尤其是 EJB？首先，mapping.xml 文件指定 Java 到 WSDL 映射（例如，程序包名称与 XML 名称空间之间的映射，WSDL 类型与 Java 对象之间的映射等等）。对于 OC4J，该文件由 wsadmin 工具生成，如下所示：
　　
　　<package-mapping>
　　<package-type>AuthenticateCustomer</package-type>
　　<namespaceURI>urn:oracle-ws</namespaceURI>
　　</package-mapping>
　　
　　然后，创建一个名为 webservices.xml 的部署描述符，并将其置于 ejb-jar 文件的 META-INF 中。该描述符指定了由 J2EE 应用服务器控制的服务描述以及它们与容器功能的相关性：
　　
　　............
　　
　　<webservice-description>
　　<webservice-description-name>SystemIdEJB</webservice-description-name>
　　<wsdl-file>META-INF/GetSystemId.wsdl</wsdl-file>
　　...........
　　<port-component>
　　<port-component-name>SystemIdPort</port-component-name>
　　<wsdl-port>
　　<namespaceURI>urn:oracle-ws</namespaceURI>
　　<localpart>SystemIdPort</localpart>
　　</wsdl-port>
　　<service-endpoint-interface>AuthenticateCustomer.GetSystemIdService</service-
　　endpoint-interface>
　　<service-impl-bean>
　　<ejb-link>SystemIdEJB</ejb-link>
　　</service-impl-bean>
　　</port-component>
　　</webservice-description>
　　
　　以上示例表明：假如在开发环境中使用适当的工具（如 Oracle 　应用服务器 和 Oracle JDeveloper），则公开 EJB 的过程将非常简单。但情况并非绝对如此，而且实际的大型分布式应用程序需要模块化、可重用性、可扩展性、可移植性、版本控制、一致性以及可伸缩性的可持续特性。
　　
　　有关如何利用标准 J2EE 组件（其中的模块功能面向业务服务上下文）以及 Web 服务中不断涌现的技术改进或增强软件开发过程以高效构建高质量的大型应用程序的信息很少。即使我们能够精确地标识“可以服务”的业务功能并拥有所有必要的应用程序和中间件工具，也无法回答下面这个问题：如何在分布式处理元素中安排应用程序功能或职责，以便在使用 Web 服务时最大限度地增强质量功能？
　　
　　通常情况下，研究 Web 服务的组织利用其现有 Java 对象并直接使用 Web 接口公开它们。最终的结