本文讨论了在 J2C 连接器体系结构（J2C Connector Architecture，JCA）、Java 消息服务（Java Message Service，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 的提供程序来公开。
• 它们可能提供事务和安全性的支持（也可能不提供这种支持）。

JCA

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

起初，人们的意图是让连接器以同步的请求／应答方式来访问大型机上的旧的事务服务器，这也是当前多数连接器的工作方式。目前，标准的发展方向是更异步的双向连接性。

连接器的某些用户定义的变种更成熟，它们运行在逻辑连接方式下。同样，它们可被用作调用框架，以类似于 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）：

1. 通过使用 IBM Web Services Gateway（WSGW），现有的 WSDL 描述被部署并在 SOAP 通道中使用 WSDL 描述。入站绑定是 SOAP，出站绑定是现有的 WSDL 实现描述。
2. 通过使用 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 信封格式化和分析。

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

技术选择的要求和含义

下一部分讨论在选择业务逻辑的访问技术中作为决定因素的非功能性要求。

松耦合或紧耦合

紧耦合意味着存在不易改变的、被迫准确表达的、预先确定的客户机-服务器或消费者-发布者关系。在这种情况下，对于给定的客户机，您一般只有一个特定的服务器，该服务器有故障敏感（这意味着客户机必须处理有关协议的错误）的技术交互。您可以在接口定义级别或协议栈级别上查看这种紧耦合。为了访问该服务，您可能依赖于服务的特定的抽象定义或特定的协议栈。

松耦合系统常被设计成解决跨越数据流边界的问题，工作程序只解决更大的问题的一个部分，而且不一定知道这个问题的上下文。您常常可以通过添加更多的工作程序来自然地扩展这些系统。

您可以按以下方式来松耦合：

• 通过提供描述消费者／客户机与生产者／服务器之间的关系的公共合同，您可以放心地构建和集成您的应用程序而不必让别人了解您的应用程序的技术细节（以及随着时间的流逝而发生的变化）。通过相同的标记，您可以使用别的开发者的公共合同来使用他们的应用程序而不必了解细节。
• 通过提供处理与匿名服务器无连接交互的协议栈，您可以放心地通过故障弹性机制与组件交互。
• 通过提供与负载无关的通信通道，特别是通过基于代理的消息传递系统。

现在，我们把所讨论的三种技术映射到松耦合或紧耦合。

JCA 是紧耦合技术。

• JCA 是使用容器来连接请求和连接的企业信息系统的 J2EE 标准。容器是一个耦合器，为安全性、事务作用域、连接管理传播以及与目标系统的交互提供受管方式支持。
• JCA 耦合接口由公共客户机接口来严格定义。
• 应用程序组件看不到系统合同和容器-组件合同，但这些合同确实有力地链接了调用者和被调者。
• JCA 尚未处理类似计费和审计的业务问题。实现这些要求仍是应用程序业务体系结构的问题。

JMS 是松耦合技术。例如，它（只给消息中间件）不给目标系统提供安全性或事务绑定。一般来说，消息传递实现松耦合的原因有：

• 消息制造者和消费者在点到点或发布／预订模型中通过消息传递传输（例如消息代理）来交互。
• 提供的技术头常常独立于业务负载。

JMS 很适合于：

• 集成参与业务事件的系统／组件。
• 集成迟缓的响应者。
• 集成现有的系统。

Web 服务的目标是业务服务而不是技术连接性。它们主要用松技术耦合但接口定义级别上的紧耦合来实现。

在 Web 服务中，耦合基于接口定义和协议绑定。

• 合同用 WSDL 来发布，WSDL 定义了接口，接口定义了可用的操作。
• 用于访问 Web 服务的协议多种多样。这个协议被称为入站绑定，它定义了如何获取实现助诊文件。
• 访问实现的方法也多种多样。这个协议被称为出站绑定，它定义了实现公共合同的助诊文件。示例包括 JavaBeans、EJB 和 JCA。

Web 服务中的耦合方式提供了灵活性，有两种绑定：静态和动态。

• 静态绑定意味着紧耦合：请求者使用在设计时获取的服务实现；不必使用私有的或共享的注册中心。
• 动态绑定意味着松耦合：请求者在运行时发现用于被调用的服务的实现；它甚至可能在运行时确定应该被调用的接口。

在现实中，目前多数 Web 服务把 SOAP 用作入站协议。SOAP 是松耦合协议，直至 服务等级被支持。服务等级将处理安全性、可靠性和可用性。

