JBI概述

什么是JBI?
JBI是一个Java基础标准，用于通过可插拔式组件创建系统集成方案。这些组件通过处于中介的标准消息交换机制进行互操作。消息交换模型是基于WebService描述语言（WSDL）。

上图展示了可插拔式框架的JBI的高级理论。JIB环境为可插拔式组件提供接口，同时组件也提供接口给JBI环境使用。组件之间是不能直接交互的，代替的是，如下图所示，JBI担当了中介层，负责路由组件间的消息。这种分割是把服务提供者和服务消费者解耦和的关键所在，也是SOA的目标之一。另外，它为消息处理和监控提供了关键点。

基于WSDL，面向服务模型，可插拔式组件这些机制对于服务的提供和消费都是很重要的。通过提供服务，组件可以提供一个功能或一系列功能来供其它组件（或它自己）使用。这样的功能是使用WSDL 2.0来建模的，它包含了消息的交换。WSDL规范中定义的四个基本消息交换模式清楚地定义了在操作执行期被允许的消息顺序。我们可以形成这样的共识：在消费者组件和提供者组件之间，消息交换模式是JBI中组件交互的基础。

JBI组件提供的任何服务，都由组件使用WSDL1.1或2.0规范进行描述。这样就提供了一种抽象的，技术中立的使用基于XML消息交换的服务模型。WSDL也为服务消费者和JBI环境本身提供了一种声明额外的服务元数据的机制，组件可以通过JBI环境查询可用的WSDL描述的服务。
JBI体系结构



这个图形描述了JIB系统的架构：

  • JBI环境提供了通过基于管理工具的JMX进行部署、控制、监控的特性。
  • 标准消息路由（NMR）提供了中间消息交换的基础。
  • 组件（白色框中的东西）。

组件被分为两大类：

  • 服务引擎（SE）提供业务逻辑和转换服务，也能使用其他服务。
  • 绑定组件（BC）提供对于JBI组件外部服务的连通性。

SE和BC组件能够作为服务提供者、服务消费者或者两者皆可。注意，SE和BC组件之间的差异是纯粹的实用性，这种从通讯逻辑上的业务分离减少了复杂度和提高了灵活性。

除却消息系统，JBI环境还提供了基于JMX的管理结构，它提供了如下的标准机制：

  • 安装组件
  • 管理组件的生命周期（启动/停止）
  • 部署服务元件到组件中

JBI组件通常充当某种类型的容器，工件(artifact)可以被部署进这样的容器来增加新的服务或者提供逻辑。例如一个提供基于XSLT的转换服务的SE将会需要部署有XSLT样式表，这样才能增加新的转换操作。往已安装的组件中增加这样的组件相关的工件的过程被称为部署。这样的工件被称为SU，而部署工件加上一些相关元数据的集合称为SA。

消息交换概念实现的核心是WSDL消息。消费者组件生成一个服务请求，通过NMR路由递送到提供者组件。例如，BPEL SE组件可能会生成一个请求，碰巧这个请求被一个链接到WS-I组件的外部服务提供者所提供。NMR就会路由这个请求到WS-I绑定组件。在这个例子中SE是一个服务消费者，BC是提供者。

WSDL 消息模型
JBI使用WSDL1.1或2.0规范来对组件生产或者消费的服务进行建模。在WSDL两个版本中，术语定义存在差异的地方以WSDL2.0为准。这里有个典型的例子，接口（interface）和端点（endpoint）在1.1版本中被称为端口类型（port type）和端口（port）。

WSDL在两个层次上提供基于消息服务的声明式模型：

  • 抽象模型：不指向任何特定的协议或者线编码；
  • 具体模型：绑定到某个具体的通信协议或者通信端点（endpoint）。

JBI使用抽象服务模型作为组件交互的主要基础。组件在交互时一般扮演如下角色：

  • 服务提供者：执行给定服务的组件（直接的或者作为一个外部服务提供者的代理）。
  • 服务消费者：调用给定服务的组件（直接的或者作为一个外部服务消费者的代理）。

