针对SOA将EJB组件公开为业务服务(2)

以下是发送至该服务的 SOAP 1.1 请求以及该服务发出的响应的示例：

 

从以上示例可以清楚地看到：WSDL 和 XML 消息表示是启用服务的主要元素。最重要的是，WSDL 描述了该服务的消息和端口、绑定以及服务定义：

<message name="GetSystemIdInput">ITPUB个人空间2U!H5Koar0S*l Gk <part name="body" element="xsd:logon"/> 3s jsx\thX0</message> <message name="GetSystemIdOutput">ITPUB个人空间`*Ld'Eb <part name="body" element="xsd:authenticatedId"/> g{"^4s)_ UP+e0</message> 2u;Hw0]U0C0 7HZ ?!pjA~Q0<portType name="SystemIdPortType"> p y9t ~EK&z-ys^0<operation name="GetSystemId">ITPUB个人空间,x)ijC;U@,V <input 1J*F@*D(jf;|X0message="tns:GetSystemIdInput"/>ITPUB个人空间Ud z:C3p&X <outputITPUB个人空间OjKq$i"?9gkQ message="tns:GetSystemIdOutput"/> vO2xB\X0</operation>ITPUB个人空间Q'U$G)W3j%D ` </portType>ITPUB个人空间Br1fqo ITPUB个人空间7Pyd/qU'e ..................... <service name="GetSystemIdService">ITPUB个人空间&@l$Jts.i'Vb <port name="SystemIdPort"ITPUB个人空间?#l![@`\|X ..................... U8X-vr#?[/C%]0<port>ITPUB个人空间-b3otG~8~Mz </service>

但这些 WSDL 和 XML 消息表示究竟如何映射到 Java 对象，尤其是 EJB?首先，mapping.xml 文件指定 Java 到 WSDL 映射(例如，程序包名称与 XML 名称空间之间的映射，WSDL 类型与 Java 对象之间的映射等等)。对于 OC4J，该文件由 wsadmin 工具生成，如下所示：

<package-mapping> U6E+x eS0NE%j6R0<package-type>AuthenticateCustomer</package-type> |m1c%]rCZ0<namespaceURI>urn:oracle-ws</namespaceURI> (w)o?,SZ @0</package-mapping>

y
g+mM6a0

然后，创建一个名为 webservices.xml 的部署描述符，并将其置于 ejb-jar 文件的 META-INF 中。该描述符指定了由 J2EE 应用服务器控制的服务描述以及它们与容器功能的相关性：

 

............... <webservice-description> #d u&ezY`S m1w0<webservice-description-name>SystemIdEJB</webservice-description-name> %ss%V#wM p0<wsdl-file>META-INF/GetSystemId.wsdl</wsdl-file> ezw;lk+p\5| f0........... S;tR@ e2l0<port-component>ITPUB个人空间6p&k0w jsL1Jd/x <port-component-name>SystemIdPort</port-component-name>ITPUB个人空间RW _ u{ <wsdl-port>ITPUB个人空间 fZ!{q3dX$~,s <namespaceURI>urn:oracle-ws</namespaceURI>ITPUB个人空间l/DeA_D1P <localpart>SystemIdPort</localpart>ITPUB个人空间Vq[^2bC </wsdl-port>ITPUB个人空间Hi!Gm,PT9U*Wox <service-endpoint-interface>AuthenticateCustomer.GetSystemIdService</service- KkBfx1? Y?`0endpoint-interface>ITPUB个人空间kI IVvm:}A <service-impl-bean> |aw4P"Rzm0<ejb-link>SystemIdEJB</ejb-link>ITPUB个人空间'COa jS </service-impl-bean> Dn7E'_AlA"t%w L aE0</port-component>ITPUB个人空间sC!E0d1o7Vq </webservice-description>

