使用 JMS 和 WebSphere ESB 构建强大而可靠的 SOA.docx

使用 JMS 和 WebSphere ESB 构建强大而可靠的 SOA.docx

《使用 JMS 和 WebSphere ESB 构建强大而可靠的 SOA.docx》由会员分享，可在线阅读，更多相关《使用 JMS 和 WebSphere ESB 构建强大而可靠的 SOA.docx（43页珍藏版）》请在冰豆网上搜索。

使用JMS和WebSphereESB构建强大而可靠的SOA

使用JMS和WebSphereESB构建强大而可靠的SOA——第1部分收藏

Java™MessageService（JMS）对J2EE™平台上的可靠消息传递进行了标准化。

最近发布的IBM®WebSphere®EnterpriseServiceBus（ESB）产品提供了一些重要的功能，这些功能位于任何基于面向服务的体系结构（SOA）的环境核心位置。

本系列共三篇文章，描述如何将JMS和WebSphereESB结合使用，以形成强大而可靠的SOA。

使用JMS和WebSphereESB构建强大而可靠的SOA——第2部分

使用JMS和WebSphereESB构建强大而可靠的SOA——第3部分

引言

面向服务的体系结构（SOA）永远不能建立在真空中。

在任何实际的环境中，都必须考虑现有的IT环境，功能（和数据）的提供并不能简单地通过提供一组新服务来实现。

因此，构建SOA的一个关键方面就是将现有应用程序分解为更小的块（即“服务”），这些块通过标准协议进行通信，并具有定义良好的接口。

这样做的优势在于，此类环境更为灵活，整个系统的各个部分之间并不存在紧密耦合。

松散耦合且具有平台独立性的服务的概念通过使用企业服务总线（EnterpriseServiceBus，ESB）得到了进一步发展。

其中，ESB充当使用不同数据和消息格式、网络协议和编程语言的服务之间的“粘合剂”。

ESB充当服务使用者和服务提供者之间的中间层，允许部署中介，以执行各种操作，如向交互应用服务质量或执行所需的数据转换。

在本系列的文章中，我们将了解一个ESB充当此类中间层的具体例子。

我们将利用IBMWebSphereEnterpriseServiceBus（WebSphereESB）V6.0.1产品来链接服务使用者和服务提供者，同时使用JMS作为消息传递机制。

在第一篇文章中，我们将简单了解一下WebSphereESB产品及其工具环境，即WebSphereIntegrationDeveloperV6.0.1。

第2部分将描述实际的ESB场景，并说明如何构建服务使用者和服务提供者，而在第3部分，我们将演示如何构建运行于WebSphereESB中的使用者和提供者之间的中介。

您将学习如何部署和运行解决方案，我们将提供进行此操作所需的所有代码构件。

企业服务总线和JavaMessageService

SOA由彼此进行通信的服务使用者和服务提供者组成。

它们通常通过企业服务总线进行通信。

每个服务具有服务定义，在其中描述如何从使用者接受消息和如何向其使用者返回消息（“单向”服务时例外）以及其他一些事项。

因此，构建ESB与消息传递有很大关系。

一直以来，以稳健、快速而可靠的方式发送和接收消息是IT系统的一项关键要求，ESB的到来并未改变这一点；它恰恰给解决方案带来了额外的要求——例如，支持描述消息格式的标准、服务间的事务交换等等。

同时，基于JavaJ2EE平台的系统通常会利用JavaMessageService（JMS）API来满足其消息传递需求。

简单说来，JMS描述如何将消息从一个应用程序发送到另一个应用程序，对服务的事务质量进行了潜在的利用。

充分考虑到很多应用程序已经在使用JMS了，而SOA内的服务又需要一种进行消息传递的方式，这样就能很好地理解JMS在ESB上下文中所扮演的角色。

每个ESB都必须能够通过JMS从服务使用者接收消息，并将其转发到相应的服务提供者（通过JMS或其他协议，如HTTP），反之亦然。

而且，JMS还定义了可发送的若干不同类型的消息。

例如，Text消息包含消息的字符串表示形式；Object消息包含序列化的Java对象；Map消息包含键/值对的映射，等等。

Web服务通常使用SOAP作为其消息格式，但很多应用程序都使用纯XML。

