iweroulsdjf

本文探究了面向服务的体系结构中各种形式的松耦合，并重点介绍什么时候是使用消息驱动 Bean 所提供的异步处理能力的最佳时机。

摘自 IBM WebSphere 开发者技术期刊。

在每个专栏中，EJB 倡导者都采用独特的前后衔接的对话方式与实际客户和开发人员进行交流，并在期间针对某一大家关注的设计问题推荐解决方案。其中并没有介绍任何确定性的细节，也没有提出“新颖的”或专有的体系结构。要了解更多信息，请参见 EJB 倡导者简介。

您对松耦合的定义是否太过狭窄呢？

由于这是 2005 年的最后一篇文章，而且这次交流的是 Java™ Platform、Enterprise Edition (Java EE) 组件而非会话和实体 Bean，所以可以通过这篇文章来很好地总结本专栏所进行的一年之久的讨论，并将所有的组件一起放到完整的面向服务的体系结构中。

问题：太过于关注 SOA 中的会话和实体

亲爱的 EJB 倡导者：

到目前为止您的专栏全部都是关于服务的会话和实体 EJB，它对于直接连接 Java 应用程序是很重要的，例如基于 Web 客户端的 HttpServlets 或富（我们不喜欢说“胖”）客户端的 Swing 应用程序。但我们曾听说面向服务的体系结构都是与松耦合有关的。这不就意味着要尽可能地使用 SOAP 来提供使客户端和服务器应用程序能够独立运行的语言中立性和异步协议？换句话说，为什么您对 JMS 和消息驱动 Bean 讨论得不多呢？

署名：
Feeling Disconnected

对松耦合有许多方面要考虑

亲爱的 Disconnected：

EJB 倡导者关注的是应用程序的服务层，而对客户端介绍得很少，因为我对古谚语形式追随功能 (form follows function) 深信不疑。

其原因在于，许多进行 SOA 的项目之所以失败，是因为它们没有首先建立定义服务的良好模型就开始着手实现细节。

这种倾向相当正常，因为我在 SOA 项目中接触到的大多数人都是架构师和编程人员，他们知道棘手的始终是在细节上，想要尽快解决它们。所以，一旦我们认同好服务的特征是粗粒度、无状态、可通过中介传递和适应的（请参阅 Is it ever best to use EJB components without facades in service oriented architectures?），很明显带有数据传输对象的会话 Bean 就会在实现中扮演重要角色。

但上期专栏介绍了使用实体 Bean 及其 Home 方法代替会话 Bean 的可能性，从而使人们对会话 Bean 是否真的是必需的产生了疑问。图 1 显示了同时使用的两种方法。

图 1 显示了当使用传递过去的会话 Bean 时，纯实体方法（自 EJB 2 开始可用）如何才能有更少的组件和更短的路径长度。其中使用绿色框表示客户端，蓝色框表示各种接口和 Facade 类。橙色框是最常访问的实体 Bean。框和框之间使用双向箭头连接，箭头标有在组件之间通信所使用的协议；蓝色箭头表示相同 JVM 中的 Java 调用，红色箭头表示远程连接（在本例中使用 RMI/IIOP）。为了表示端到端的流向，对流程箭头进行编号，其中 A1-A10 表示从 Java 客户端经过会话 Bean 到实体和返回的流程，B1-B4 表示从客户端直接到实体 Bean 和返回的流程。

客户端用于检索服务接口的编程模型也很简单，虽然在图中没有表示出来。检索会话 Bean 接口需要在 JNDI 上下文中查找会话 Home 并用它创建一个会话；实体 Home 仅仅需要一次查找，其方法可以直接调用而不需要创建对 EJB Object 的引用。以下两段代码示例显示了它们之间的区别。

												
																		
Context initCtx = new InitialContext();
Object obj = initCtx.lookup("java:comp/env/ejb/OrderEntry");       
OrderEntryHome home = (OrderEntryHome)PortableObjectRemote(
	obj, OrderEntryHome.class
);       
OrderEntry ref = home.create();

// Method must be invoked on a session reference
CustomerData data = ref.getOpenOrderForCustomer(cID);

												
										

												
																		
