通常情况下，研究 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。每个用例实现一个会话外观所需的管理投入令人生畏。此外，复杂性不但没有降低，反而进一步增大。
要实现一个有助于实现其他一些有利设计可能性的理想松耦合状态，必须进一步改进分层：将上述的服务外观层划分为若干层(即子层)，这些层按顺序进行排列，即层“n + 1”主要由层“n”的外观公开的服务组成(如图 4 所示)将外观嵌套(而非增加)可以对服务粒度进行管理—从粗粒度程度很高的服务到粗粒度程度中等的服务，再到细粒度服务。注意，粗粒度意味着更正式(通用)的接口;粗粒度服务接口提供了子系统(如订单管理、帐户管理、定价等)的抽象表示。此处的主要设计思想是采用一个足以满足需要的多个外观复合结构(其后隐藏了基础业务逻辑的所有细节)。只有该方法才能有效地帮助我们实现一个完全符合 SOA 的解决方案。
<<上一页
1
2
3
4
5
下一页>>
