为EAI选择JCA、JMS或Web服务

　　引言

　　组织在迅速地发展，他们试图在控制成本的同时满足变化的业务需求。这意味着企业需要以支持信息系统的简易重组的方式来组织他们自己的应用程序。重要的组织变化(例如兼并或子公司的创建)也有可能把新的变数引入信息系统。

　　企业还可能需要到市场上购买应用程序或签定他们的部分业务需求的转包合同(例如分类帐或 back-office 管理)。无法保证现有的技术框架支持这些服务。

　　随着信息系统变得越来越复杂，开发必须被简化。这使人们对 企业应用程序集成(Enterprise Application Integration，EAI)产生了兴趣。企业仍然必须用业务服务和访问新的集成应用程序的灵活方式来补充 EAI。

　　目前，基于接口的体系结构考虑了这种对业务服务的灵活访问和客户机独立性的不断增长的需求。基于接口的体系结构包括 Web 服务、 J2C 连接器体系结构(J2C Connector Architecture，JCA;)和 Java 消息服务(Java Message Service，JMS)等技术。它们还包括分离客户机代码和业务服务的实现的命令模式的所有变种。这些调用框架与 EAI 中间件之间可以相互调用。

　　在本文中，我们先讨论每个接口技术的主要特点，然后讲述促使您选择技术的要求。读完本文后，您将理解如何定位各种技术以及如何为某个实现选择其中的一种技术。

　　Web 服务、JCA 和 JMS 的特点

　　这一部分列出有关的接口技术并详细介绍它们的一些特点。

　　Web 服务

　　Web 服务是面向服务的体系结构(Services Oriented Architecture，SOA)的实现。SOA 有松耦合的三方：提供者、代理和请求者。提供者提供的业务服务表示请求者无法直接看到的某个实现。请求者从代理那里了解它必须从提供者那里收发的信息结构以及访问该服务所用的协议。请求者一点也不了解提供者实现业务服务的方式。

　　Web 服务被定义为请求者与提供者之间的必需的业务接口而不是所有业务请求的共同管道。有些变数反映了 Web 服务的特点，包括：

　　它们可以是紧耦合的，它们的部署可以基于调用框架的使用。

　　它们以同步的请求/应答方式或异步方式来执行。

　　它们可由 J2EE 或非 J2EE 的提供程序来公开。

　　它们可能提供事务和安全 style="COLOR: #000000" href="http://safe.it168.com/" target=_blank>安全性的支持(也可能不提供这种支持)。

　　JCA

　　Java 连接器体系结构主要处理的是以紧耦合的方式访问 企业信息系统(Enterprise Information System，EIS)的业务逻辑的需求。连接器体系结构提供了资源适配的支持，资源适配把 J2EE 安全性、事务和通信共享映射到相应的 EIS 技术。

　　起初，人们的意图是让连接器以同步的请求/应答方式来访问大型机上的旧的事务服务器 style="COLOR: #000000" href="http://server.it168.com/" target=_blank>服务器，这也是当前多数连接器的工作方式。目前，标准的发展方向是更异步的双向连接性。

　　连接器的某些用户定义的变种更成熟，它们运行在逻辑连接方式下。同样，它们可被用作调用框架，以类似于 Web 服务的方式来选择适当的物理 EIS 目标和业务操作。

　　JMS

　　JMS 是异步的、基于消息的接口。您还可以使用 JMS 来访问分布于不同种类的系统中的业务逻辑。基于消息的接口支持以下功能：

　　点到点和发布/预订机制。基于消息的框架可把信息传给其它应用程序而这些程序不必显式地请求它。相同的信息可被并行地传递给许多订户。

　　节奏的独立性。JMS 框架以异步方式运行，但也提供模拟同步的请求/响应方式的功能。这使源系统和目标系统能够同时运行而不必等待对方。

　　有保证的信息传递。JMS 框架可在事务方式下管理消息并确保消息的传递(但不确保传递的及时性)。

　　不同种类的框架之间的互操作性。源应用程序和目标应用程序可在不同种类的环境中运行而不必处理有关它们相应的框架的通信和执行问题。

　　使交换更流畅。改用消息方式后，信息交换的细粒度变细。

　　选择接口技术

　　您过去在系统中实现业务逻辑的方式将使您自然地面对这些技术中的一种技术。作出选择的第一步是分析您现有的基础结构。有现有的消息传递系统或旧系统(例如 CICS 或 IMS)吗?

　　在许多情况下，访问大型机 EIS(例如 CICS 或 IMS)的最自然的方式是通过 Java 连接器体系结构。另一方面，如果您需要访问 .NET 应用程序，那么您很可能倾向于 Web 服务接口。在其它情况下，您可能使用 JMS 接口，该接口允许消息的交换而且对实现语言的约束很小。

　　请使用以下的决定要点的摘要：

　　您有现有的 Java 应用程序或在规划新的 Java 应用程序：使用 JMS 或 JCA。

　　您需要与伙伴交互：把 Web 服务用于传输和连接。

　　您需要跨越语言之间的障碍：使用 JMS 或 Web 服务。