WSDL模型使用名字来标识模型中的各种组件，WSDL模型使用以下两种类型的模型：

  • 限定名（Qualified names）：一个 XML命名空间(URI)和简单名字组成的名称对，用于全局命名；
  • 简单（非限定）名（Simple [non-qualified] names）：只有简单名字，没有关联的XML命名空间，用于局部命名。

WSDL组件模型示意图如下所示，该模型将在以下几节详细讨论。


抽象服务模型
WSDL服务描述总是包括一个抽象的服务模型，定义如下：

  • 消息类型：消息类型定义了合法的消息结构和约束，一般通过XML Schema来表示。消息分为两类：常态消息（normal）和故障消息（fault），常态消息是指服务正常处理过程中的消息，故障消息用于描述非正常的处理条件。
  • 操作：与某种服务进行交互时的一次操作，该服务由服务消费者和提供者间交换的常态（或故障）消息来定义。抽象操作定义如下：
    • 操作名称：是一个限定名称；
    • 消息交换模式(MEP) ：消息（包括常态消息和故障消息）在消费者和提供者之间传递的顺序、方向和基数（Cardinality）；
    • 消息类型：MEP中消息的类型。
  • 接口：是相关操作的集合。注意不要同Java语言中的接口混淆。抽象服务类型即接口定义如下：
    • 接口名称：用于标识服务类型的全局限定名，在JBI中接口名称还用来指明服务类型；
    • 扩展的接口：扩展了其他服务类型的服务类型，类似于Java中的接口类型。一个服务类型可由其他几个服务类型组成。

JBI使用抽象服务模型作为组件交互的主要基础。组件在交互时一般扮演如下角色：

  • 服务提供者：执行给定服务的组件（直接的或者作为一个外部服务提供者的代理）。
  • 服务消费者：调用给定服务的组件（直接的或者作为一个外部服务消费者的代理）。

具体服务模型
WSDL中的具体服务模型建立在抽象服务模型之上，为抽象服务同特定通信协议及通信端点的映射提供描述信息。为了尽可能的保持通信协议中立，JBI中组件间的交互主要基于抽象服务模型，但为了与WSDL服务模型一致，组件间的交互使用WSDL具体服务模型来定义。JBI使用的WSDL具体服务模型非常简单，在大多数情况下可以将其等同为抽象服务模型看待，从而为组件间的交互构建了一个简单的处理模型。
具体服务模型定义了以下几个概念：

  • 绑定类型：标识服务所绑定的协议类型；
  • 端点：为服务消费者指明通过特定协议与服务提供者交互所需的通信端点的信息。在JBI中，端点是一种形式上的标识，其内部使用的协议是基于Java的标准JBI消息契约，与通常的通信协议无关。JBI中端点的定义包括以下几个概念：

    • 端点名称：简单的命名，用于在服务中标识一个端点。
    • 绑定类型：将一个绑定类型和端点想关联。
  • 服务：提供访问该服务的一组端点的集合，一个服务实现了特定的服务类型（接口）。一个服务包含如下信息：
    • 服务名称：一个限定名称，用于标识特定的服务实现。
    • 服务类型名称：服务实现的接口名；
    • 端点： 服务”包含“一个或多个端点，通过每个端点都可以访问该服务。

上图显示了一个ServiceMix项目中SU的配置文件如何映射到WSDL上。这个例子是用于ServiceMix中的servicemix-http组件和servicemix-jsr181组件。
通常，一个端点通过结合其服务名称和端点名称来识别，该结合称之为服务端点（Service Endpoint）。

标准消息路由
标准消息路由（NMR）从JBI组件接收到“交换消息”并将其路由到适当的组件去进行处理。它将服务提供者与服务消费者分离开来，并能够增加一些附加的操作。
消费者和提供者


JBI组件(SE和BC)可以担当服务提供者、服务消费者或者同时担当两种角色。上图就是一个servicemix-http提供者BC和servicemix-http消费者BC的例子。注意请求的起始位置和箭头的方向。

提供者通过一个端点使得一个用WSDL描述的服务可用。这个服务实现了一个WSDL接口，这个接口是一些操作（operation）的集合。

消费者通过创建一个交换消息能够调用服务中的某个特定的操作。