因此，ESB必须支持各种网络和消息协议。

图1显示了服务使用者和服务提供者可能支持的一系列协议组合。

请注意，ESB充当了这两者间的中间层，允许在不受协议限制的前提下连接任何使用者和提供者。

图1.SOA中的消息和网络协议示例

如果设置WebSphereESB，以支持不同的组合，这正是我们将在本系列中讨论的内容。

不过，首先让我们看一下该产品本身以及其主要组件。

WebSphereESBV6.0.1

WebSphereESB产品是IBMSOAFoundation的一部分。

尽管其版本号可能会让人觉得此产品已经存在很长时间，但该产品却是在2005年末首次发布，与其他已经存在的WebSphere产品系列成员共享很多组件。

例如，它使用基于J2EE的IBMWebSphereApplicationServer作为其核心运行时。

WebSphereApplicationServer提供了一个JMS实现，该实现由WebSphereESB进行了重用。

它还使用了服务组件体系结构（ServiceComponentArchitecture，SCA）作为其基础编程模型，并与WebSphereProcessServer共享SCA运行时。

图2显示了WebSphereESB及其基本组件的概况。

图2.WebSphereESB概况

WebSphereESB支持通过JMS的基本消息传递，可以通过WebSphereApplicationServer中的MQLink与WebSphereMQ进行通信。

使用SOAPoverHTTP和SOAPoverJMS的Web服务是插入到ESB中的，支持很多Web服务标准和通过应用服务器提供的UDDI注册表。

WebSphereESB不仅可以从标准J2EE客户端使用，也提供C/C++和.Net®的客户端支持。

而且，它还通过WebSphereAdapter提供了到各种遗留环境的连接。

WebSphereESB和服务组件体系结构

我们在前面提到WebSphereESB所使用的编程模型基于SCA。

SCA描述了一个完整的服务编程模型，涉及到大量可采用相同的方式描述和访问的组件（即服务）。

此类组件可以为BPEL流程、业务规则或传统Java组件等等。

WebSphereESB向SCA模型引入了一个新的组件类型，即中介流组件。

从SCA的角度而言，中介流组件与任何其他服务组件没有任何区别，因为中介组件具有以下特征：

∙存在于模块中（更准确地说，存在于中介模块中，它采用这种方式部署到服务器运行时中）。

∙具有接口，采用Java或WSDL描述。

∙通过导出向客户端公开，导出可以有多个不同协议的绑定（我们将在以后对此进行讨论）。

∙具有对其他服务的依赖关系（通过导入，导入也具有描述协议详细信息的绑定）。

就某种程度而言，中介流编程模型是独一无二的；它支持访问和操作关于正在处理的服务消息的绑定特定信息（通常为Header类型的信息）。

有关SCA及其编程模型的详细信息以及如何通过其构建和部署组件，请参阅BuildingSOAsolutionswiththeServiceComponentArchitecture系列文章。

（在本系列的剩下部分中，我们将假定您已具有SCA的基本知识，因此我们将不会对已在其他地方得到详细阐述的内容进行复述。

）

中介流组件提供了一种服务组件的新实现，即中介流的实现。

中介流通常使用可视流编辑器进行构建，用于通过一系列中介原语描述请求和响应消息流。

这些原语可以读取和更改消息，或将其路由（“筛选”）到不同的目标位置。

虽然您可以构建自己的自定义中介原语，该产品仍然提供了一系列用于以下用途的预定义原语：

∙XSLT转换

∙消息日志记录

∙消息筛选

∙数据库访问。

图3显示了一个使用若干中介原语实现响应流的中介流组件实现。

图3.中介流示例

顺便说明一下，我们将在第2部分详细讲解创建此类流所需的各个步骤。

WebSphereESB和服务消息对象

我们尚未讨论的是，消息“在总线中”时如何对其进行处理。

也就是说，如何对发送到中介流组件的数据进行表示？

答案是，每个消息到达中介流组件时，将立即被转换为服务消息对象。

与此类似，在离开中介流组件前，会将其重新转换为消息的目标所要求的任何格式。

服务消息对象是ServiceDataObject（SDO）规范的扩展，该规范描述了一种以独立于源的方式访问数据的方法。