　　在作出决定时，另一个要考虑的因素是网络的范围：是因特网、内部网或外部网中的哪个?该范围决定了您在选择传输协议时的灵活性。因特网上的部署很可能需要通过 HTTP 的松耦合的 Web 服务。这将与现有的防火墙和 非军事区(demilitarized zone，DMZ)基础结构相配套，您可以最大限度地降低成本。JMS 和 JCA 更适合作为内部网或外部网协议。JMS 适合用于异步方式或模拟的同步方式，JCA 适合用于更紧的耦合。

　　选择的共同点

　　Web 服务不是通过 SOAP 提供的服务的同义词。您可以把任何带有它的功能的 Web 服务描述语言(Web services Description Language，WSDL)描述的代码和访问协议看作 Web 服务。您可以通过多个传输和协议来提供任何这种服务。

　　因此，您可以采用以 WSDL 为中心的方式，这一方式由 Web 服务调用框架(Web services Invocation Framework，WSIF)来描述和实现。无论网络的范围(内部网、外部网或因特网)，这把您为集成作出的选择联系在一起。

　　您很可能试图把更多的选择留到未来的扩展规划中，包括现有企业系统的扩展或连接到业务伙伴。为了简化这种做法，您可以在一个 WSDL 文档中描述相同的业务组件，您可以：

　　通过 入站绑定(inbound binding)概念，在不同的协议(例如 SOAP 和 RMI-IIOP)中提供。RMI 是 Java 远程消息调用。因特网 ORB 间协议(Internet Inter-ORB protocol，IIOP)是 CORBA 有线协议。

　　通过 出站绑定(outbound binding)概念，用不同类型的组件(例如 JCA 或基于 JMS 的组件)来实现。

　　如果使用这种方式，那么 JMS 和 JCA 只是服务器提供程序可能用来实现业务组件的几个协议。因此，不同网络和接口技术只影响非功能性的部分，例如安全性、性能、响应时间和可用性。当内部网和因特网上的相同组件可被使用时，两个网络的区别是所需的安全性、预期的性能和要求的可用性。

　　Web 服务的以 WSDL 为中心的方式使您能够把抽象的接口从确切的协议栈中分离出来。您可以用两种方法来实现这种方式(两种方法都利用 WSIF)：

　　通过使用 IBM Web Services Gateway(WSGW)，现有的 WSDL 描述被部署并在 SOAP 通道中使用 WSDL 描述。入站绑定是 SOAP，出站绑定是现有的 WSDL 实现描述。

　　通过使用 IBM WebSphere Studio Application Developer Integration Edition(WSAD-IE)，现有的 WSDL 描述被消耗并通过 SOAP 或 RMI-IIOP 代理来使用 WSDL 描述。

　　交互模式

　　在设计应用程序时，您需要定义交互的模式。一般来说，这些模式揭示了您对技术集成的偏爱。

　　事件驱动的推模型

　　等待事件的侦听器提供了标准的事件推模型，该模型对于 EAI 特别重要。业务流程的自动化常常需要捕获应用程序事件以便传播到其它的集成应用程序。

　　标准的业务服务的侦听器常常使用 JMS 或 HTTP 服务器。EJB 中的消息驱动 Bean 使用 JMS，而 Web 服务使用 HTTP。

　　在这个推模型中，被推的事件触发流程。Web 服务社区已为正式定义这种流程交互的先后顺序做了大量的工作。具体地说， Web 服务流程语言(Web services Flow Language，WSFL)和 Web 服务的业务流程执行语言(Business Process Execution Language for Web services，BPEL4WS)标准可处理这种事件排序。

　　在 WSFL 中，作为对进入消息的响应，流程引擎可以执行新的流程实例(以 spawn生命周期操作为标志)。它对单向交互的支持提供了对通知的支持。

　　在 BPEL4WS 中，作为对进入消息的响应， receive或 pick活动可隐式地启动业务流程; pick活动可根据一组事件中的一件来选择运行的流程。

　　同步的请求/应答方式

　　在企业中，性能要求可能促使您选择 JCA 实现，特别是在目前多数业务逻辑在某个现有的 EIS 中的时候，更是这样。然而，并没有访问所有系统的连接器，在有些情况下，用 JMS 来添加消息层是唯一的解决方案。

　　消息传递不是请求/响应类型交互的主要选择。由于消息传递所带来的隔离，用消息传递中间件实现的请求/响应阻碍了调用者与被调者之间的事务协调。另外，调用者的编程逻辑(而不是提供的连接器实现)必须管理响应超时。

　　异步模型

　　所有三个接口技术(Web 服务、JMS 甚至 JCA)都可在异步方式下工作。请求或事件被发送至目标而所期待的回答只不过是“消息被正确地传递”。它是“发送并忘记(fire-and-forget)”式的交互。

　　在体系结构中支持这个模型不是主要问题，您所用的技术与其它模型中的技术类似。您常常把异步模型与事件推支持或轮询机制配对，这些细节很可能促使您为实现选择某种技术。

　　在 Web 服务的情况下，虽然一般来说工具不适合异步交互，但是这种形式被支持。基于 SOAP 的 Web 服务不仅支持同步 RPC 交互方式，还支持异步消息交互方式。它的基础是面向文档模型，在这个模型中，请求者和供应者必须处理 SOAP 信封格式化和分析。

　　面向文档模型是实现真正的单向通信的方法。

[1] [2] 下一页