消费者和提供者仅仅是共享了抽象服务定义，因而是解耦的，因为消费者不知道具体的协议和调用服务的位置。

一个WSDL接口可以具有多个服务实现，服务消费者在查找实现了某个接口的提供者时，可能会查找到多个实现了该接口的服务提供者（服务和相关联的端点）。

标准化消息


JBI在提供者和消费者之间交互使用了标准消息这个概念。

一个标准消息包括如下3个部分：

  • 有效数据：是一个遵守WSDL信息类型的XML文档，不含有任何协议和编码；
  • 属性（或元数据）：包含了在消息处理过程中获得的与消息相关的额外信息。消息属性可以包含消息的安全信息（例如消息接收方的签名信息），事务上下文信息和组件特定的信息。
  • 附件：消息载荷（内容）的一部分可以由附件构成，附件由消息载荷来引用，并且附件中包含一个可以操作附件内容的数据处理器。这些附件可以是非XML格式的。

递送通道
递送通道是一个在组件和NMR之间双向的、异步的通讯管道。

服务消费者使用它发起一个服务调用，而服务提供者使用它接收调用。

每个组件只有一条DC，即用做入站也用作出站通信。
端点激活
Endpoint激活是服务提供者告诉NMR它提供服务的一个过程，这使得这些服务能够为NMR所知，从而NMR可以将服务调用路由到这些服务。
激活被分为两个步骤：
声明一个服务端点 (服务限定名+端点名称)；
提供元数据：组件必须提供活动端点的WSDL描述；WSDL描述可以让NMR知道哪一个接口和操作已经被活动端点所实现。
服务调用和MEPs服务调用指服务消费者和服务提供者之间的一个端对端交互的实例。尽管无法在JBI中定义一套完整的服务调用模式，但是JBI实现必须支持以下列表中的交互模式：

  • 单向交互（One-Way）模式：服务消费者向提供者发送一个请求，服务提供者不必向消费者返回任何错误（故障）信息。
  • 可靠的单向交互（Reliable One-Way）模式：服务消费者向提供者发送一个请求。如果服务提供者处理该请求失败，会向消费者返回出错信息。
  • 请求-回复（Request-Response）模式：服务消费者向提供者发送一个请求，并期望服务提供者响应。如果处理请求失败则返回出错信息。
  • 请求-选择回复（Request Optional-Response）模式：服务消费者向提供者发送一个请求，并期望服务提供者响应。消费者和提供者接受到一个消息后，都可以选择是否应答。

端点端点，在WSDL2.0中指代一个可以通过特定协议访问的特定的地址，用于访问特定的服务。JBI使用这个概念表示两种不同类型的端点：
外部端点：是在JBI环境之外的端点。这些被BC暴露的端点充当服务消费者来暴露一个内部端点以供外部的服务消费者使用（启代理作用）。
内部端点：由在JBI环境内的服务提供者暴露。它们可以通过NMR的API函数被访问到。
绑定组件在内部端点和外部端点之间建立映射，例如，绑定组件提供的内部端点可以映射到外部服务提供者发布的端点。

在JBI中，端点能够以下面三种不同的方式被引用：

  • 隐式引用(Implicitly)：JBI根据服务类型选择服务提供者端点；
    显式引用(Explicitly)：服务消费者根据自身的逻辑或配置选择服务提供者端点；
  • 动态引用(Dynamically)：在消息交换中使用一个端点引用（EPR）来提供“回调（call back）”地址供服务提供者返回应用会话进行过程中其它相关的消息交换信息。EPR在JBI中具有两种不同的使用方式：
    • EPR构建（EPR creation）：一个组件希望在消息中提供回调地址时，必须能够构建适当的EPR。
    • EPR解析（EPR resolution）：一个接收EPR的组件必须能够解析该EPR（也就是将其转换成可用的端点）以便于将消息交换发送到适当的端点（通常是外部服务提供者）。


上面的序列图显示了在消费者和提供者之间的InOut服务调用：

  1. 消费者创建了一个InOut消息交换, 构造"in" 消息(请求消息) 并发送消息到NMR；
  2. 提供者组件轮询递送通道（DC）获取这个交换信息；
  3. 它处理这个请求，构造一个"out"消息，并发送消息回NMR；
  4. 消费者轮询递送通道获取这个回复；
  5. 消费者处理了这个回复消息，并将之标记为"done" ；
  6. 提供者从递送通道接收到"done"状态；