因此，并不会考虑消息是否通过HTTP或JMS或任何其他协议传入，也不会考虑消息是SOAP消息还是纯文本，而会始终将其转换为一种可由实际中介流实现（如中介原语）使用的通用格式。

因此，SCA提供了用于调用中介流组件的编程模型，而SMO/SDO则表示在此组件中处理的实际消息。

这二者实现了紧密的协作。

SCA导出和导入绑定

正如前面提到的，SCA组件使用导入和导出与外部世界通信（即，与使用组件的客户端和组件的实现使用的其他服务通信）。

对WebSphereESB及其中介流组件而言，可以将导出视为ESB的入站端口，而将导入视为出站端口。

例如，假定您有一个现有服务使用者和一个现有服务提供者，二者通过SOAPoverHTTP进行通信。

现在您希望向此连接中插入WebSphereESB中介，以便能对通过的每个消息进行记录。

通过创建中介流组件，并为其提供与目标服务相同的接口，就可以实现此目标。

然后为导入创建Web服务绑定，以引用目标服务的WSDL（包括端点地址），从而创建指向现有Web服务的导入。

也就是说，已将导入“绑定”到该Web服务。

类似地，为导出创建Web服务，从而生成新WSDL文件，并构建一个指向中介流组件的端点。

最后，部署此组件，并告知服务使用者使用新端点地址。

消息现在将定向到WebSphereESB，通过一系列中介原语，然后转发到实际的目标Web服务。

还记得我们曾提到每个消息都将成为总线中的一个SMO吗？

Web服务绑定是一段将传入SOAP/HTTP请求消息转换为服务消息对象的逻辑，而出站Web服务绑定则提供其反向逻辑；即，它将传出SMO转换回SOAP/HTTP消息。

这些都是自动进行的。

运行时知道入站消息的格式，因为这个消息是由相应的WSDL定义进行了全面的描述，运行时可以据此进行分析和处理。

为了保证正确性，自定义绑定仅处理消息的正文部分。

Header字段由基础设施自动处理，将在不需任何编程的情况下在JMS消息和SMO之间进行转换。

不过，如果传入的消息并不遵循SOAP之类的特定消息协议，会发生什么呢？

例如，如果有JMS映射消息发送到导出，则不能使用默认绑定，因为不知道此映射的格式。

此时自定义绑定就派上用场了。

必须以Java类的形式提供从传入消息到SMO的转换，以执行相应的分析逻辑和构建正确的SMO。

在出站端（即导入）也应该进行相同的处理。

自定义绑定实现知道如何获取SMO并将其转换为正确的格式。

在本系列的第2部分和第3部分，我们将详细讨论自定义JMS绑定的示例（支持全部五种JMS消息类型的绑定），因此我们会再次讨论自定义绑定的话题，并演示如何将自定义绑定作为中介模块的一部分部署到运行时中。

WebSphereIntegrationDeveloperV6.0.1

WebSphereESB的目标之一是简化创建中介并将其插入到企业的消息流中。

在某种程度上来说，这个目标是通过利用SCA编程模型实现的，该模型允许使用一个描述和部署机制处理不同类型的服务。

SCA规范还描述了用于将这些组件装配为较大的解决方案的方法。

而且，我们希望支持以细粒度中介原语为基础构建的中介流组件。

WebSphereIntegrationDeveloperV6.0.1支持所有这些操作。

我们在前面提供了使用多个原语的中介流组件实现的图。

该工具也支持采用可视方式将中介流组件、导出和导入装配为中介模块，以便部署和安装到运行时中。

例如，图4演示了如何使用装配编辑器来构建包含中介流组件的中介模块。

图4.包含中介流的中介模块

前面提到的系列文章“BuildingSOAsolutionswiththeServiceComponentArchitecture”详细讨论了使用此工具的示例场景。

我们还将在第3部分逐步说明如何构建中介模块。

结束语

在本文中，我们讨论了可以如何使用WebSphereESB产品构建企业服务总线，该产品支持可用于连接到现有服务和新服务的各种消息和网络协议。

其中一个协议就是JMS。

WebSphereESB基于新的服务组件体系结构，使用服务数据对象作为其内部消息格式模型。

SCA定义了绑定的概念，可利用绑定对客户端提供服务组件，并让其与其他组件进行通信。

