重造Java ESB:JBI与ServiceMix

Java的进展都是围绕着JSR形式的规格说明书进行的。最近，这个家族中又新添了一个成员，那就是JBI(Java Business Integration)。它是一种企业服务总线(Enterprise Service Bus,ESB)，用于形成一种关键基础设施片段，使我们能够用Java实现面向服务的架构。我们将在本文中探讨JBI有关概念以及一种名为SeviceMix的开源实现。

　　JBI的主要目的是提供一个基于服务的平台作为对现有Java/J2EE平台功能的扩展。由于Web services已经实际应用于J2EE中，而且ESB和SOA等术语与其说是技术推动力倒不如说更是市场概念，所以让我们一起来深究一下到底什么是Java/J2EE中所谓的“基于服务的平台”。

　　当前的J2EE部署都运行在一个基础上，那就是应用服务器。应用服务器本身由两个独立的部分组成——Servlet容器和EJB容器，它们分别用于部署JSP/Servlets和EJB构件。在它们中的任何一个，你都能使用Web services。但是，在任何环境中以分散的方式使用services是很困难的工作，而JBI的目的就是为完成这个任务提供一个专门的环境。

　　JBI的最底层是一个容器，它与J2EE中的容器一样定义了自身的部署构件。在我们深入之前，让我们先详细了解一下JBI的主要构想。

　　首先，它关注了Web services的核心部分:在终端之间传输的SOAP 消息/信封。这种数据段或标记能够包含被服务于很多应用的信息。不仅如此，根据发送端或接受端的不同，它还能协助把某个业务逻辑与数据适配。

　　现在，回过头来看看今天的Web services。在Web services出现之前，对于很多企业应用来说，使用面向消息的中间件系统或者MOM实现异构系统之间的通信已经足够了。Web services的出现同样是处于这个目的。用MOM的基于消息的架构和Web services很类似，被服务的数据也能在应用之间进行无缝操作。

　　这种场景可以被应用到典型的J2EE环境中，并通过JMS或JAX-RPC等技术进行服务。这种做法对简单部署是可行的，但正如前面提到的，当进行很复杂的设计时，现有的容器则显得很难用。于是JBI试图解决这个问题。

　　JBI提供了一种正规消息路由器(Normalized Message Router,NMR)，说白了，就是一个地点。在这个地点，所有基于消息的数据片段——SOAP片段、MOM消息、HTTP数据或其它信息——被聚合、集中、应用到业务逻辑、传输，如果有必要则被转换成其它格式并随后被分派到最终目的地。

　　先前的描述说明了为什么JBI被称为ESB。它很适合企业级应用，因为它通过一种总线型架构的基于消息的手段到达了适应大范围的消费者和提供者的目的。现在，让我们看看除了NMR还有什么构成了JBI。

　　和JBI环境直接交互的是两个部分，JBI machine和JBI binding。JBI machine定义了部署构件以及在环境中管理它们的方式。本质上，它是提供商设计的黑盒，用于在JBI中支持他们自己的模型。另一方面，JBI binding则被环境通过专门的业务协议与外部世界进行通信。

　　现在，再让我们把这些概念放到真实的JBI实现ServiceMix中。ServiceMix是完全用JBI的思想开发的一个开源项目。它可以支持多种绑定，包括HTTP、JMS、平面文件以及RSS，还提供了一系列类似BPEL、Schema Validation、JCA 和缓存等服务。

　　与ServiceMix协作的还有基于JMX的管理接口以及用来与JBI构件通信的对本地客户端API。尽管本文不对ServiceMix功能做进一步说明，但你可以很容易地下载该软件然后继续学习。下面，让我们来看看一个可部署在ServiceMix上的真实的JBI构件，这样你会对它有点感性认识。

　　Listing for JBI Components - File Sender & File Receiver.

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns:my="http://servicemix.org/demo/">
<!-- the JBI container -->
<container id="jbi">
<property name="useMBeanServer" value="true"/>
<property name="createMBeanServer" value="true"/>
<property name="dumpStats" value="true"/>
<property name="statsInterval" value="10"/>

<components>
<!-- Write files to the outbox directory -->
<component id="fileSender"
service="foo:fileSender"
class="org.servicemix.components.file.FileWriter">
<property name="directory" value="outbox"/>
<property name="marshaler">
<bean
class="org.servicemix.components.util.DefaultFileMarshaler">
<property name="fileName">
<bean
class="org.servicemix.expression.JaxenStringXPathExpression">
<constructor-arg value="concat('sample_', /sample/@id, '.xml')"/>
</bean>
</property>
</bean>
</property>
</component>

<!-- Look for files in the inbox directory -->
<component id="filePoller" service="foo:filePoller"
class="org.servicemix.components.file.FilePoller"
destinationService="foo:fileSender">
<property name="workManager" ref="workManager"/>
<property name="file" value="inbox"/>
<property name="period" value="1000"/>
</component>
</components>
</container>

<!-- the work manager (thread pool) for this container -->
<bean id="workManager"
class="org.jencks.factory.WorkManagerFactoryBean">
<property name="threadPoolSize" value="30"/>
</bean>

</beans>

　　JBI规格说明书本身并没有定义构件应该如何编码。请注意，ServiceMix用XML风格的语法定义了两个核心构件，关联到特定的类和属性。在把这种结构部署到ServiceMix以后，环境就会创建一种查询构件，负责从系统和其它构件中读取存档信息，然后把读取的值返回到文件系统。

　　该文件系统是JBI中非常基本的场景，因为信息就是从JBI环境(NMR)原样集中的，然后被返回到同样类型的绑定(文件系统)。但是很明显，一旦JBI环境有能力把任何业务逻辑适配成数据，例如BPEL或schema validation，然后重定向到其它类型的绑定，例如HTTP或RSS，那么就不只是返回到文件系统了。

　　正如你意识到的一样，当一用到JBI，操纵及分发数据的可能性就很大，但即使JBI用Java的方法实现了SOA，JSR-208规格说明书还是受到了批评。IBM和BEA是Java/J2EE领域的两个主要推动者，他们就不支持这个新项目。尽管如此，还是有像ServiceMix这样的小项目开发者和一些闭源开发组织打赌，一个培育良好的JBI市场将和J2EE的情况差不多。

　　假如你正在Java中使用Web services或者为了复杂的集成任务使用基于消息的设计，你应该对JBI的进展特别关心，因为它能为执行这样的任务提供更健壮的平台。就算你对JBI/ESB是否能加入J2EE协议栈还存有怀疑，继续关注还是有帮助的，因为它可能会成为应用服务器领域像Spring那样的事实上的“第三容器”或轻量级的容器扩展，为Java提供SOA能力。