这个例子是一个异步调用，但是JBI也能够操作同步调用。在这样的例子中，消费者发送一个sendSync并阻塞该线程直到回复被接收到；在提供者这边，如果提供者希望同步递送该回复，调用send（图示第3步）并阻塞，直到消费者确认该回复。

人们可能会惊奇，为什么会需要一个“done”状态。。。在JBI中，所有交换的终止必须标记为"done"状态或者"error" 状态。错误不同于故障，它们属于正常的数据交换状态。所以，对于在一个交换过程中实现一个可靠的消息、事务或者传送流“done”状态是非常有用的。

让我们看一个文件BC的例子，它能够巡检文件，通过InOnly方式传送内容，然后删除文件。出于性能的原因，他必须传送一个Open状态的文件流，但是他必须要关闭文件流然后在处理完删除文件。如果，消费者是异步的，那么必须有一条途径让它知道什么时间文件可以被删除，这个时候就需要“done”状态了。

JBI包
JBI定义了一个标准的包装方法用于安装新的组件和部署工件到这些组件中，这些组件提供了“容器“的功能。

所有的这些工件都在META-INF目录中的jbi.xml中包含有JBI描述。
我们已经讨论了关于工件的知识，现在让我们深入了解一下。下面列出了工件（打包在zip或jar文件中）的四种类型：

  • 组件（Components）组件安装器包含了组件运行期需要的库文件和资源。组件可以引用共享库。
  • 共享库（Shared Libraries） 就是一堆jar包，可以共享给其它组件使用。
  • 服务单元（SU） 是可以被部署到制定组件的元件。除去JBI描述，SU还可以有如下形式的文件：单独的XSLT格式表，BPEL过程，或者其它的Java类。。。
  • 服务集合（SA） 是一些SU的集合体。SU不能直接被部署，必须被打包进SA中再进行部署。SA中包含了SU的压缩包和关联元数据（就是jbi.xml)。

SA是一个包含了一些SA zip文件的zip文件。它和J2EE中的EAR很相似。为了降低打包JBI元件的痛苦，ServiceMix提供了强有力的工具：Maven，它能够打包所有的JBI元件，并且能够自动生成JBI描述文件。为了降低开发量，我们提供了针对JBI组件和SU的Maven原型，原型就是一些通过命令行生成项目的模板(详见 Notes on Creating JBI Component using maven2).

参考资料

  1. JSR208: Java Business Integration
  2. JBI Components: Part 1 (Theory) by Ron Ten-Hove
  3. Using JBI for service oriented integration by Ron Ten-Hove
  4. JBI - A Standard-based approach for SOA by Meeraj Kinnumpurath
  5. Steve Vinoski's JBI article
  6. Frank Summer's SOA JBI
  7. JBI - the only game in town
  8. Carlos's blog post on JBI
  9. JBI gains Industry support EbizQ
  10. Sun's JBI site
  11. Carl-Henrik Wolf Lund created a (Norwegian) presentation on JBI
  12. SCA, JBI and more.. which echos our FAQ entry
  13. Java Business Integration (JBI) Gains Industry Support by Patricia Seybold Group

评论

发表评论

此博客中的热门博文

如何解决在Delphi2009中添加pas组件的问题

过去Delphi7的时代，我们写了很多.pas的单元式组件，用Install Component的方式就可以安装了。但是，在Delphi2009中这个功能被取消了。 如何解决这个问题呢？ 你可以在Delphi2009中New一个Package，然后将你的*.pas文件和相关文件（*.dcu， *.dcr，*.res) 添加到Package中，然后再Build该项目，会产生*.hpp, *.obj, *.bpi, *.lib, *.bpl 等文件。 然后，你就可以在Delphi2009中使用Install package方式安装了。 如果你的.pas文件中没有Register方法，你需要补充它： procedure Register; begin RegisterComponents('MyComponentName', [MyTypeName]); end;
阅读全文