Context initCtx = new InitialContext();
Object obj = initCtx.lookup("java:comp/env/Customer");
CustomerHome ref = (CustomerHome)PortableObjectRemote(
	obj, CustomerHome.class
);

// Note how the method is invoked directly   
CustomerData data = ref.getOpenOrder(cID);

												
										

图 1 和相关的代码示例显示了 Java EE 编程模型的真正好处，不管您是否选择使用实体 Home 方法。编程模型逐渐改进并提供向后兼容。简而言之，您的最佳实践能够得以发展而不必强制更改现有的应用程序。另外，JNDI 上下文提供了一个不容忽视的松耦合相关方面：实现独立性。

会话或实体 EJB 组件的远程接口提供了位置独立性。使用远程接口使得在相同的 JVM 中部署客户端应用程序和服务组件成为可能，其中它对系统（例如使用 HttpServlets 的 Web 应用程序）的响应时间、吞吐量和可维护性目标有意义。图 2 显示的正是这样的配置，其中企业质量应用服务器（如 IBM® WebSphere® Application Server）在联合部署了客户端和服务组件时“短路”远程接口以使用 Java 并按引用传递（不管服务实现为实体 Home 方法还是会话 Bean）。流程 A1-A6 显示了与服务组件联合部署的 HttpServlet 的使用。流程 B1-B4 显示了它如何被远程富客户端 Java EE 应用程序重用。

但这听起来像是您已确定松耦合的最重要方面是语言中立性和异步操作。并且您认为需要异步操作会使得必须在服务器端使用消息驱动 Bean (MDB) 和 JMS。

在实现 MDB 时，许多编程人员使用的方法是通过其远程接口调用表示服务的 EJB 组件，以使上述位置独立性最大化。然后，不管服务实现是远程还是本地部署，MDB 的目的都是作为简单的适配器，将 MQ 层连接到承载服务的 EJB 容器。JMS 可能由异步客户端应用程序（如果它是 Java）或 MDB 使用（通常用于应答队列）。图 3 显示了服务实现的另一个输入通道的这一配置。

流程 C1-C2 与 D1-D6 分别显示，以阐释客户端和服务器流程的独立性。C2 和 D6 只是对 Writer 是否写入消息进行“确认”，并不意味着等待。清单 3 显示了 MDB 的典型结构，该结构应该有助于阐明它必须做的处理：

												
																		
public class OrderSubmitMsgHandler implements MessageDrivenBean {
    private transient MessageDrivenContext context = null;

    // Interface supported by either the session Bean or entity Home
    private transient OrderEntry ref;

    public void ejbCreate() {
        // Cache the home according to either snippet one or two
    }
    public void ejbRemove() {}
    public void setMessageDrivenContext(MessageDrivenContext mdc) {    
        context = mdc; 
    }
    // Message acknowledge and database update participate
    public void onMessage(Message inMessage) {
        // Parse the customer from the message
	try {
	    ref.submit(customer); 
	} 
        catch (CustomerDoesNotExist e) {
            // Send JMS message to reply queue from exception
        }
        catch (OrderNotOpen e) {
            // Send JMS message to reply queue from exception
        }
        catch (OrderHasNoItemsException e) {
            // Send JMS message to reply queue from exception
        }
    }
}
												
										

EJB 倡导者现在将回到您提到过的语言中立性问题。看起来您已经将语言中立性的要求与异步处理的要求紧密联系起来了。没有理由不能将这些考虑分开；解析 SOAP 消息和用它调用会话 Bean 的能力应该与该消息的处理是异步（通过 MQ 或者传递 JMS 等效消息的另一个协议）还是同步（例如通过 HTTP，甚至 IIOP）无关。事实上，Java EE 应用程序上的一些早期“发明”的 Web 服务使用 HttpServlet 来解析通过 HTTP 传递的 XML 消息。这种方法最终发展为 SOAP/HTTP。图 4 显示可以在 EJB 组件所实现的服务之上提供的另一个路径。

Web Service Servlet 和 Message Driven Bean 可以共享对来自从消息串或 HttpServletRequest 提取的流的数据传输对象进行解析的代码。类似地，响应或应答可以共享从数据传输对象（它可以是 Exception 的一个实例）生成流的代码。