在采用五种不同的JMS消息类型的情况下，我们需要提供自定义绑定实现，以便支持任何消息格式。

在本系列的其他两篇文章中，我们将提供一个示例，演示如何利用WebSphereESB来处理JMS客户端和（基于JMS的）消息驱动Bean交换的消息。

您将了解如何开发和部署自定义绑定实现，如何全程使用WebSphereIntegrationDeveloper作为工具环境来构建相应的解决方案。

使用JMS和WebSphereESB构建强大而可靠的SOA——第2部分收藏

Java™MessageService（JMS）对J2EE™平台上的可靠消息传递进行了标准化。

最近发布的IBM®WebSphere®EnterpriseServiceBus（ESB）产品提供了一些重要的功能，这些功能位于任何支持面向服务的体系结构的环境核心位置。

本系列文章讨论如何将JMS消息传递和WebSphereESB集成，共三篇文章，本文是第二篇，主要描述用例场景，以提供构建和部署测试应用程序的舞台，以演示此集成的消息传递功能。

使用JMS和WebSphereESB构建强大而可靠的SOA——第1部分

使用JMS和WebSphereESB构建强大而可靠的SOA——第3部分

引言

在本系列的第1部分，我们向您介绍了一系列概念，包括企业服务总线（EnterpriseServiceBus，ESB）的概念，以及JavaMessageService（JMS）之类可靠的标准化API可以如何帮助保证服务使用者、服务提供者和总线之间的通信服务质量。

我们还了解了WebSphereESB产品提供的ESB实现，该实现基于一个新编程模型，即服务组件体系结构（ServiceComponentArchitecture，SCA）。

SCA描述导出和导入绑定的概念，我们可以将此类绑定用于通过JMS与中介流组件进行交互。

所需的所有构件都可以使用IBMWebSphereIntegrationDeveloper工具进行构建和部署。

在第2部分，我们将开始应用这些概念，并演示如何构建实际的应用程序。

用例

在实际的SOA业务应用程序——特别是涉及到异类IT基础设施的应用程序以及希望对这些IT基础设施提供的服务间的工作流进行组合以形成松散耦合的交互的应用程序中，服务使用者和提供者间的消息流并不需要采用同步方式处理。

由于JMS作为面向消息的中间件标准得到了广泛的应用，因此经常用作同步和异步服务调用的首选协议。

有很多典型的场景，其中服务间的连接可以使用JMS进行传输：

电子政务、电子商务或工业制造就是其中的一些例子。

示例1

一个具体的用例就是处理会计系统中的文档。

影响公司财务的文档（如购买货物的发票）在企业中多个系统流动。

其中很多都必须采用允许以后进行审计的方式处理（某些情况下，这是法律强制要求的做法）。

这意味着此类文档的流通必须能够跟踪，而这又要求传输协议要十分可靠。

而且，所涉及的系统之间的很多交互都实现了具有异步性本质的工作流。

因此，所选的协议既要支持消息的可靠事务性交换，也要支持各种消息传递模式（异步和同步调用以及发布/订阅消息）。

同时，要对所有消息进行定向，使其通过企业服务总线，以便能够应用其他功能；如基于内容的动态路由或数据转换以及日记记录和日志记录。

此会计示例代表了一个场景，在此场景中，解决方案采用面向服务的体系结构构建的，但并不一定会使用Web服务；在我们的例子中，服务通过交换普通JMS消息进行通信。

为此类解决方案部署ESB仍然十分可行。

示例2

让我们看看另一个场景，制造行业的一个例子：

某个公司制造需使用大量部件的产品，其中一些部件来自内部的工厂，而其他从外部供应商处购买。

该公司希望加速其库存周转，降低其库存水平，从而降低内部成本和提高其产品的上市时间。

实现此目标的一个方法是与其业务合作伙伴（包括供应商）建立更紧密的关系。

通常，制造商将利用生产计划系统（productionplanningsystem，PPS）来协调其内部生产与外部供应链。

在PPS中，内部部件的库存较低时，将生成生产请求，以生产此部件。

图1.生产计划系统——概略体系结构

除了使用内部工厂提供的部件外，该制造商还从外部供应商购买其他部件。

