開源ESB-ServiceMix服務總線

Apache ServiceMix是小巧的開源集成容器，它結合了Apache ActiveMQ、Camel、CXF和Karaf的特性和功能到一個強大的運行平臺，你可以用它構建屬于自己的集成解決方案。它提供了一個由OSGI技術支持的全面的企業預備ESB。

其主要特性（features）包括：

• 基于Apache ActiveMQ的可靠消息
• 基于Apache Camel的消息、路由和EIP（Enterprise Integration Patterns）
• 基于Apache CXF的WS-*和RESTful web服務
• 由Apache Karaf技術支持的基于OSGI的服務運行環境。

通過另外可安裝的特性（features），ServiceMix也支持：

• Activiti的BPM引擎
• Apache OpenJPA的完整的JPA支持
• Apache Aries的XA事務管理
• 仍舊支持JBI標準（在ServiceMix 3.x系列之后已廢棄），通過Apache ServiceMix NMR來支持，Apache ServiceMix NMR包含了豐富的Event、Messaging和Audit API。

構建ServiceMix應用方式主要有OSGI Blueprint，OSGI聲明式服務和Spring DM（legacy）。可以看到對于一些常見的基礎標準常見，直接使用Bludeprint配置文件即可以完成配置。

ServiceMix的官方網站地址為： http://servicemix.apache.org/ 。 其下載和安裝部署也相對簡單，在下載完成后，可以直接通過QuickStart里面的例子對ServiceMix的基礎功能進行熟悉，以最簡單的兩個文件目錄文件集成傳輸為例來進行說明如下：

首先是需要編寫BluePrint.xml的配置文件，具體如下：

由于ServiceMix本身是基于OSGI和Karaf的組件化熱部署框架，因此在配置文件開發完成后，只需要將該配置文件拷貝到Deploy目錄下即可以完成該文件路由服務的部署。在部署完成后的服務運行后，我們將文件拷貝到camel/input目錄下，可以看到文件會被傳輸和包括到output目錄下。

對于具體部署的日志和狀態可以通過 log:display 命令進行顯示。

對于ServiceMix本身也提供另一個簡單WebConsole端，可以通過：

>>features:install webconsole

進行Console管理端的安裝，安裝完成后通過 http://localhost:8181/system/console 地址訪問，以smx/smx進行登錄，登錄后可以看到當前安裝的組件本身的狀態，可以查詢總線運行相關的服務日志信息。

當前ServiceMix的版本為6.1版本，雖然仍然有對JBI規范的支持，但是也可以看到其核心已經轉換為Camel，ActiveMQ和CXF三個核心開源組件的集成。同時基于Karaf實現的OSGI運行環境和容器。Karaf作為一款成熟而且優秀的OSGi運行環境以及容器已經被諸多Apache項目作為基礎容器。

對于ServiceMix本身由于重點是在ESB服務運行引擎和開源組件的集成，因此可以看到在SOA治理管控，可視化的服務設計和開發方面都相對欠缺。而且當前ServiceMix相關的文檔資料極少，實際在企業應用的場景也不多，如果要學習ServiceMix其核心需要學習的內容還是基于Camel的集成，消息中間件和CXF服務化框架，這三者本身是ServiceMix的基礎。

對于服務開發中存在的個性化規則和邏輯的處理，ServiceMix提供了足夠的開放性和靈活性，可以通過Eclipse環境進行plugin插件開發，開發完成的插件可以直接部署到deploy目錄中。

在JBOSS Fuse ESB被紅帽收購了做了較大的整合和商用化，即推出了JBOSS FUSE ESB引擎和基于JBOSS Developer Editon的服務可視化設計和開發。該ESB引擎本身仍然是基于Camel底層的可視化設計和實現，通過設計器的協助可以更加快速和高效的配置和開發ESB服務。

ESB在JAVA領域主要有兩種標準，一種是Sun提供的JBI業務集成規范，一個則是由BEA和IBM提出的SCA/SDO標準。可以看到對IBM和Oracle的ESB平臺基本采用的是SCA/SDO的標準。而對于開源的ESB如ServiceMix，JBOSS ESB等更多則是基于JBI規范進行實現。

最后在簡單說明下OSGI和JBI規范

OSGi(Open Services Gateway Initiative,開放服務網關協議)提供了一個面向服務組件的編程模型，基于 OSGi 編程，具有模塊化，標準化，面向服務，動態性，易復用，易擴展，易部署等諸多優點。

OSGi 帶來了規范化的模塊劃分，低耦合的模塊間關系，統一的模塊開發方式，可動態插拔的模塊管理環境。開發 OSGi 應用程序的第一步是在需求分析的基礎上進行精心的模塊劃分，模塊劃分的原則是盡量保持單個模塊的獨立性，使模塊與模塊之間的耦合降到最小，每一個模塊暴露給其它模塊的信息最少，盡量讓模塊之間使用 OSGi 框架提供的服務注冊機制來通信。一般可采用一個模塊一個 Bundle 的方式，并為每一個 Bundle 在 Eclipse 環境中建立一個 Project 來進行開發，由于模塊與模塊之間的耦合很小，各個 Bundle 之間并不會象傳統的開發方式中的各模塊之間那樣存在糾纏不清的包和類的引用關系，因此大部分Bundle的開發工作可以并行進行而不會互相影響。

JBI的本質是一種服務總線思想。JBI的目標是創建一個用于各種Java組件服務集成的運行環境。JBI容器以一種可插拔的方式集成不同類型的服務，而不是通過編寫客戶端代碼來實現服務的集成。目前流行的服務容器有Servlet容器、EJB容器、JMS容器。

1. Servlet容器只能處理以HTTP/SOAP協議傳輸的消息（接收與響應）；

2. EJB容器只能處理RMI協議傳輸的消息；

3. JMS容器則處理的是JMS協議傳輸的消息；

它們之間無法進行通訊，如果想集成上面不同類型的容器服務，則必須有一種能融合以上不同容器的 新容器出現。JBI就是基于解決這種問題的思路出現的，JBI提供了各種各樣的容器綁定組件（Binding Component,稱BC）,BC專門負責接收各種各樣的傳輸協議的消息與發送請收消息給外部容器。當然JBI還提供其它的功能，要不這純屬一種代理 了，就沒什么意義；

JBI提供處理各種業務的組件（即Service Engines組件，稱SE）的消息，比如接收到HTTP的消息后需要轉發給外部組件EJB，則需要SE組件來進行轉換（更準確的說是Transform SE組件）。其實BC與SE之間是無法直接通信的，所有的消息都是通過傳輸通道（Deliver Channel）傳送到NMR（Normalized Message Router），再由NMR通過DC將信息轉到SE或BC的。