在Delphi中操作Sap对象造成内存增长的原因

曾经在我的一个Delphi开发项目中，我遇到过这样一个问题，困扰了我相当一段时间。 我将SAP对象封装成了类，并在一个线程中调用。也就是说，SAP对象的创建释放全部是通过代码来操作的，不同于直接将SAP控件拖放到窗体上。 线程每执行一次SAP读写操作，内存就增长24K-32K。 关键代码 下面是SAP类的部分关键代码，含有SAP对象的创建和释放。 procedure TSapSvr.Open(FunctionName: string); begin if fConnect.LogOn(0, True) then begin fFunctionName := FunctionName; fFunction := fSapFunctions.Add(FunctionName); end; end; procedure TSapSvr.Close; begin fFunction := Unassigned; fSapFunctions.ReMoveAll(); fConnect.LogOff; end; 我就是在线程中不断的调用Open和Close函数，你能看出问题出在哪里吗？你肯定想不到的。 解决方案 我也是在无意中发现的，不过我现在还不知道原因，告诉你解决的方法吧！那就是将 fSapFunctions.ReMoveAll(); 删除！！！ 结束语 你能告诉我原因吗？ 附件中我提供了我封装的SAP类，分享给大家，如果发现问题，请转送一份文件给我！
阅读全文

杀死团队的七种武器（转）

不管你是一个团队的成员还是带头人，如果你对它已经厌倦了，恨不得大家早点儿散伙，不妨赶紧捡起来下面这七种武器。好吧，也许你是一片好心， 希望改变团队目前垂垂危矣的状况，病急乱投医，随便捡起一把枪，却没搞懂枪口冲着哪个方向，再加上擦枪走火，自行了断，也不是不可能。有的武器介绍之后，还有使用它的进阶技巧。让其成为项目管理、共同协作、职场发展必备之最佳利器。 　　如果当初猪八戒扔掉钉耙，而是拿起来这些的话，也许他早就回高老庄，跟高翠兰一起，从此过上快乐、幸福的生活了。 武器一：贸然加入陌生人 　　团队来了新人，不要介绍他给大家认识，不要让大家知道他的技能和长处。人们会根据他的一些细微行为做出自己的判断，而不是先去深入了解他。 要是新人的兴趣癖好跟大家完全相反，那就再好不过了。 进阶技巧： 　　把两个死对头加入到一个团队中，而且告诉大家他们的技能对于团队来说很重要。这样一来，他们之间的摩擦就会成为加速团队分裂的催化剂。 武器二：限制沟通 　　别让大家谈天，这样会增进他们的感情。不断提醒他们“你们还有活要干！”要是能在办公室里面贴上一个“静”，就再好不过。实际上，如果团队分布在不同的地方， 甚至彼此之间的文化背景都不同，效果就更好了。不到迫不得已，绝不要把一个团队的人安排在一起。不要公布通讯录。让人们的惰性发挥效果，如果想找一个人很麻烦，他就不会找了。 进阶技巧： 　　告诉团队时间紧迫，发邮件也是浪费时间。这样人们就不会发送不必要的信息了。 武器三：分清长幼尊卑 　　最佳的装备给最棒的人。最快的电脑、最好的办公室、额外的假期等等等等，只给这些精英人物。当人们看到有人可以享受特权时，嫉妒暗自滋生。基督教的七宗罪，“嫉妒”跻身其中。更美妙的是，一旦这种致命武器在团队中出现，不用人浇灌，敌意就会不断蔓延。 武器四：打人要打脸 　　每个人都有自己的弱点，找到它！把人们的弱点公开出来，并且使其个人化。要指名道姓！在表达方式上也要无所不用其极：羞辱，责怪等等，不一而足。传播方式，可以通过备忘录、邮件、会议上的发言。用红色的大字体可以加强效果。更棒的是，你还可以散布流言。要想让人信服，不妨在流言中加入一些真相，这就更有效啦。。。 进阶技巧 　　曾经有一个公司的总裁，向全公司发送了一个备忘录，其中责备了软件团队新产品的种种不足。这种做法太牛掰了！这个总裁也就成了公司的杀手，不久之后，公司成功散...
阅读全文