使用Java EE 实现松耦合的 SOA 运用程序新

EJB倡导者:使用JavaEE实现松耦合的SOA应用程序级别：中级GeoffHambrick(ghambric@us.ibm.com),杰出工程师,IBM2006年2月13日本文探究了面向服务的体系结构中各种形式的松耦合，并重点介绍什么时候是使用消息驱动Bean所提供的异步处理能力的最佳时机。摘自IBMWebSphere开发者技术期刊。在每个专栏中，EJB倡导者都采用独特的前后衔接的对话方式与实际客户和开发人员进行交流，并在期间针对某一大家关注的设计问题推荐解决。其中并没有介绍任何确定性的细节，也没有提出“新颖的”或专有的体系结构。要了解更多信息，请参见EJB倡导者简介。您对松耦合的定义是否太过狭窄呢？由于这是2005年的最后一篇文章，而且这次交流的是Java™Platform、EnterpriseEdition(JavaEE)组件而非会话和实体Bean，所以可以通过这篇文章来很好地本专栏所进行的一年之久的讨论，并将所有的组件一起放到完整的面向服务的体系结构中。问题：太过于关注SOA中的会话和实体亲爱的EJB倡导者：到目前为止您的专栏全部都是关于服务的会话和实体EJB，它对于直接连接Java应用程序是很重要的，例如基于Web客户端的HttpServlets或富（我们不喜欢说“胖”）客户端的Swing应用程序。但我们曾听说面向服务的体系结构都是与松耦合有关的。这不就意味着要尽可能地使用SOAP来提供使客户端和服务器应用程序能够独立运行的语言中立性和异步？换句话说，为什么您对JMS和消息驱动Bean讨论得不多呢？署名：FeelingDisconnected对松耦合有许多方面要考虑亲爱的Disconnected：EJB倡导者关注的是应用程序的服务层，而对客户端介绍得很少，因为我对古谚语形式追随功能(formfollowsfunction)深信不疑。其原因在于，许多进行SOA的项目之所以失败，是因为它们没有首先建立定义服务的良好模型就开始着手实现细节。这种倾向相当正常，因为我在SOA项目中接触到的大多数人都是架构师和编程人员，他们知道棘手的始终是在细节上，想要尽快解决它们。所以，一旦我们认同好服务的特征是粗粒度、无状态、可通过中介传递和适应的（请参阅IsiteverbesttouseEJBcomponentswithoutfacadesinserviceorientedarchitectures?），很明显带有数据传输对象的会话Bean就会在实现中扮演重要角色。Page1of8EJB倡导者:使用JavaEE实现松耦合的SOA应用程序2009-9-15http://www.ibm.com/developerworks/cn/websphere/techjournal/0512_ejba/0512_ejba....但上期专栏介绍了使用实体Bean及其Home方法代替会话Bean的可能性，从而使人们对会话Bean是否真的是必需的产生了疑问。图1显示了同时使用的两种方法。图1.用有待使用的会话和实体EJB实现的服务图1显示了当使用传递过去的会话Bean时，纯实体方法（自EJB2开始可用）如何才能有更少的组件和更短的路径长度。其中使用绿色框表示客户端，蓝色框表示各种接口和Facade类。橙色框是最常访问的实体Bean。框和框之间使用双向箭头连接，箭头标有在组件之间通信所使用的协议；蓝色箭头表示相同JVM中的Java调用，红色箭头表示远程连接（在本例中使用RMI/IIOP）。为了表示端到端的流向，对流程箭头进行编号，其中A1-A10表示从Java客户端经过会话Bean到实体和返回的流程，B1-B4表示从客户端直接到实体Bean和返回的流程。客户端用于检索服务接口的编程模型也很简单，虽然在图中没有表示出来。检索会话Bean接口需要在JNDI上下文中查找会话Home并用它创建一个会话；实体Home仅仅需要一次查找，其方法可以直接调用而不需要创建对EJBObject的引用。以下两段代码示例显示了它们之间的区别。清单1.定位和调用远程会话EJB方法清单2.定位和调用等效远程实体EJBHome方法图1和相关的代码示例显示了JavaEE编程模型的真正好处，不管您是否选择使用实体Home方法。编程模型逐渐改进并提供向后兼容。简而言之，您的最佳实践能够得以发展而不必强制更改现有的应用程序。另外，JNDI上下文提供了一个不容忽视的松耦合相关方面：实现独立性。会话或实体EJB组件的远程接口提供了位置独立性。使用远程接口使得在相同的JVM中部署客户端应用程序和服务组件成为可能，其中它对系统（例如使用HttpServlets的Web应用程序）的响应时间、吞吐量和可维护性目标有意义。图2显示的正是这样的配置，其中企业质量应用服务器（如IBM®WebSphere®ApplicationServer）在联合部署了客户端和服务组件时“短路”远ContextinitCtx=newInitialContext();Objectobj=initCtx.lookup("java:comp/env/ejb/OrderEntry");OrderEntryHomehome=(OrderEntryHome)PortableObjectRemote(obj,OrderEntryHome.class);OrderEntryref=home.create();//MethodmustbeinvokedonasessionreferenceCustomerDatadata=ref.getOpenOrderForCustomer(cID);ContextinitCtx=newInitialContext();Objectobj=initCtx.lookup("java:comp/env/Customer");CustomerHomeref=(CustomerHome)PortableObjectRemote(obj,CustomerHome.class);//NotehowthemethodisinvokeddirectlyCustomerDatadata=ref.getOpenOrder(cID);Page2of8EJB倡导者:使用JavaEE实现松耦合的SOA应用程序2009-9-15http://www.ibm.com/developerworks/cn/websphere/techjournal/0512_ejba/0512_ejba....程接口以使用Java并按引用传递（不管服务实现为实体Home方法还是会话Bean）。流程A1-A6显示了与服务组件联合部署的HttpServlet的使用。流程B1-B4显示了它如何被远程富客户端JavaEE应用程序重用。图2.部署到本地Web应用程序和远程富客户端的服务但这听起来像是您已确定松耦合的最重要方面是语言中立性和异步操作。并且您认为需要异步操作会使得必须在服务器端使用消息驱动Bean(MDB)和JMS。在实现MDB时，许多编程人员使用的方法是通过其远程接口调用表示服务的EJB组件，以使上述位置独立性最大化。然后，不管服务实现是远程还是本地部署，MDB的目的都是作为简单的适配器，将MQ层连接到承载服务的EJB容器。JMS可能由异步客户端应用程序（如果它是Java）或MDB使用（通常用于应答队列）。图3显示了服务实现的另一个输入通道的这一配置。图3.用提供异步客户端通道的MDB部署的服务流程C1-C2与D1-D6分别显示，以阐释客户端和服务器流程的独立性。C2和D6只是对Writer是否写入消息进行“确认”，并不意味着等待。清单3显示了MDB的典型结构，该结构应该有助于阐明它必须做的处理：清单3.典型的消息驱动Bean实现publicclassOrderSubmitMsgHandlerimplementsMessageDrivenBean{privatetransientMessageDrivenContextcontext=null;//InterfacesupportedbyeitherthesessionBeanorentityHomeprivatetransientOrderEntryref;publicvoidejbCreate(){Page3of8EJB倡导者:使用JavaEE实现松耦合的SOA应用程序2009-9-15http://www.ibm.com/developerworks/cn/websphere/techjournal/0512_ejba/0512_ejba....EJB倡导者现在将回到您提到过的语言中立性问题。看起来您已经将语言中立性的要求与异步处理的要求紧密联系起来了。没有理由不能将这些考虑分开；解析SOAP消息和用它调用会话Bean的能力应该与该消息的处理是异步（通过MQ或者传递JMS等效消息的另一个协议）还是同步（例如通过HTTP，甚至IIOP）无关。事实上，JavaEE应用程序上的一些早期“发明”的Web服务使用HttpServlet来解析通过HTTP传递的XML消息。这种方法最终发展为SOAP/HTTP。图4显示可以在EJB组件所实现的服务之上提供的另一个路径。图4.将语言中立性和异步性的考虑分开WebServiceServlet和MessageDrivenBean可以共享对来自从消息串或HttpServletRequest提取的流的数据传输对象进行解析的代码。类似地，响应或应答可以共享从数据传输对象（它可以是Exception的一个实例）生成流的代码。希望这有助于您理解JavaEE组件的布置，所有这些都将提供某种对面向服务的体系结构很基本的松耦合形式。对话到此结束，//Cachethehomeaccordingtoeithersnippetoneortwo}publicvoidejbRemove(){}publicvoidsetMessageDrivenContext(MessageDrivenContextmdc){context=mdc;}//MessageacknowledgeanddatabaseupdateparticipatepublicvoidonMessage(MessageinMessage){//Parsethecustomerfromthemessagetry{ref.submit(customer);}catch(CustomerDoesNotExiste){//SendJMSmessagetoreplyqueuefromexception}catch(OrderNotOpene){//SendJMSmessagetoreplyqueuefromexception}catch(OrderHasNoItemsExceptione){//SendJMSmessagetoreplyqueuefromexception}}}Page4of8EJB倡导者:使用JavaEE实现松耦合的SOA应用程序2009-9-15http://www.ibm.com/developerworks/cn/websphere/techjournal/0512_ejba/0512_ejba....您的EJB倡导者仍然有太多选项要选择亲爱的EJB倡导者：谢谢。我以前不认为像JNDI这样的服务和远程接口会提供松耦合。我还可以了解如何将SOAP和MQ的概念“紧耦合”（按照您提到的方法），以及应该如何尽可能将它们分开。所以将解析和生成SOAP消息看作由Web服务Servlet和MDB重用的服务本身是很有意义的。但谢谢，我不要这样。在这次讨论之前，SOA看似非常简单：每个服务都公开一个SOAP/MQ接口。现在看起来有好多选择要考虑，并且既然将SOAP消息的解析和生成看作服务，那么为什么不想建立一个独立的会话Bean来封装它们以便如图中所显示的那样进行重用呢？再次打扰您，我还是：StillDisconnected并非一切都是服务：要使用业务模型加以判定亲爱的Disconnected：这次讨论是当过快要着手实现细节时会出现的情况的一个很好的例子。EJB倡导者专栏WhichtypeofEJBcomponentshouldassemblethedatareturnedbyaservice?非常重要，因为它描述了一种定义服务的自顶向下方法，这种方法将服务直接与业务流程模型相关联。这里总结这种方法的基本细节：1.开发一个业务流程模型，显示重要域对象的生命周期中的主要里程碑：a.我们使用状态转换关系图来描述这一模型，其中状态代表里程碑，转换代表促使变成该状态的事件。转换可以看作应用程序所提供的服务（有关示例请参见图5）。b.我们使用UML"Actor"符号来扩展状态转换关系图，以显示当处于该状态时对象的所有者。状态的所有者负责发起转换，从而驱动应用程序的安全模型（也请参见图5）。c.对于业务流程中的每个状态，我们也对每个需要支持转换动作的域对象的属性和它们之间的关系进行建模。我们通常使用的符号是UML类关系图（有关示例，请参见图6）。为每个状态建立独立的关系图可以让我们随时对变化的对象“形状”进行建模。这些关系图驱动持久性数据。2.开发一个用户界面流程模型，显示在典型“会话”期间来自业务流程的给定参与者如何与系统相交互。a.与业务流程模型一样，我们也使用状态转换关系图，其中状态代表屏幕和对话框，而转换代表实际的UI事件，如选择菜单项和按下按钮。根据业务流程转换指定与转换相关的动作。b.还是和业务流程模型一样，我们构建一个类关系图来显示必须在每个状态中可见的数据以支持各种选择。这意味着该数据必须可以从用户输入派生，并以自顶向下的方式驱动服务上的读取操作。c.与业务流程模型不同，我们不需要用Actor符号扩展状态关系图，因为关系图本身可Page5of8EJB倡导者:使用JavaEE实现松耦合的SOA应用程序2009-9-15http://www.ibm.com/developerworks/cn/websphere/techjournal/0512_ejba/0512_ejba....以视为单个用户角色的“生命中的一天(dayinthelife)”。图5.显示订单生命周期的状态转换关系图示例图6.显示open订单“形状”的类关系图示例这种综合方法可以确保：z将正确的操作分组到一个服务（与业务流程生命周期中的一个状态相关联的所有转换和read方法）。z每个服务的用途很好理解（根据相关业务对象来指定动作）。z调用服务需要的前置条件和会产生的后置条件是相通的（当前状态和可选的监护、以及下一状态都是通过转换指定的）。z标识了负责调用服务的用户角色（参与者与每个状态相关联）。不管是否实现，方法签名都不会提供此信息，但此信息对于好的SOA来说是很关键的。否则，编程人员将陷入另一种倾向：一旦有怀疑，就再次构建。因为SOA的开发成本比较高（要为图4所示的完全松耦合提供各种中介器和适配器），所以这种反对重用的倾向可能会导致获得好处最少。对您关于简单性的答复中提出的问题的回答是，此信息一点都没有强制您以某种方式公开接口，EJB倡导者知道简单只存在于旁观者眼中。如果您想要使服务开发人员不必进行选择，只需为每个服务提供图5中所示的所有“蓝色”组件即可：Page6of8EJB倡导者:使用JavaEE实现松耦合的SOA应用程序2009-9-15http://www.ibm.com/developerworks/cn/websphere/techjournal/0512_ejba/0512_ejba....z远程服务接口，用于提供同步JavaEE客户端访问服务操作的位置独立性。z与每个操作相关联的MDB，通过遵循JMS的MQ实现来提供异步非Java客户端访问。您可以选择编写此MDB或不同的MDB以期待JMS客户端的Java消息（从而避免HTTP解析开销）。z与每个操作相关联的Web服务Servlet，用于提供同步SOAPoverHTTP客户端访问。因为有人会担心这种方法将生成大量未使用的组件，所以另一种简单的方法是，应用EJB倡导者喜欢的内容来调用面向客户端的体系结构(COA)；以对客户端最自然的方式给它们提供使用服务正好需要的内容。这种COA方法需要考虑业务流程和UI模型的细节，以便为每种方法挑选最可能的候选者。例如：z业务流程生命周期中的状态之间的转换很可能是异步服务的候选者，因为它们将是相关域对象的“所有者”变体。例如，在open订单应用程序（我们在上述示例中调用此OrderEntry）中，submit方法可以简单地将订单的状态更改为“submitted”，并发送一条JMS消息来将其复制到已提交订单应用程序中（我们将这称为一次OrderFulfillment）。z状态间的转换通常应该是同步的，因为所有者没有改变。举个例子来说明为什么这些操作不应该是异步的，设想一下，如果您进入一位书商的Web应用程序，还必须轮询或等待发布-订阅事件来显示目录或将物品添加到购物车中！对于想要通过异步通道使用伪同步方式的读者，请查阅BobbyWoolf关于设计消息传递系统的书籍。z只有对于没有相关的非Java客户端和服务的集成场景，才提供SOAPoverHTTP或MQ。使用COA方法，可以“准时(just-in-time)”开发组件，这就是EJB倡导者喜欢推荐它的原因。对您的问题（为什么不将所有的东西都看作是服务，甚至是与中介器和适配器相关联的转换）的回答的最后一点是：简单的回答超出了“过犹不及”这一事实。在开发SOA或COAJavaEE应用程序时，最好将服务视为业务流程模型上的操作。服务与应用程序的功能需求有关。中介和相关联的转换与非功能需求有关，例如可靠性、可用性、有效性、可维护性和可移植性。如果您将中介或相关联的转换视作第一个类服务，则最终将使应用程序的真实用途变得模糊。我知道这其中有很多方面的内容需要理解，所以当您应用这些方法时，遇到相关细节问题不要嫌麻烦，尽管与我联系。对话到此结束，您的EJB倡导者。结束语这些交流中谈论了JavaEE如何为采用面向服务的体系结构的应用程序提供完整的实现框架，其中每个组件或API都在一些“松耦合”方面扮演重要角色：z操作系统独立性是由Java本身提供的，因为Java为组件提供“一次编写，到处运行”的语言，使得您的代码与基础操作系统相分离。z实现独立性是由JavaNaming和DirectoryInterface(JNDI)提供的，它具备在运行时将逻辑名称绑定到实现的能力。z位置独立性是由远程接口使用RMIoverIIOP提供给无状态会话Bean或封装服务的实体Home方法的。RMI/IIOP是一个相当快的有状态连接，但扩展性不那么好。zWeb服务器独立性是由HttpServlets提供的，它可以响应同步HTTP协议。与RMI/IIOP不同的是，HTTP（通常）是一个扩展性很好的无状态协议，但由于消息大小的限制，而且每次都需要在客户端和服务器之间建立和取消连接，所以不能执行得很好。Page7of8EJB倡导者:使用JavaEE实现松耦合的SOA应用程序2009-9-15http://www.ibm.com/developerworks/cn/websphere/techjournal/0512_ejba/0512_ejba....IBM公司保留在developerWorks网站上发表的内容的著作权。未经IBM公司或原始作者的书面明确许可，请勿转载。如果您希望转载，请通过提交转载请求表单联系我们的编辑团队。z应用独立性是由异步JavaMessagingService（或非Java客户端的MQ）和消息驱动Bean提供的（用于队列处理程序）。z语言独立性是由标准消息格式（如SOAP）提供的，不管它是在RMI/IIOP、HTTP还是MQ上传递。因此，SOAP可以被每个组件使用，但只有在需要时才使用它，这一点很重要。相信您可以找到其他方法，我们乐意看到这样的结果。困难的是需要处理与每种方法相关联的权衡。这应该能够让您忙到明年。参考资料z您可以参阅本文在developerWorks全球站点上的英文。zJavaPlatform,EnterpriseEdition(JEE)specification(formerlyJ2EE)；这里将“2”去掉是为了将用于企业的Java平台的主要概念与具体的版本分开。zEnterpriseJavaProgrammingwithIBMWebSphere,SecondEdition，KyleBrown、GaryCraig、GregHester、RussellStinehour、W.DavidPitt、MarkWeitzel、JimAmsden、PeterM.Jakab和DanielBerg著。前言由MartinFowler撰写。zEnterpriseIntegrationPatterns:Designing,Building,andDeployingMessagingSolutions，GregorHohe和BobbyWolfe著。包含大量与消息传递应用程序相关联的很好的模式和反模式。关于作者GeoffHambrick是IBM软件服务部WebSphereEnablementTeam的首席顾问，居住在德克萨斯州的RoundRock（在奥斯汀附近）。EnablementTeam通常通过深入的技术讲座及短期概念验证为售前流程提供支持。Geoff于2004年3月被选为IBM的杰出工程师，他的工作是创建并传播在IBMWebSphereApplicationServer上开发J2EE应用程序的最佳实践。Page8of8EJB倡导者:使用JavaEE实现松耦合的SOA应用程序2009-9-15http://www.ibm.com/developerworks/cn/websphere/techjournal/0512_ejba/0512_ejba....