为了提高所涉及各方的集成水平，该制造商需要将其PPS与其若干供应商系统集成，以便自动交换供求信息。

为了将PPS系统连接到任意数量的供应商（每个供应商都采用自己独特的协议和数据格式），可能必须开发大量的代码。

很多要集成的现有系统都使用JMS作为外部消息传递协议。

其他系统（特别是最近构建的系统）可能支持Web服务。

在此情况下，制造商决定建立ESB来集中处理协议和消息格式的转换，从而将对现有系统的任何影响降到最低。

例如，外部接口使用JMS的现有系统可以与Web服务交互，并将处理不同协议的细节委托给ESB。

测试应用程序

我们在上面了解了作为协议的JMS如何与基于SOA的解决方案相关（包括从头创建系统以及必须集成现有系统时的情况）。

在这一部分中，我们将给出一个测试应用程序实现，以便重点了解使上述场景可行的WebSphereESB功能。

此实现包括：

∙JMS客户机，将发送不同JMS消息格式的请求。

∙服务提供者，接受JMS格式服务请求，并使用JMS消息进行响应。

∙一个WebSphereESB中介模块，包含用于执行实际消息中介操作的中介流。

图2给出了测试应用程序概略结构。

请注意，总共要使用四个队列和ESB进行通信。

图2.测试应用程序

在演示如何构建实际中介流并说明如何插入自定义代码之前（我们将在本系列的第3部分进行讨论），我们将了解测试客户端和测试服务提供者（将分别发送和接收JMS消息）。

另外，您将注意到，客户端和提供者代码中没有特定于WebSphereESB的内容。

设计就是这样的，因为我们假定服务使用者和服务提供者都不需要了解其间存在的ESB的任何信息。

客户端

我们将不会讨论将EAR文件导入到WebSphereIntegrationDeveloper中的详细步骤。

应用程序符合普通J2EE标准，可以像任何其他Web应用程序一样导入和处理。

另外，我们也不会对整个源代码进行详细说明，而仅重点讨论对我们示例重要的那些部分。

最后，我们将假定会将给出的所有代码部署到WebSphereESB服务器；例如，WID工具中包含的测试服务器环境。

测试客户端应用程序基于某个Web应用程序中的一组JavaServerPage和Servlet，允许在一对JMS队列间发送和接收不同类型的JMS消息。

该程序打包为JMSTestClientV1_6.ear文件，可以从本文的下载部分获得此文件。

图3.WebSphereIntegrationDeveloper工作区中的JMS客户端项目

在图3中，可以看到将客户端项目导入到WebSphereIntegrationDeveloper工作区后的结构。

请注意，其中包含两个Servlet，分别命名为ReadQueue和WriteQueue，我们将在下面对其进行更为详细的讨论。

清单1.WriteQueue.javaJMS消息创建

//WriteQueue.java

Sessionsession=con.createSession（false,Session.AUTO_ACKNOWLEDGE）;

MessageProducerproducer=session.createProducer（queue）;

if（msg_type.equals（"TextMessage"））{

TextMessagemessage=session.createTextMessage（msg_text）;

producer.send（message）;

}

elseif（msg_type.equals（"BytesMessage"））{

......

}

elseif（msg_type.equals（"StreamMessage"））{

......

}

elseif（msg_type.equals（"MapMessage"））{

......

}

elseif（msg_type.equals（"ObjectMessage"））{

......

}

ServletWriteQueue（清单1）将产生发送到指定队列目的地的所有类型的JMS消息。

它使用标准JMSAPI调用来根据JSP页插入的输入构造JMS消息。

根据指示的JMS消息类型对输入进行了格式设置。

上面的代码示例非常明白地说明了如何构建TextMessage。

可以在可下载源代码中找到与其他类型对应的代码。

以下代码摘录演示了如何解析对恰当JMS目的地队列的引用：

清单2.WriteQueue.javaJMS消息创建

InitialContextic=null;

try{

//Getthejndiinitialcontext

ic=newInitialContext（）;

ContextmyEnv=null;

//GetthecontextthatisspecificforthisWAR

//Thisholdsitemssuchasresourcereferences,ejbreferences,etc

//fromtheweb.xml

myEnv=（Context）ic.lookup