技术选择的要求和含义

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

　　松耦合或紧耦合

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

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

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

　　通过提供描述消费者/客户机与生产者/服务器之间的关系的公共合同，您可以放心地构建和集成您的应用程序而不必让别人了解您的应用程序的技术细节(以及随着时间的流逝而发生的变化)。通过相同的标记，您可以使用别的开发者的公共合同来使用他们的应用程序而不必了解细节。

　　通过提供处理与匿名服务器无连接交互的协议栈，您可以放心地通过故障弹性机制与组件交互。

　　通过提供与负载无关的通信通道，特别是通过基于代理的消息传递系统。

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

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

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