以上示例表明：如果在开发环境中使用适当的工具(如 Oracle 　应用服务器 和 Oracle JDeveloper)，则公开 EJB 的过程将非常简单。但情况并非绝对如此，而且实际的大型分布式应用程序需要模块化、可重用性、可扩展性、可移植性、版本控制、一致性以及可伸缩性的可持续特性。

有关如何利用标准 J2EE 组件(其中的模块功能面向业务服务上下文)以及 Web 服务中不断涌现的技术改进或增强软件开发过程以高效构建高质量的大型应用程序的信息很少。即使我们能够精确地标识“可以服务”的业务功能并拥有所有必要的应用程序和中间件工具，也无法回答下面这个问题：如何在分布式处理元素中安排应用程序功能或职责，以便在使用 Web 服务时最大限度地增强质量功能?

通常情况下，研究 Web 服务的组织利用其现有 Java 对象并直接使用 Web 接口公开它们。最终的结果是不符合 SOA 的要求，且此类实现可以使组织面临以下比较严重的问题：

• 低可重用性—为某个项目开发的服务不易于在其他项目中重用，这是因为它们的结构通常过分依赖于 Web 服务接口的实现。某个服务中的组件之间的依赖性降低了该服务在其他上下文中的可用性。
• 低可扩展性—当出现新功能需要时，很难扩展现有接口，或至少将更改或扩展孤立到一到两个组件。通常情况下必须设计新接口，尤其是当服务控制逻辑集中用于执行消息处理的代码中时。
• 低可伸缩性—很难存档高容量工作负载(例如，每秒钟 1,000 个以上的服务请求)。直接使用 Web 服务接口公开每个对象的细粒度解决方案无法通过经济有效的方式扩展到这样的级别。

要避免此类问题，组织需要部署正确的体系结构模式来帮助创建粗粒度、高度面向业务的 J2EE 组件。

分层的重要性

此处要考虑的主要模式是 EJB 层中的分层。该模式移除了所公开的 Web 服务接口的复杂性。分层的 Web 服务驱动的 EJB 可以通过更简单的面向业务的接口进行设计，而不必将多个接口指向服务集合。从 J2EE 的角度而言，大多数设计人员针对此目的解决方案是使用 Floyd Marinescu 在《EJB Design Patterns:Advanced Patterns, Processes, and Idioms》(由 Wiley 出版社于 2002 年出版)一书中所介绍的 Facade(外观)模式—具体而言，就是创建一个用作外观的会话 EJB，并将组成服务的组件集(即其他 bean，其中的某些 bean 可能是会话 bean 和实体 bean)“包装”起来。这样，服务请求程序将与服务实现的细节分隔开，且会话 EJB 将启用一个“虚拟功能”provide_Service() 方法，该方法不包含业务逻辑并公开一个通用(抽象化)接口。该体系结构方法解除了服务请求程序与服务接口之间的耦合，从而实现了组件的重复使用。它还可以在不同版本的服务存在不同的业务要求时，帮助管理 Web 服务的复杂性。

遗憾地是，在实践中，“外观”模式通常未得到充分地应用，尤其是在以下两种常见的情况下。第一种情况是，用户创建了一个直接包装子系统组件的所有方法的外观，但未提供任何其他抽象。这样的方法是否提供了所需级别的松散耦合?实际上并未提供。松散耦合必须减低总体复杂性，而在这种情况下，复杂性并未降低而只是转移到其他对象。

第二种情况与第一种情况正好相反—开发人员走向了另一个极端，即将会话 bean 中的每个用例包装起来，并向每个 bean 公开一个 Web 服务 API。这样做也不会获得任何好处;其结果是生成了许多体现相似行为的会话 bean(例如，GetAccountBalance、UpdateAccountBalance、TransferFunds、ListAllAccountBalances 等等)，并且在应用程序中，我们需要密切注意所操作的会话 bean。每个用例实现一个会话外观所需的管理投入令人生畏。此外，复杂性不但没有降低，反而进一步增大。