由于 SOAP 无处不在、防火墙友好和其它优点，SOAP 仍是缺省协议。另外，SOAP 是目前开发 Web 服务安全性规范的地方；所以在实践中，定义标准的安全性方式意味着使用 SOAP。

现在，在 Web 服务中，一些其它辅助业务功能（例如计费和审计）已经可用。

可移植性和互操作性

Web 服务不在调用者与被调者之间强加编程语言或操作系统限制。在不久的将来，很有可能处理 SOAP 的某些互操作性问题，例如 Apache 实现与其它实现之间的差异。在解决它之后，所有支持 Web 服务的平台将可以互操作（包括 .NET 和 J2EE 平台）。但是即使到那时，Web 服务客户机或服务器实现代码也不能在供应商之间移植。为 .NET 编写的实现代码肯定不能运行于 J2EE。

JMS 和 JCA 只处理 Java 世界。有了 JCA，就可以在 Java 客户机代码端上实现可移植性，而且互操作性限于特定的目标。为了在技术级别上互操作，JMS 要求在两端都有 Java 环境，但是消息负载是无关的，通过使用 JAXM Web 服务，可在 JMS 上携带 SOAP 负载。

事务支持

JCA 并不总是支持 EIS 的端到端事务支持。前面已提到，连接器提供程序实现了把事务上下文传播到目标系统的容器。这是通过事务管理系统合同来完成的，在合同中，容器被用作控制作为资源管理器的 EIS 的事务管理器。这是基于 XA标准（请参阅 参考资料以了解更多信息）。

Web 服务目前不支持事务。标准委员会正在研究用 WS-Coordination 和 WS-transaction 标准来提供松耦合模型中的事务支持的方法。今后将出现使用补偿的松耦合模型和使用类似 XA 事务模型的紧耦合模型。

在消息传递模型中，消息被传递到队列后，客户机无法控制它的传播。所以 JMS 只支持队列入口点的事务，不支持目标应用程序的事务。

可靠性

目前，唯一有保证的传递是通过 JMS（尽管没有消息延迟的保证）。为了今后的需要，IBM、Microsoft、BEA 和 TIBCO 已联合提出了在 Web 服务环境中交换安全的、可靠的消息的标准机制。您可在 Web 服务组织站点获取这些标准（请参阅 参考资料）。JCA 连接的可靠性总是特定于连接器，JCA 本身并不意味着可靠性。

安全性

安全性是标准化程度最低的领域。在 JMS 中，规范明确规定安全性由 JMS 提供程序实现（该实现与其它的 J2EE 安全性兼容）来决定。幸运的是，IBM 也坚持这一标准。在 JCA 中，安全性的支持取决于连接器容器的功能和目标企业信息系统的实现。

HTTPS 支持在传输层上提供某种 Web 服务安全性。但是，在 Web 服务器译码和认证请求后，它是易受攻击的，只有使用 SOAP 安全性扩展（SOAP Security Extensions，SOAP-SEC）的某些 Web 服务实现支持目前可用的安全性（请参阅 参考资料以了解更多有关 SOAP-SEC 的信息）。有关 WS-Security 标准的标准化工作正在进行，WS-Security 将在未来实现完全互操作的端到端安全性模型。

结束语

您可以看到，需要根据多个标准来为集成选择 Web 服务、JMS 和 JCA 实现中的一个实现。通过映射到某些解决方案的要求并对这些要求划分优先级，设计者可为他们特殊的情况选择正确的实现。

下面的表总结了我们已讨论过的内容并列出了决定的标准：

参考资料

• 您可在 java.sun.com 获取 JMS 规范。
• 您可在 Java 2 连接器体系结构（Java 2 Connector Architecture，JCA）中找到 JCA 标准的完整描述。
• Paul Fremantle 写的“ Applying the Web services Invocation Framework”（ developerWorks，2002 年 6 月）是 WSIF 的优秀的入门读物。
• WSFL 规范（PDF 格式）很好地描述了 Web 服务流程语言。
• 回顾 Web 服务的业务流程执行语言 V1.0（Business Process Execution Language for Web services，BPEL4WS）规范。
• 了解更多有关 Apache Axis的信息。
• 通过回顾 目前所有公开的标准和规范来了解有关 Web 服务协议系列的信息。
• SOAP Security Extensions: Digital Signature很好地描述了目前的 SOAP 安全性扩展（尽管该扩展已被取代）。