hengheng123456789

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="

? <!-- 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能力。