JBI架構思想

SOA在Java領域有兩套標準：一個是SUN推出的JBI（沒有得到BEA和IBM的承認），另外一個是：IBM和BEA等公司推出的SCA和SDO標準。

　　JBI之關注Java元件只處理Java元件的整合。

　　SCA實現了業務元件和傳輸協議的分離，可以處理各種平臺元件的整合。

　　SDO可以的自由讀取各種不同資料來源的資料。

　　另外，BPEL本質上是一種整合WebService服務的語言，也可以算作為SOA的一部分。

　　在此，詳細介紹JBI的架構思想。

　　一、認識JBI

　　JBI（Java Business Integration）中文翻譯為“Java業務整合”，是SUN釋出的一個用於Java元件進行整合的一個標準。

　　JBI的本質是一種服務匯流排思想。

　　JBI的目標是建立一個用於各種Java元件服務整合的執行環境。

　　二、認識JBI容器

　　JBI是一種思想，JBI思想的實現就是JBI容器。

　　JBI容器是為彌補現有J2EE容器的不足而出現的。

　　現有應用伺服器的容器型別：Servlet容器、EJB容器、JMS容器。

　　現有應用伺服器的容器不足：

　　a)、每種容器都有自己特殊的傳輸協議，相互之間不能直接通訊。比如：Servlet容器只能接受HTTP/SOAP的傳輸協議，EJB容器只能處理RMI的傳輸協議，JMS只能處理JMS的傳輸協議。

　　b)、是一個純粹的服務提供者，不是一個服務的整合者。也就是說，容器之間不能繼承服務。

　　c)、容器間服務的呼叫需要編寫客戶端程式碼。

　　JBI容器以一種可插拔的方式整合不同型別的服務，而不是通過編寫客戶端程式碼來實現服務的整合。

2、JBI容器的組成的三大部分：

　　a)、繫結元件（BC：Binding Components）：專門用來接收各種不同傳輸協議的請求，原理是JBI實現了各種不同協議的繫結元件，繫結元件可以細分為接收BC和傳送BC。接收BC主要負責傳送請求和接收響應，傳送BC主要用來呼叫外部的服務。

　　b)、服務引擎（SE：Service Engines）：這類元件只處理JBI容器內部的訊息。JBI容器通常在接收到訊息後，需要對請求的訊息做一些“處理”，然後再呼叫外部服務的提供者。根據功能的不同，將SE元件分為以下三種型別：

　　Transform SE：專門處理各種傳輸協議和格式變化。

　　BPEL SE：專門負責將Web Service進行流程編排。

　　Rules SE：專門負責通過規則將各種服務進行整合。

　　c)、JBI的規格化訊息路由器（Normalized Message Router）：是JBI內部訊息系統的核心，所有的組建之間不能交換訊息，只能通過NMR來傳遞。

　　在JBI容器內部，只有一種標準的規格化訊息（Normalized Message）。任務服務元件進入JBI環境之前，通過BC轉換為規格訊息NM。在JBI環境裡，所有的服務都不能相互呼叫，不論是請求還是回答訊息，都要先轉給NMR，再由NMR分發。JBI執行環境裡面的元件（SE、BC）和NMR都是通過NM來進行資訊交換的。

外部請求者將一個HTTP請求傳送給JBI容器，容器的HTTP BC接收請求，並將請求的訊息格式化為NM傳送給訊息接收轉換引擎，然後再將NM傳送給NMR，由NMR再將NM傳送給SOAP BC，SOAP BC將NM轉換為SOAP訊息傳送到外部的WS元件。執行後，訊息按照原路返回。

　　個人觀點：

　　JBI是SUN的標準，是SUN對J2EE容器的一種改進，SUN並不想相容其他語言的元件。

　　隨著SUN公司被收購，SUN之外的幾個巨頭都力推SCA標準，SUN的JBI標準將名存實亡，難以得到重用。

　　理解容器的工作原理，可以更清楚的認識JBI整合服務的原理和過程。如果只為學習開發，容器標準瞭解下即可，應多研究一下JBI標準API介面和規範。