ESB解决方案.doc

esb 解决方案 问问题题描描述述 在商业激烈竞争的今天，很多企业，特别是大型企业都应用了 it 技术来提高企业竞争力，提高 公司的运作效率与资源利用率等，而技术的更迭，业务变化等等造成了企业内部多种异构应用 软件、平台、系统共存的局面。这些系统、平台可能使用不同的通信协议，或者是不同格式的 数据，互相之间交换数据、通信显然十分困难。如果企业还需要与外部其他系统交互，则还面 临着需要调查其他系统的结构，通信协议等等问题。这些都是企业系统集成所面临的问题与困 境。 近年来，也出现了一些解决集成问题的技术，例如 eai（enterprise application integration）， b2b（business-2-business），soa（service oriented architecture）以及 web service，这些解决 方案能够解决一些问题，但是往往有以下诟病：或者有专利保护，需要支付昂贵费用，实现起 来耗时费力，或者是一次性定制的，花费成本高，后期难以维护，系统扩展不灵活。 什什么么是是 esb esb 全称为 enterprise service bus，即企业服务总线。它是传统中间件技术与 xml、web 服务等 技术结合的产物。esb 提供了网络中最基本的连接中枢，是构筑企业神经系统的必要元素。 esb 的出现改变了传统的软件架构，可以提供比传统中间件产品更为廉价的解决方案，同时它 还可以消除不同应用之间的技术差异，让不同的应用服务器协调运作，实现了不同服务之间的 通信与整合。从功能上看，esb 提供了事件驱动和文档导向的处理模式，以及分布式的运行管 理机制，它支持基于内容的路由和过滤，具备了复杂数据的传输能力，并可以提供一系列的标 准接口。 esb 的五个基本功能： 1)服务的 metadata 管理：在总线范畴内对服务的注册命名及寻址管理功能。 2)传输服务：必须确保通过企业总线互连的业务流程间的消息的正确交付，传输还包括基 于内容的路由功能。 3)中介：提供位置透明性的服务路由和定位服务；多种消息传递形式；支持广泛使用的传输协 议。 4)多种服务集成方式：如 jca，web 服务，messaging ，adaptor 等。 5)服务和事件管理支持：如服务调用的记录、测量和监控数据；提供事件检测、触发和分 布功能。 esb 的八个扩展功能： 1)面向服务的元数据管理： 他必须了解被他中介的两端,即服务的请求以及请求者对服务的要 求，以及服务的提供者和他所提供的服务的描述； 2) mediation ：它必须具有某种机制能够完成中介的作用，如协议转换； 3）通信：服务发布、订阅，响应 请求，同步异步消息，路由和寻址等； 4) 集成： 遗留系统适配器，服务编排和映射，协议转换，数据变换，企业应用集成中间 件的连续等。 5）服务交互： 服务接口定义，服务实现的置换，服务消息模型，服务目录和发现等。 6）服务安全： 认证和授权、不可否认和机密性、安全标准的支持等； 7）服务质量： 事务，服务的可交付性等； 8）服务等级： 性能、可用性等。 esb 中最常提到的两个功能是消息转换和消息路由。 解解决决方方案案选选择择 方案 目前实现了 esb 的产品有很多，选取具有代表性的几种为例，如： websphere enterprise service bus（ibm 的基于 websphere 的解决方案，基于 service component architecture，sca，商业产品）； apache servicemix（java business integration，jbi 规范的一种实现，它包涵了许多 jbi 组件，这 些组件支持多种协议，比如 jms,http,ftp,file 等。同时也实现了 eip，规则和调度。早在几年 前，它就已经成为了 apache 的顶级项目，开源）； mule（一个基于 esb 架构理念的消息平台，它是可升级的、高分布式的对象代理，可以通过异 步传输消息技术来无缝的处理服务与应用之间的交互。目前分开源与商业两个版本） open esb（sun 公司支持下的一个开源项目，其核心是基于 jbi 规范的实现。open esb 可运行在 glassfish 应用服务中，同时 netbeans ide 也为 open esb 提供了拖拽式的开发工具，这是其他开 源 esb 不可匹敌的。） 选型 考虑到有稳定社区维护的开源产品，如 servicemix，具有高可靠性与低成本代价两个较大优势， 以及在市场上的应用率以及呼声较高，最终将选择对象锁定到 servicemix 与 mule 两个产品。 在开源产品中，两者在网络上呼声最高，将两者对比的文章很多。下面摘选作者谈开源 esb一文中的书两位作者 tijs rademakers，jos dirksen 对两者的对比： infoqinfoq：您认为，对于 muleesb 和 servicemix，它们各自的优缺点是什么？在使用时有何建议？ jdjd：二者都有优缺点。我喜欢 servicemix 的模型，它让热部署新的集成流程变得容易，并且事实上 它是基于标准的。尽管 jbi 标准没有获得太多的青睐，但它是一个相当不错的规范，当你理解 jbi 时，它 会让你对 servicemix 很容易上手。我很喜欢有可热插拔的集成组件，特别是它们是可以热部署的。包含 camel 也是 servicemix 的一个亮点。我真的喜欢可以用 dsl 去开发集成流程。servicemix 的不足之处跟 它的优点是有关联的。jbi 规范确实引入了另一个困难级别，对 xml 的关注并不见得总是适合你在集成领 域中遇到的需求。另一方面，mule 让集成流程的创建变得容易和简单。它有非常广泛的路由器，易于扩 展，并有很多可选的开箱即用的连通性、路由和转换。使用 mule，使你能够在数分钟内让相当复杂的集 成流程启动并运转起来。然而，mule 也有缺点。尽管不是很大，但是对我个人而言，它的一个最大的缺 点就是没法热部署新的集成流程。如果 mule 集成 osgi 或者其他方法，就能很容易的更新集成流程，这将 是一个大大的加分点。 tjtj：当前，servicemix 被分成了两个项目，servicemix 3.2.x/3.3.x 和 servicemix 4。我们书中使 用 servicemix 3.2.x（基于 jbi），但我们对 servicemix 4（基于 osgi，支持 jbi）也有一个简短的介 绍。因此，servicemix 和 mule esb 之间的主要不同点就是，servicemix 是基于 jbi，而 mule esb 实现 了基于 java 的定制模型。但是这些 esb 间还有很多共同点（支持 spring，通过 cxf 支持 web 服务，xml 配置）。但是，让我们着重谈谈不同点。 mule esb 是一个以 java 为中心的 esb，这让 java 开发者能很容易地上手。它拥有强大的 xml 模式集 合，它们创建了一个真正清洁可读的 xml 配置并提供了代码补全支持。当你想实现一项转换逻辑或者路由 逻辑时，你能够很轻易地开发出一个简单的 java 类/spring bean/脚本文件，把它引入到 xml 配置中。如 果必须要指出 mule 的一个不足之处，那就是缺乏对于热部署的支持。 servicemix 是一个以 jbi 为中心的 esb，它提供了大量的 jbi 组件，比如 jms，web 服务，camel 以 及 bpel 组件。当然，你也可以使用来自其它基于 jbi 的 esb 的 jbi 组件，诸如 petals 和我们书中介绍的 open esb。servicemix 为每个 jbi 组件都提供了一个简易的 xml 配置语言，为部署你的集成解决方案提 供了热部署功能。servicemix 的一个缺点是进入 jbi 的学习曲线。因此，问题实际就是：在 mule 和 servicemix 之间，你更愿意选择哪一个？。servicemix 提供了 jbi 支持，bpel 集成，关注 xml 消息和热 部署功能。mule 提供了以 java 为中心的模型，支持 jbpm，支持消息无关，没有热部署功能。 jdjd：选择使用哪一个，其实取决于你的需求。当你面临的是关注 xml 标准的集成场景时，servicemix 就是个不错的选择。如果你需要低级别的集成，mule 可能是个好的选择。这两个 esb 都是不错的开源集 成解决方案，对于大多数集成问题都能很好地解决。 infoqinfoq：为什么你们最终选择了：为什么你们最终选择了 servicemixservicemix 和和 mulemule，而不是其他选择？对，而不是其他选择？对 apacheapache synapsesynapse 或者或者 springspring 集成（集成（springspring integrationintegration）有何建议？）有何建议？ tjtj：servicemix 和 mule 是活跃社区中成熟开源 esb 的绝佳范例，它们代表了基于 jbi 的 esb 和以 java 为中心的 esb 的方法。我们还会考虑其他替代方法，apache synapse 就是最主要的替代者。顺便说 一句，在本书中，我们已经包含了 apache synapse 以及 spring 集成的例子。apache synapse 是面向 web 服务的 esb 的典范，它是基于 apache axis2 的。当你一门心思想要获得 ws-*支持和 rest 支持时， synapse 显然是一个你需要考虑的 esb。我发现 spring 集成是个不错的框架，可以跟 apache camel 相媲 美。它们都对 hohpe 和 woolf 描述的企业集成模式提供了支持，这样无需单独的集成容器，你就能很轻易 地将你的 java 应用程序集成进来。因此，在不需要引入中心 esb 容器，在应用程序级别实现集成功能情 况下，这些框架非常有用。 jdjd：我个人没有过多接触 spring 集成，为了体验它，我们正在用它做一个很小的项目。目前为止， 我们对它印象还不错。它是相当轻量级的解决方案，可以轻易地与我们编写的其余 spring 应用程序相结 合。在我们开始写这本书时，开源 esb 社区还不如现在成熟，而且现在有了更成熟的解决方案。 两者各有千秋，我们选取了 servicemix 作为 esb 解决方案进行研究，版本 3.3.2。 servicemix 相相关关 servicemix 简介 features servicemix is lightweight and easily embeddable, has integrated spring support and can be run at the edge of the network (inside a client or server), as a standalone esb provider or as a service within another esb. you can use servicemix in java se or a java ee application server. servicemix uses activemq to provide remoting, clustering, reliability and distributed failover. servicemix is completely integrated into apache geronimo, which allows you to deploy jbi components and services directly into geronimo. servicemix is being jbi certified as part of the geronimo project. other j2ee application servers servicemix has been integrated with include jboss, jonas with more to follow. jbi container servicemix includes a complete jbi container supporting all parts of the jbi specification including: normalized message service and router jbi management mbeans ant tasks for management and installation of components full support for the jbi deployment units with hot-deployment of jbi components servicemix also provides a simple to use client api for working with jbi components and services. in addition, servicemix provides an implementation of ws notification. jbi components servicemix includes many jbi components including http, jms, bpel, rules, and many more . 以上摘自 apache servicemix 官方网站的介绍。 jbi 消息规范 要理解 servicemix，首先必须弄懂 jbi 规范。以下摘自jbi 消息规范-第二部分。 jbi 规范规范-规格化消息路由规格化消息路由 nmr（一）（一） 规格化消息路由从 jbi 组件（服务殷勤或绑定组件）接收消息交换 me 并将其路由到适当的组件进行 处理。this mediated message-exchange processing model decouples service consumers from providers, and allows the nmr to perform additional processing during the lifetime of the message exchange. 本章中使用 wsdl2.0 中的术语而不是 wsdl1.1。 1.几个关键的概念 本节介绍 nmr 架构中的几个关键概念。nmr 的目标是the goal of the nmr is to allow components acting as service producers and consumers to interoperate with one another in a predictable fashion, using wsdl- based service descriptions as the sole source of coupling between them. this is key to allowing mix-and-match assembly of components, creating the basis of integration solutions and a services infrastructure. wsdl wsdl 2.0, wsdl 1.1为 jbi 组件交互提供了基本的模型和描述机制。wsdl 提供了一个基于 xml 消息交换操作的抽象服务模型，该模型可以通过提供特定的绑定信息（将抽象模型映射到实际的通 信模型和端点wsdl 2.0 bindings 的特定的协议信息）进行扩展。 jbi 扩展应用了 wsdl 的抽象消息模型，可以把 nmr 看作是一个抽象的 wsdl 消息系统基础平台 infrastructure，绑定组件和服务引擎在这个平台上提供和使用 wsdl 定义的服务。 wsdl 定义了一项服务提供者和消费者之间的消息交换操作，消息交换参与者依照各方都能够理解的 一种消息交换模型进行操作。一组相关联的操作称作“接口”，该接口的实现称作“服务”。一个服务具有一 个或多个端点，每个端点通过一种特定的绑定（消息通信协议）为外部系统访问该服务提供入口。 所有的这些 wsdl 概念都被 jbi 用于 apis 和 spis 中构建服务模型。 1.1. 服务消费者和提供者服务消费者和提供者 jbi 引擎和绑定组件可以扮演服务消费者，服务提供者或两者兼之的角色。服务提供者通过端点 （endpoint）提供 wsdl 描述的服务；服务消费者通过开始调用特别操作的消息交换使用服务。服务 （service）实现了 wsdl 的接口，wsdl 接口是通过交换抽象定义的消息来描述的一组相关的操作。 因为服务消费者和服务提供者之间通常只共享抽象的服务定义而不是具体的端点信息，所以两者之间 是松耦合的。这种结构使得服务提供者的具体实现（如特定协议）对服务消费者来说是透明的。 一个 wsdl 接口可以具有多个服务实现，服务消费者在查找实现了某个接口的提供者时，可能查找 到多个实现了该接口的服务提供者（服务和相关联的端点）。 1.2. 规格化消息规格化消息 jbi 使用“规格化（normalized）”消息的概念描述服务消费者和提供者之间的交互。一条规格化消息由 如下三个主要部分组成： 消息载荷（payload）：符合抽象 wsdl 消息类型，不具有任何协议编码或格式信息的 xml 文档（这不是一个消息的规范格式）。 消息属性（或元数据）：包含了在消息处理过程中获得的与消息相关的额外信息。消息属 性可以包含消息的安全信息（例如消息接收方的签名信息），事务上下文信息和组件特定的信息。 消息附件：消息载荷的一部分可以由附件构成a portion of the content of the “payload” (content) of the message can be made up of attachments, referenced by the payload, and contained within a data handler that is used to manipulate that contents of the attachment itself. such attachments can be non-xml data. 规格化消息通过抽象 wsdl 消息类型定义为组件间的交互提供了互操作。 1.3. 传输通道（传输通道（delivery channel） 传输通道是绑定组件和服务引擎与 nmr 之间通信使用的双向通信管道。传输通道构成了服务消费者， 提供者和 nmr 之间的交互契约，即 api 接口。服务消费者使用传输通道开始服务调用，服务提供者使用 传输通道从 nmr 接收服务调用。既能发起调用服务，又能接收服务调用的组件使用同一个传输通道完成 这两种功能。 以一个绑定组件接收 jbi 系统外部的服务消费者请求为例，当接收这种传入的服务调用请求后，该绑 定组件通过其传输通道与 nmr 交互时必须扮演服务消费者的角色（在此场景中，绑定组件可以看作是一 个服务消费者代理）。 每个组件都具有唯一的一个传输通道，因此传输通道的实现必须支持在多线程环境下的并发使用。 1.4. 运行时端点激活运行时端点激活 运行时激活是服务提供者激活其提供的实际的服务的过程，在该过程中，服务提供者将其实际的服务 注册到 nmr，使得 nmr 可以将调用路由到该服务。端点激活分为两步： 向 nrm 声明一个服务端点 提供描述该端点定义的元数据信息 向 nrm 声明一个服务端点是绑定组件或服务引擎向 nmr 注册一个端点名称的过程。在 nmr 中声 明的端点名称必须有相应的元数据信息详细描述该端点的注册，这部分详细信息在作为组件接口一部分的 spi 中进行了详细的描述。 1.5. 服务调用和消息交换模型服务调用和消息交换模型 服务调用指服务消费者和服务提供者之间的一个端对端交互的实例。尽管无法在 jbi 中定义一套完整 的服务调用模型，但是 jbi 实现必须支持如下列表中的交互模式： 单向交互（one-way）模式：服务消费者向提供者发送一个请求，服务提供者不必向消费 者返回任何错误信息。 可靠的单向交互（reliable one-way）模式：服务消费者向提供者发送一个请求，如果服 务提供者处理该请求失败，它可以向消费者返回处理的错误信息。 请求-回复（request-response）模式：服务消费者向提供者发送一个请求，并期望服务提 供者返回一个处理应答，如果处理失败则返回处理的错误信息。 请求-选择回复（request optional-response）模式：服务消费者向提供者发送一个请求， 并期望服务提供者返回一个处理应答，如果处理失败则返回处理的错误信息；如果服务消费者处 理返回的应答失败，则向服务提供者发送应答处理错误的信息。 上述提到的消费者和提供者角色可能由绑定组件或服务引擎来扮演。当一个绑定组件扮演一个服务消 费者的角色时，也就说明存在一个外部的服务消费者；同样的，当一个绑定组件扮演服务提供者角色时， 也就说明存在一个外部的服务提供者。当以任意一种角色使用服务引擎时，说明该服务引擎是一个内部参 与者。 wsdl 2.0 预定义扩展wsdl 2.0 extensions定义了一个消息交换模型（mep），jbi 使用该模型定义 消费者节点和提供者节点之间的交互。该模型根据消息类型（normal 或 fault）和消息流向定义。 meps 总是站在提供者的角度来理解。例如，在请求回复交互模式中， mep 的定义是 in-out，站在提 供者的角度来看，请求（request）是输入（in），回复（response）是输出（out）。从服务消费者的角度 看，消息流的方向正好相反，但是 nmr 在与服务消费者交互过程中使用的 mep 总是从服务提供者的角 度来说的。当处理 wsdl meps 时，这是一种惯用的处理方式。in-out 模式示意图如下所示： 如上图所示，第一条消息（请求）是从消费者发送到提供者，从提供者的角度看其方向是输入（in）。 第二条消息（回复）是从提供者到消费者，即输出（out）。这些交换是按给出的序列执行的，从提供者 的角度这种交换首先是输入一条消息（in），跟着是输出（out）一条消息，因此这种交互模式命名为输入 输出（in-out）模式。 1.6. 消息交换（消息交换（message exchange） 消息交换（me）用作承载构成服务调用一部分的规格化消息的“容器（container）”。me 不仅封装了 其实现的消息交换模型中的输入（in）消息和输出（out）消息，它还包含了这些消息的元数据信息以及正 在进行的消息交换的状态信息。消息交换代表了 jbi 本地服务调用的一部分。下表说明了服务调用和消息 交换模型之间的关系： 服务调用（服务调用（service invocation）消息交换模式消息交换模式 mep (提供者角度提供者角度) one-wayin-only reliable one-wayrobust in-only request-responsein-out request optional-responsein optional-out 表 2 service invocation to mep mapping 图 one-way service invocation between two service engines 上图描述了两个本地服务引擎间的单向服务调用：se1 作为一个服务消费者，通过创建并初始化一个 包含了消息请求的 in-only 消息交换调用所需要的服务操作。如上图中的连接线流向所示，se1 将该消息 交换实例发送到 nmr。 nmr 根据该消息交换实例决定由哪一个服务提供者提供该消息交换请求的服务操作，并将其传输给 选定的提供者。该对象流转过程从上图 nmr 和 se2 之间的连接线可以看出。 需要注意的是该图示并不意味着调用方必须在交换完成之前阻塞当前线程的执行。调用方在发送和接 收消息时，可以是事件驱动as shown in the activity diagram, advances the engines internal state without necessarily tying up thread resources. 图 se invokes service provided by remote jbi instance: robust in with fault normalized 以下内容描述了上图所示的处于两个不同的 jbi 环境中的服务引擎之间的可靠的单向调用逻辑。需要 注意的是规范中未规定如何联合两个分离的 jbi 实例，该例中两个 jbi 实例之间通过 bc1 和 bc2 提供的 通信协议使得两者作为远程的消费者和提供者而相互可见，并不存在影响两者之间调用执行的特殊关系。 se1 构建并初始化了一个可靠的单向（robust-in）消息实例，并发送到 nmr（在构建 me 实例的过程 中，nmr 为该实例设定了一个唯一标识“x”）。nmr 选择合适的服务提供者，并将消息交换以可靠的单 向消息模式发送给 bc1。bc1 按照其所实现的协议需求封装消息请求，并将该请求发送给服务提供者， 在本例中，恰好是另一个通过 bc2 发布了一个服务端点的 jbi 实例 jbi2。 当 jbi2 实例中的 bc2 组件接收到请求以后，该组件构建一个可靠的单向消息交换实例（“y”）并发 送给 nmr。jbi2 实例中的 nmr 选择合适的服务提供者并将消息交换实例（“y”）发送给该提供者即 se2。 se2 接收实例“y”，处理完成以后，se2 可能选择返回一个故障消息说明发生了一个应用级别的错误。 在本例中，se2 可以使用实例“y”返回故障消息，沿着请求流向的反向路径最后通过消息交换实例“x”到达 jbi1 实例中的 se1 组件（在此 mep 中，存在一个“done”响应信息会沿着相同的路径传递，为了清晰未在 图中显示）。 以下内容描述了上图所示的 jbi 实例中的服务引擎与 jbi 系统外部的一个远程服务提供者之间的请求/ 响应调用。 服务引擎 se 创建并初始化一个 in-out 模式的消息交换实例并发送到 nmr，由 nmr 决定哪一个服务 提供者应当处理该调用。在本例中，bc 组件被选中，bc 接收到该消息交换（in-out 模式），将其反规格 化（denormalize），然后通过通信协议发送到外部的服务提供者。外部提供者处理消息请求，返回适当的 信息（正常的回复或者是应用处理层级的错误消息）。bc 组件规格化该回复，讲求封装到消息交换，然 后发送到 nmr，最终返回给消费者 se。 1.7. 端点（端点（endpoints） 端点，在 wsdl2.0 中指代一个可以通过特定协议访问的特定的地址，用于访问特定的服务。jbi 使 用这个概念表示两种不同类型的端点： 外部端点：jbi 系统外的端点。外部服务提供者发布的端点，绑定组件发布的端点，用于 代理外部服务消费者。 内部端点：jbi 系统内部服务提供者发布的端点，可以通过 nmr 的 api 访问。 绑定组件在内部端点和外部端点之间建立映射，例如，绑定组件提供的内部端点可以映射到外部服务 提供者发布的端点。 在 jbi 中，端点可以通过三种不同的方式进行引用： 隐式引用：jbi 根据服务类型选择服务提供者端点 显式引用：服务消费者使用自身的逻辑或配置选择服务提供者端点 动态引用：在消息交换中使用一个端点引用（epr）来提供“回调”地址供服务提供者返回 应用会话进行过程中其它相关的消息交换信息。epr 在 jbi 中具有两种不同的使用方式： a) epr 构建（epr creation）：一个组件希望在消息中提供回调地址时，必须能够构建适当的 epr。 b) rpr 解析（epr resolution）：一个接收 epr 的组件必须能够解析该 epr（也就是将其转换成可用 的端点）以便于将消息交换发送到适当的端点（通常是外部服务提供者）。 2. 消息交换的构成 模式（pattern）：每条消息交换都通过消息交换的模式（方向，序列，cardinality）和消息 名称（normal 或 fault）构成。 起始组件（initiator）：构建该消息交换的组件。在所有 jbi 定义的消息交换模式中服务消 费者组件担当消息交换的初始组件。 服务组件（servicer）：处理该消息交换的组件。服务提供者担当服务组件。 角色（role）：当一个组件“拥有”某条消息交换时，该组件所扮演的角色，包括：提供者 提供该消息交换请求的服务；消费者该组件向提供服务的提供者发出请求。 地址（address）：一个服务引用，端点引用和 nmr 用来路由消息的逻辑地址的操作名称。 消息（message）：携带一条或多条消息的消息交换 me。 故障（fault）：携带至多一条故障信息的消息交换，错误是一种特殊的消息。 状态（status）：描述消息交换的状态：error，done 或 active 中的一种。 错误（error）：用于描述错误状态原因的 java exception 对象。 属性集（properties）：消息构建组件和消息服务组件可以将任意的属性信息关联到其拥有 的一条消息交换 me。nmr 可以预留某些属性名称用于声明 qos，安全，事务或其它操作元数 据。 消息交换的生命周期很短，不能够在系统停止或崩溃时保留。由消费者和提供者组件提供的错误恢复 逻辑必须处理这类错误案例。能够使 jbi 支持可恢复性的可靠的消息交换需求将在 jbi2.0 中进行考虑。 2.1. 交换概要（交换概要（exchange summary） 下表是 jbi 使用的 wsdl2.0 中定义的消息交换模式。每种定义包含一个故障处理规则，用于which specifies which message in the exchange is created (or replaced) to convey a fault from one participant to the other.，能够与 wsdl1.1 等同的操作也同时在表中列出。 pattern namemessage sequence fault rule wsdl 1.1 operation in-onlyinnoneone-way robust in-onlyinon in- in-outin, out replaces out request-response in optional-outin, out on in or out - 表 3 jbi standard message exchange patterns (from wsdl 2.0) 3. 规格化消息 规格化消息是 jbi 消息交换 me 中的消息。本节定义了规格化消息，同时讨论了 jbi 中处理该类消息 的模型。 3.1. 标准化定义标准化定义 消息的规格化指的是将协议与业务上下文信息以可传输的方式存储起来的过程。nmr 处理的所有消 息都是规格化的，规格化是一个双向的过程： 消息的规格化是将包含了特定上下文数据的消息转换成上下文中立的抽象表示，本质上说 就是将由 nmr 解释的上下文数据转换成一种 nmr 能够理解的“通用”的表现形式。任何其他的 信息（如消息载荷，附加上下文等）都可以由消息承载并由 nmr 传递，但是，这些信息对 nmr 来说是透明的。需要说明的是规格化并不意味着要将消息载荷数据规范化表示。 反规格化消息指的是从 nmr 接收消息并将其转换为与上下文相关的表现形式。反规格化 是规格化的逆向操作，例如，一个 soap 绑定组件反规格化消息时会将消息适当的部分以及消息 元数据放入 soap 信封，转化成需要的编码格式。 3.2. 规格化消息的结构 规格化消息包含两个不同的部分：上下文和载荷。 消息上下文指的是一组消息属性集，可以为消息关联一些元数据信息。 消息载荷实际上是包含了所有消息载荷的原始数据信息的抽象。在此处，术语包含（“contain”）是指 包含在描述消息的抽象数据模型中。 3.3. 处理方法处理方法 规格化消息提取并未规定消息载荷的处理方式。消费者可以根据特定上下文需求自由选择消息载荷的 处理方式。例如，一个高性能的绑定组件会考虑使用“拉”模式的解析器或原始字节流来序列化消息载荷； 另一方面，一个转换引擎可能需要将整个消息载荷加载道内存中表示成 xml 的 dom 树以便于查询。 3.4. 二进制数据二进制数据 规格化消息的消息载荷一定是 xml，对于非 xml（包括二进制数据）的数据通过使用 jaf（java activation framework）将这些数据作为规格化数据的附件。 3.5. wsdl1.1 的支持的支持 服务提供者可能使用 wsdl1.1 描述其自身而不是用 wsdl2.0。由于 wsdl1.1 的消息模型与 2.0 有 很大的区别，jbi 定义了一个映射关系用于将 wsdl1.1 消息映射成为单个 xml 文档的规格化消息形式。 servicemix 用例 我们采用一个用例来说明 servicemix 是如何发布一个外部的 webservice。 开发环境：开发环境： 操作系统：windowxp jdk：7 容器：servicemix3.3.2 tomcat6.1.8 ide：eclipse3.5 其他工具：apache maven 2.2.1 预备知识：预备知识： service unit 和 service assembly 如字面意思，service unit 就是一个一个的服务单元，而 service assembly 是这些单元的集合。在 servicemix 上发布一项服务，其实是发布一个服务集(sa)，在这个集合中，可能存在一个或者多 个服务(su)。例如，我们有一个服务需要顺序使用两个 webservice，那个我们可以定义两个 su 分别对应不同的 webservice，然后使用一个 sa 将这两个 su 统合起来 这样，我们就可以调用一个暴露在外面的服务（该 sa 的服务），来达到使用两个 webservice 的目的。 准备工作：准备工作： 1 安装好 jdk ，eclipse 以及 tomcat。 2 将 servicemix3.3.2 解压完毕，进入 cmd 控制台，运行如下命令： cd %servicemix_home%/bin servicemix 这样就启动了 servicemix 容器。 3 安装好 maven，并且配置好 maven 的环境变量 m2_home : 解解压压 maven 的的目目录录 path : %m2_home%bin 具体步骤：具体步骤： 发布简单 的 webservice 在 eclipse 下建立一个 web 工程，取名 helloworld。建立包 sample，并在包下建立 hello.java 类， 如下： package sample; public class hello public string say(string value) return “hello “ + value; 采用 eclipse 自带的 webservice 插件生成一个 webservice，得到如下的 wsdl： 将该 web 工程用 tomcat 运行起来，本例 tomcat 采用 8888 端口。 建立 servicemix 工程 建立 servicemix project 建立一个目录，作为 workspace，用来放置各个项目，本例如下： 运行 cmd，键入： d: mkdir mvnspace 则，目录结构为 d：mvnspace。 然后进入该目录，利用 maven 建立一个 servicemix project： cd mvnspace mvn archetype:create - darchetypegroupid=org.apache.servicemix.tooling -darchetypeartifactid=servicemix-project-root -dgroupid=org.apache.servicemix.tutorial -dartifactid=tutorial-wsdl-cxf-service cd tutorial-wsdl-cxf-service mvn install 到这里为止，一个工程被建立了，名称为 tutorial-wsdl-cxf-service，我们已经将这个新建的工程 发布到我们的本地 maven repository 中。 建立 service unit 接着，建立一个 service unit，仍然在 tutorial-wsdl-cxf-service 目录下键入: mvn archetype:create - darchetypegroupid=org.apache.servicemix.tooling -darchetypeartifactid=servicemix-cxf-bc-service-unit -dgroupid=org.apache.servicemix.examples -dartifactid=my-cxf-bc-su 这样，一个 service unit 被添加到了工程，工程的 pom.xml 文件中自动加入了 my-cxf-bc-su 且工程目录中建立了 my-cxf-bc-su 文件夹，文件夹下有 pom.xml 以及 src 文件夹。修改 my-cxf- bc-su 文件夹下的 pom.xml 中的组件名，方便在控制台中观看。做如下修改： . cxf wsdl tutorial : cxf bc su . 将步骤 1 里得到的 wsdl 文件粘贴到 srcmainresources 目录下，并修改 wsdl 文件， 目的是修改 webservice 的访问名称以及地址，替换成代理，如下： 现在我们已经完成了对 wsdl 的设定，现在我们需要在 xbean.xml 设定 consumer 和 provider 来帮定这些东西。打开 xbean.xml，作如下修改： 首先，我们需要一个 namespace，这个 namespace 要和我们引用的 wsdl 中的 service 和 endpoint 的 namespace 一致，这样我们才能准确找到 service 和接口。我们的 wsdl 定义 的 targetnamespace=”http:/sample”，所以我们 bc 组件中的 consumer 和 provider 定义的 namespace 也必须和上面一样。 最终修改完成如下： 注：这里采用轻量级模式，即，将 consumer 和 provider 写在一个 service unit 内，如果想 在中间加入其它程序，则可以将 consumer 和 provider 分成两个 service unit 这样 service unit 就建好了，接下来我们建立 service assembly。 建立 service assembly 继续在 tutorial-wsdl-cxf-service 目录下键入： mvn archetype:create - darchetypegroupid=org.apache.servicemix.tooling -darchetypeartifactid=servicemix-service-assembly -dgroupid=org.apache.servicemix.examples -dartifactid=my-cxf-sa 现在可以看到工程目录中新建出来了 sa 的文件夹， 同样，我们修改一个名字： cxf wsdl tutorial : cxf sa 接下来，我们要在这个 sa 中注册我们刚才制作的 su： org.apache.servicemix.examples my-cxf-bc-su 1.0-snapshot 注意：只能存在一个 dependencies 节点。 好了现在一切就绪，我们在工程目录下面运行 mvn install，这样就建立好组件了。 部署 servicemix 工程 将 my-cxf-satarget 目录下的 jar 包复制到 servicemix 目录下面的hotdeploy 文件夹， 来正式发布到 servicemix 当中。 如此一来，便成功发布了一个服务到 servicemix 容器上。 检测成果 建立一个测试 html 如下： servicemix wsdl -first exa