希望这有助于您理解 Java EE 组件的布置，所有这些都将提供某种对面向服务的体系结构很基本的松耦合形式。

对话到此结束，
您的 EJB 倡导者

仍然有太多选项要选择

亲爱的 EJB 倡导者：

谢谢。

我以前不认为像 JNDI 这样的服务和远程接口会提供松耦合。我还可以了解如何将 SOAP 和 MQ 的概念“紧耦合”（按照您提到的方法），以及应该如何尽可能将它们分开。所以将解析和生成 SOAP 消息看作由 Web 服务 Servlet 和 MDB 重用的服务本身是很有意义的。

但谢谢，我不要这样。

在这次讨论之前，SOA 看似非常简单：每个服务都公开一个 SOAP/MQ 接口。现在看起来有好多选择要考虑，并且既然将 SOAP 消息的解析和生成看作服务，那么为什么不想建立一个独立的会话 Bean 来封装它们以便如图中所显示的那样进行重用呢？

再次打扰您，我还是：
Still Disconnected

并非一切都是服务：要使用业务模型加以判定

亲爱的 Disconnected：

这次讨论是当过快要着手实现细节时会出现的情况的一个很好的例子。EJB 倡导者专栏 Which type of EJB component should assemble the data returned by a service? 非常重要，因为它描述了一种定义服务的自顶向下方法，这种方法将服务直接与业务流程模型相关联。这里总结这种方法的基本细节：

1. 开发一个业务流程模型，显示重要域对象的生命周期中的主要里程碑：

   1. 我们使用状态转换关系图来描述这一模型，其中状态代表里程碑，转换代表促使变成该状态的事件。转换可以看作应用程序所提供的服务（有关示例请参见图 5）。

   2. 我们使用 UML "Actor" 符号来扩展状态转换关系图，以显示当处于该状态时对象的所有者。状态的所有者负责发起转换，从而驱动应用程序的安全模型（也请参见图 5）。

   3. 对于业务流程中的每个状态，我们也对每个需要支持转换动作的域对象的属性和它们之间的关系进行建模。我们通常使用的符号是 UML 类关系图（有关示例，请参见图 6）。为每个状态建立独立的关系图可以让我们随时对变化的对象“形状”进行建模。这些关系图驱动持久性数据。

2. 开发一个用户界面流程模型，显示在典型“会话”期间来自业务流程的给定参与者如何与系统相交互。

   1. 与业务流程模型一样，我们也使用状态转换关系图，其中状态代表屏幕和对话框，而转换代表实际的 UI 事件，如选择菜单项和按下按钮。根据业务流程转换指定与转换相关的动作。

   2. 还是和业务流程模型一样，我们构建一个类关系图来显示必须在每个状态中可见的数据以支持各种选择。这意味着该数据必须可以从用户输入派生，并以自顶向下的方式驱动服务上的读取操作。

   3. 与业务流程模型不同，我们不需要用 Actor 符号扩展状态关系图，因为关系图本身可以视为单个用户角色的“生命中的一天 (day in the life)”。

这种综合方法可以确保：

• 将正确的操作分组到一个服务（与业务流程生命周期中的一个状态相关联的所有转换和 read 方法）。

• 每个服务的用途很好理解（根据相关业务对象来指定动作）。

• 调用服务需要的前置条件和会产生的后置条件是相通的（当前状态和可选的监护、以及下一状态都是通过转换指定的）。

• 标识了负责调用服务的用户角色（参与者与每个状态相关联）。

不管是否实现，方法签名都不会提供此信息，但此信息对于好的 SOA 来说是很关键的。否则，编程人员将陷入另一种倾向：一旦有怀疑，就再次构建。因为 SOA 的开发成本比较高（要为图 4 所示的完全松耦合提供各种中介器和适配器），所以这种反对重用的倾向可能会导致获得好处最少。

对您关于简单性的答复中提出的问题的回答是，此信息一点都没有强制您以某种方式公开接口，EJB 倡导者知道简单只存在于旁观者眼中。如果您想要使服务开发人员不必进行选择，只需为每个服务提供图 5 中所示的所有“蓝色”组件即可：

• 远程服务接口，用于提供同步 Java EE 客户端访问服务操作的位置独立性。

