<b>为EAI挑选JCA、JMS或Web服务</b>[Java编程]

　　引言

　　组织在疾速地发展,他们试图在掌握本钱的同时满意改变的业务需求.这意味着企业需求以支持信息系统的简易重组的方法来组织他们自己的利用程序.重要的组织改变(比方吞并或子公司的成立)也有大概把新的变数引入信息系统.

　　企业还大概需求到市场上购置利用程序或签订他们的部份业务需求的转包条约(比方分类帐或 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 信封格局化和解析.

　　面向文档模子是实现真正的单向通信的办法.

　　紧耦合意味着存在不易改变的、被迫精确表达的、预先肯定的客户机-服务器或消费者-公布者关系.在这种情形下,关于给定的客户机,您普通只有一个特定的服务器,该服务器有弊端敏感(这意味着客户机必须处理有关协议的错误)的技术交互.您可以在接口定义级别或协议栈级别上查看这种紧耦合.为了拜候该服务,您大概依靠于服务的特定的抽象定义或特定的协议栈.

　　松耦合系统常被计划成办理超越数据流边界的问题,工作程序只办理更大的问题的一个部份,并且不一定知道这个问题的上下文.您常常可以通过增添更多的工作程序来自然地扩大这些系统.

　　您可以按以下方法来松耦合:

　　通过供应描写消费者/客户机与生产者/服务器之间的关系的大众条约,您可以安心地构建和集成您的利用程序而没必要让别人理解您的利用程序的技术细节(以及随着时间的流逝而发生的改变).通过相同的标志,您可以利用别的开辟者的大众条约来利用他们的利用程序而没必要理解细节.

　　通过供应处理与匿名服务器无衔接交互的协议栈,您可以安心地通过弊端弹性机制与组件交互.

　　通过供应与负载无关的通信通道,分外是通过基于代理的消息传送系统.

　　目前,我们把所谈论的三种技术映射到松耦合或紧耦合.

　　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 实现中的一个实现.通过映射到某些办理筹划的要求并对这些要求划分优先级,计划者可为他们特别的情形挑选精确的实现.

　　下面的表总结了我们已谈论过的内容并列出了决意的尺度: