JCA/Web Service/JMS的选择问题

最近学习了下WAS对消息系统的支持，提到使用JMS集成，和JCA集成

顺便扩大一下视野，找到两篇非常不错的文章

一篇来自BEA dev2dev,一篇来自IBM Developerworks

第一篇：EAI问题，Web Service还是JCA

人们总是问我J2EE连接器体系结构(J2EE Connector Architecture，JCA)和Web服务的区别是什么。他们很想知道选择其中一个而不是另外一个的标准是什么。最初，我感到很诧异，因为答案看上去那么显而易见。但是，稍加思索，我就明白了人们为什么会混淆。供应商们将Web服务定位为标准的集成服务，他们的市场销售做的如此之好，以至于公司和个人用户已经开始感到忧虑，因为JCA也在做同样的宣传。人们很自然地得出结论，这两种技术在互相竞争，是互相排斥的。真的吗？有一点，但不全是。

了解定位

Web服务和JCA都是解决集成问题方面的标准，但它们却并不互相竞争。开发者和用户们需要知道这两者是不同的，并且需要知道这两种技术的差别所在，这一点很重要。

Web被定位于用来标准化集成的技术，而JCA规范则用来标准化企业应用集成（EAI）。其中EAI是广义上集成问题的一个子集。因此，问”如果我有一个EAI问题，该使用Web服务、JCA，还是两者兼而有之？”这样的一个问题，完全是合乎情理的。

最大的区别在于侵入

侵入（Intrusion）是指为了支持集成技术而需要对遗留系统做的改动。

JCA：该技术需要很少或者不需要对遗留系统的侵入。JCA适配器可以利用本地API、套接字、数据访问以及其他不需要更改现有代码基础的技术来访问遗留系统。于是公司就可以利用在已部署系统中的投入，而不必再投入额外的资源来更新系统以支持集成。 
Web服务：为了让遗留系统能本地支持将Web服务用作EAI方案，必须需要很高程度的侵入。遗留系统必须被更新并且修改，以包含一个Web服务栈。这个栈将处理所有的SOAP消息分析和遗留系统调用，这是一项很庞大的任务。大多数企业都不会贸然修改现有的COBOL或者旧的大型机应用以引进一种还不成熟的Web服务栈。

因此，如果一个公司想为EAI使用Web服务，最有可能的做法是购买一个Web服务网关，该网关将截取Web服务消息，对遗留系统进行本地调用，得到响应，然后将其转换成一个响应Web服务消息。JCA很容易就能被用作进行本地遗留系统调用的技术，但很多公司可能反对使用这么多的消息层来启用EAI。

顺便说一下，我个人认为EAI问题最终会成为Microsoft的.NET策略中的一个障碍。由于大多数遗留系统都不是运行在Microsoft Windows上，所以.NET不可能直接进行遗留系统集成。Microsoft已经公开宣称Web服务为他们未来的EAI战略。这意味着Microsoft在依赖公司将Web服务栈内置于遗留系统中以获得对它们的访问。我想说的是企业肯定不会接受这种做法，来做这么一笔投资。因为那些使用.NET的企业将被迫购买EAI服务器（WebLogic Server是不错的选择）来截取Web服务请求并使用像JCA这样的EAI类技术来进行集成。

上下文传播

需要考虑的一个严重的基础结构问题是从使用遗留系统的客户到遗留系统本身的事务和安全上下文传播（Context Propagation）。

JCA：JCA支持从JCA服务器到遗留系统的安全和事务传播。这是JCA设计中最主要的基础结构概念之一，也是被很多集成环境采用的一个强有力的原因。这意味着如果一个标识用户的XA事务上下文或者安全上下文是在应用服务器中创建的，那么当应用服务器调用遗留系统上的服务时，遗留系统就会感染上事务和安全上下文。就XA事务来说，这意味着如果遗留系统是XA-compliant的资源管理器，它就能参与XA事务。这样设计师们就能设计出EAI系统，这种系统能保证具有遗留系统以及使用该系统的客户的ACID事务。至于安全来说，这意味着用于个人的单点登陆（single sign-on）可用于客户和遗留系统之间。在设计和遗留系统的交互时，这些是需要考虑的关键特性。 
Web服务：Web服务消息可以传播一个事务或者安全上下文来作为一个SOAP头部扩展，这是可能的，但现在标准的做法已经不这么做了。另外，即使存在这样一个标准，也不会用来传播XA事务和内部的安全用户标识符。Web服务可以将客户从服务器上分离出来，就和MOM系统将生产商和消费者分离一样。是的，跨过Web服务消息传播XA事务上下文是有可能的，但Web服务的本性意味着谁也不能预测响应消息究竟何时发送或抵达目的地。XA事务是一个寿命很短的事务，通常每30秒自动进行一次transaction rollback。Web服务的这种不可预测和不连贯的本性使它成为XA事务上下文不太现实的传输手段。系统级的安全标识符同样有这个问题。这意味着利用Web服务来访问远程系统的客户不能使用XA事务来实现同样的目的。