• 与每个操作相关联的 MDB，通过遵循 JMS 的 MQ 实现来提供异步非 Java 客户端访问。您可以选择编写此 MDB 或不同的 MDB 以期待 JMS 客户端的 Java 消息（从而避免 HTTP 解析开销）。

• 与每个操作相关联的 Web 服务 Servlet，用于提供同步 SOAP over HTTP 客户端访问。

因为有人会担心这种方法将生成大量未使用的组件，所以另一种简单的方法是，应用 EJB 倡导者喜欢的内容来调用面向客户端的体系结构 (COA)；以对客户端最自然的方式给它们提供使用服务正好需要的内容。

这种 COA 方法需要考虑业务流程和 UI 模型的细节，以便为每种方法挑选最可能的候选者。例如：

• 业务流程生命周期中的状态之间的转换很可能是异步服务的候选者，因为它们将是相关域对象的“所有者”变体。例如，在 open 订单应用程序（我们在上述示例中调用此 OrderEntry）中，submit 方法可以简单地将订单的状态更改为“submitted”，并发送一条 JMS 消息来将其复制到已提交订单应用程序中（我们将这称为一次 OrderFulfillment）。

• 状态间的转换通常应该是同步的，因为所有者没有改变。举个例子来说明为什么这些操作不应该是异步的，设想一下，如果您进入一位书商的 Web 应用程序，还必须轮询或等待发布-订阅事件来显示目录或将物品添加到购物车中！对于想要通过异步通道使用伪同步方式的读者，请查阅 Bobby Woolf 关于设计消息传递系统的书籍。

• 只有对于没有相关的非 Java 客户端和服务的集成场景，才提供 SOAP over HTTP 或 MQ。

使用 COA 方法，可以“准时 (just-in-time)”开发组件，这就是 EJB 倡导者喜欢推荐它的原因。

对您的问题（为什么不将所有的东西都看作是服务，甚至是与中介器和适配器相关联的转换）的回答的最后一点是：简单的回答超出了“过犹不及”这一事实。在开发 SOA 或 COA Java EE 应用程序时，最好将服务视为业务流程模型上的操作。服务与应用程序的功能需求有关。中介和相关联的转换与非功能需求有关，例如可靠性、可用性、有效性、可维护性和可移植性。如果您将中介或相关联的转换视作第一个类服务，则最终将使应用程序的真实用途变得模糊。

我知道这其中有很多方面的内容需要理解，所以当您应用这些方法时，遇到相关细节问题不要嫌麻烦，尽管与我联系。

对话到此结束，
您的 EJB 倡导者。

结束语

这些交流中谈论了 Java EE 如何为采用面向服务的体系结构的应用程序提供完整的实现框架，其中每个组件或 API 都在一些“松耦合”方面扮演重要角色：

• 操作系统独立性是由 Java 本身提供的，因为 Java 为组件提供“一次编写，到处运行”的语言，使得您的代码与基础操作系统相分离。

• 实现独立性是由 Java Naming 和 Directory Interface (JNDI) 提供的，它具备在运行时将逻辑名称绑定到实现的能力。

• 位置独立性是由远程接口使用 RMI over IIOP 提供给无状态会话 Bean 或封装服务的实体 Home 方法的。RMI/IIOP 是一个相当快的有状态连接，但扩展性不那么好。

• Web 服务器独立性是由 HttpServlets 提供的，它可以响应同步 HTTP 协议。与 RMI/IIOP 不同的是，HTTP（通常）是一个扩展性很好的无状态协议，但由于消息大小的限制，而且每次都需要在客户端和服务器之间建立和取消连接，所以不能执行得很好。

• 应用独立性是由异步 Java Messaging Service（或非 Java 客户端的 MQ）和消息驱动 Bean 提供的（用于队列处理程序）。

• 语言独立性是由标准消息格式（如 SOAP）提供的，不管它是在 RMI/IIOP、HTTP 还是 MQ 上传递。因此，SOAP 可以被每个组件使用，但只有在需要时才使用它，这一点很重要。

相信您可以找到其他方法，我们乐意看到这样的结果。困难的是需要处理与每种方法相关联的权衡。这应该能够让您忙到明年。