Regis Coqueret (regis.coqueret@fr.ibm.com), 客户经理/解决方案 设计师, jStart Emerging Technologies,IBM Software Group 2003 年 3 月 01 日 本文讨论了在 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 服务被定义为请求者与提供者之间的必需的业务接口而不是所有业务请求的共同管道。有些变数反映了 Web 服务的特点,包括:
起初,人们的意图是让连接器以同步的请求/应答方式来访问大型机上的旧的事务服务器,这也是当前多数连接器的工作方式。目前,标准的发展方向是更异步的双向连接性。 连接器的某些用户定义的变种更成熟,它们运行在逻辑连接方式下。同样,它们可被用作调用框架,以类似于 Web 服务的方式来选择适当的物理 EIS 目标和业务操作。
点到点和发布/预订机制。基于消息的框架可把信息传给其它应用程序而这些程序不必显式地请求它。相同的信息可被并行地传递给许多订户。 节奏的独立性。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 文档中描述相同的业务组件,您可以:
如果使用这种方式,那么 JMS 和 JCA 只是服务器提供程序可能用来实现业务组件的几个协议。因此,不同网络和接口技术只影响非功能性的部分,例如安全性、性能、响应时间和可用性。当内部网和因特网上的相同组件可被使用时,两个网络的区别是所需的安全性、预期的性能和要求的可用性。 Web 服务的以 WSDL 为中心的方式使您能够把抽象的接口从确切的协议栈中分离出来。您可以用两种方法来实现这种方式(两种方法都利用 WSIF):
在设计应用程序时,您需要定义交互的模式。一般来说,这些模式揭示了您对技术集成的偏爱。
标准的业务服务的侦听器常常使用 JMS 或 HTTP 服务器。EJB 中的消息驱动 Bean 使用 JMS,而 Web 服务使用 HTTP。 在这个推模型中,被推的事件触发流程。Web 服务社区已为正式定义这种流程交互的先后顺序做了大量的工作。具体地说, Web 服务流程语言(Web services Flow Language,WSFL)和 Web 服务的业务流程执行语言(Business Process Execution Language for Web services,BPEL4WS)标准可处理这种事件排序。
消息传递不是请求/响应类型交互的主要选择。由于消息传递所带来的隔离,用消息传递中间件实现的请求/响应阻碍了调用者与被调者之间的事务协调。另外,调用者的编程逻辑(而不是提供的连接器实现)必须管理响应超时。
在体系结构中支持这个模型不是主要问题,您所用的技术与其它模型中的技术类似。您常常把异步模型与事件推支持或轮询机制配对,这些细节很可能促使您为实现选择某种技术。 在 Web 服务的情况下,虽然一般来说工具不适合异步交互,但是这种形式被支持。基于 SOAP 的 Web 服务不仅支持同步 RPC 交互方式,还支持异步消息交互方式。它的基础是面向文档模型,在这个模型中,请求者和供应者必须处理 SOAP 信封格式化和分析。 面向文档模型是实现真正的单向通信的方法。
下一部分讨论在选择业务逻辑的访问技术中作为决定因素的非功能性要求。
松耦合系统常被设计成解决跨越数据流边界的问题,工作程序只解决更大的问题的一个部分,而且不一定知道这个问题的上下文。您常常可以通过添加更多的工作程序来自然地扩展这些系统。 您可以按以下方式来松耦合:
现在,我们把所讨论的三种技术映射到松耦合或紧耦合。 JCA 是紧耦合技术。
JMS 是松耦合技术。例如,它(只给消息中间件)不给目标系统提供安全性或事务绑定。一般来说,消息传递实现松耦合的原因有:
JMS 很适合于:
Web 服务的目标是业务服务而不是技术连接性。它们主要用松技术耦合但接口定义级别上的紧耦合来实现。 在 Web 服务中,耦合基于接口定义和协议绑定。
Web 服务中的耦合方式提供了灵活性,有两种绑定:静态和动态。
在现实中,目前多数 Web 服务把 SOAP 用作入站协议。SOAP 是松耦合协议,直至 服务等级被支持。服务等级将处理安全性、可靠性和可用性。 由于 SOAP 无处不在、防火墙友好和其它优点,SOAP 仍是缺省协议。另外,SOAP 是目前开发 Web 服务安全性规范的地方;所以在实践中,定义标准的安全性方式意味着使用 SOAP。 现在,在 Web 服务中,一些其它辅助业务功能(例如计费和审计)已经可用。
JMS 和 JCA 只处理 Java 世界。有了 JCA,就可以在 Java 客户机代码端上实现可移植性,而且互操作性限于特定的目标。为了在技术级别上互操作,JMS 要求在两端都有 Java 环境,但是消息负载是无关的,通过使用 JAXM Web 服务,可在 JMS 上携带 SOAP 负载。
Web 服务目前不支持事务。标准委员会正在研究用 WS-Coordination 和 WS-transaction 标准来提供松耦合模型中的事务支持的方法。今后将出现使用补偿的松耦合模型和使用类似 XA 事务模型的紧耦合模型。 在消息传递模型中,消息被传递到队列后,客户机无法控制它的传播。所以 JMS 只支持队列入口点的事务,不支持目标应用程序的事务。
HTTPS 支持在传输层上提供某种 Web 服务安全性。但是,在 Web 服务器译码和认证请求后,它是易受攻击的,只有使用 SOAP 安全性扩展(SOAP Security Extensions,SOAP-SEC)的某些 Web 服务实现支持目前可用的安全性(请参阅 参考资料以了解更多有关 SOAP-SEC 的信息)。有关 WS-Security 标准的标准化工作正在进行,WS-Security 将在未来实现完全互操作的端到端安全性模型。
您可以看到,需要根据多个标准来为集成选择 Web 服务、JMS 和 JCA 实现中的一个实现。通过映射到某些解决方案的要求并对这些要求划分优先级,设计者可为他们特殊的情况选择正确的实现。 下面的表总结了我们已讨论过的内容并列出了决定的标准:
|
联系客服