但是也不要对Web服务失望。Web服务为业务逻辑（business logic）层提供了一个商业级的接口，而不是一个细粒度（fine-grained）的方法。如果这样的话，Web服务就需要事务，安全以及很多其他的基础结构技术，但是它们必须应用于Web服务所运行的环境中（不可预测的响应，不可预测的载荷，应用的来去，XML格式的变化等）。例如，OASIS工作于商业事务协议（BTP），为该环境中的系统提供了寿命很长的事务。另外，它还创建了很多安全Web服务规范。Web服务最终会改变开发者对商业服务的看法以及他们用来创建商业服务的体系结构，但是这些新的方案是否适用于EAI，这得你自己判断。

代码绑定

代码绑定是EAI简单但重要的一面。我们可以将Web服务和JCA做一个比较。

JCA：JCA是基于Java的技术，这并不意味着遗留系统必须是用Java编写的，但是使用JCA的遗留应用必须用Java编写。这给设计师们某些暗示。首先，任何使用JCA的应用和它对JCA的使用绑定在一起。这意味着如果应用对遗留系统的使用需要作出变化，那么开发者必须动手重新编写JCA访问代码以作出改动。这对于一些公司来说可能是问题也可能不是。其次，应用可以利用对访问遗留系统的客户所作的强制声明（strong typing）和编译时间检查。由于用来访问遗留系统的数据类型和方法是以Java类型出现的，使用JCA的Java应用可以对遗留系统的语义用法进行编译时间检查（它并不确认该系统的正确用法，只是说明使用该系统的语法是正确的）。 
Web服务：Web服务EAI方案允许用任何语言编写的客户端都能访问遗留系统，这些客户端可能是用Java，C#，Fortran，或者COBOL编写的。同样，由于Web服务使用XML消息来和其他系统通信，与Web服务动态连接并获取WSDL文档来理解消息结构的客户端不能从编译时间检查中获得任何好处。但是，Web服务的格式可能是实时的，应用也可以动态地和它一起变化，也就是说Web服务的改变并不一定意味着使用Web服务的客户端需要重新编写。

数据绑定

数据绑定用来将遗留系统数据的格式变成客户端应用可用的一种格式。 
JCA：JCA需要对一个Java数据类型（Java类）的数据绑定。这对于在本地类型和Java类型之间有一个清晰映像的简单数据类型来说。但如果遗留系统有复杂的相关或者二进制数据必须被处理，那么很快就会有麻烦。JCA 1.0没有一个表示遗留系统中数据格式的标准作法，并且动态客户端也不能连接到JCA适配器上以”发现”遗留系统的数据格式是什么。JCA 2.0包含了一个元数据功能（metadata facility），它能允许JCA客户端查询JCA适配器，以便动态地发现遗留系统中的数据形状和类型。 
Web服务：Web服务给遗留系统带来了一个有趣的问题，因为遗留系统中的数据必须首先被转换成XML来传输，然后再转换成使用Web服务的客户端的编程语言格式。如果EAI系统使用客户端->Web服务->服务器中间件->本地集成适配器->遗留系统这种途径，那么遗留系统中的数据将沿着一种丑陋的格式传输，即本地格式->本地集成适配器转换的语言格式->XML转换->使用Web服务的客户端的语言格式。除非数据绑定技术取得突破性进展，否则原始数据的很多含义在这些转换过程中很有可能丢失（更不用说系统变慢这样显著的性能了）。

另一方面，很多公司用XML格式来表示遗留数据自有他们的道理。XML在商业上很有意义，有很多种方法来跨越不同的应用和系统使用这些商业意义。但是，如果遗留系统在本地将它的数据用XML展现出来，那么Web服务可能会提供一个无缝方案，该方案使得对JCA的使用也变得很麻烦。在过去的三年里人们创建了很多使用XML作为数据格式的系统，这些系统现在都已成为遗留系统，所以这种方案可能是可行的

 

第二篇： 为 EAI 选择 JCA、JMS 或 Web 服务

http://www.ibm.com/developerworks/cn/webservices/ws-jcajms/index.html

本文讨论了在 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 实现中的一个实现。通过映射到某些解决方案的要求并对这些要求划分优先级，设计者可为他们特殊的情况选择正确的实现。

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

	Web 服务	JMS	JCA	注释
接口耦合（抽象服务定义）	是   支持动态接口发现和请求构造	否   负载无关	是	“是”意味着紧耦合
技术耦合（协议栈）	否   在 WSIF 中，客户机未与某个协议实现的客户机库绑定	是	是	“是”意味着紧耦合
可移植性	是   多种语言	否   仅 Java 技术	否   仅 Java 技术
可靠性	SOAP 的 HTTP-R 绑定	是	特定
事务支持	未来   WS-Coordination 和 WS-Transaction 补偿和 XA 模型	作用域有限   仅在队列入口点	是   XA 模型
安全性	限于 SOAP   SOAP-SEC（被 WS-Security 取代）	不是标准的一部分，所以特定于供应商	EIS 与 J2EE 之间的集成
同步方式	是   大量使用	自己动手	是
异步方式	是   面向文档接口	是	未来
事件驱动、推方式	是   面向文档接口或流程支持（WSFL，BPEL4WS）	是	未来

参考资料

• 您可在 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 安全性扩展（尽管该扩展已被取代）。