本身對WSO2 ESB 看法

這周沒想到要更新什麼內容，就把我最近工做接觸的WSO2 ESB簡單介紹下吧。

   

前提：

一切文檔，知識都要與官方文檔爲準。

WSO2 ESB：

http://wso2.com/products/enterprise-service-bus/

WSO2 ESB 文檔：

https://docs.wso2.com/display/ESB481/WSO2+Enterprise+Service+Bus+Documentation

   

我這篇博客不做具體作一步步的教程，須要學習的能夠參考官方文檔一步步的入手。

   

1. 那什麼是WSO2 ESB？

      

   我也不想去copy什麼是ESB。我舉一個例子吧。

      

   想一想在一個很大的公司，這個公司有2個大的部門。部門A，部門B。

      

   部門A有10個web service，5個是WCF開發的基於SOAP，安全校驗是A（好比 SAML Token吧），5個是restful安全校驗是B.

      

   部門A有5個web service，3個是JAVA開發的基於SOAP，安全校驗是A（好比 SAML Token吧），2個是restful安全校驗是C.

      

   而後前段業務須要快速開發移動APP，這須要後端service是restful風格的。因爲移動變化快，須要不用的需求，須要更多數據？

   後端的web service僅僅提供最爲基礎的數據，雖然全，可是沒有根據前段的業務去優化數據。

   有一天，移動APP須要調用部門A的service1（SOAP 風格）和service2（restful）和們部門B的service3（SOAP）去獲得相關數據，而後須要調用部門A的service4（SOAP） 去更新數據。

   這樣有2中方案：

    

   方案1：移動APP就須要處理不少，須要考慮不一樣service的協議和安全校驗。

   方案2：要求後臺開發一個service爲移動app提供服務。

    

   顯然方案1把太多的業務邏輯放在了前端。方案2，適應不了快速的APP開發。

      

   那麼ESB就出來了，它是做爲一箇中間層把移動app和後端的web service分開來。

   ESB會提供web sevice與移動app打交道，這樣就爲前端提供一個新的service，專門知足前端APP

   的需求。統一的協議，統一的安全校驗。

   這樣在ESB內部就能夠處理調用後端service的邏輯。

      

2. 一個簡單的例子。

   仍是上面的那個例子：

   有一天，移動APP須要調用部門A的service1（SOAP 風格）和service2（restful）和們部門B的service3（SOAP）去獲得相關數據，而後須要調用部門A的service4（SOAP） 去更新數據。

      

   這樣移動APP說，我須要一個新的service，那麼定義好須要那麼獲得那些數據，須要更新那些數據，須要什麼協議（soap，restful），須要數據的格式是什麼（xml，json）。。。。

      

   ESB就新建一個service提供這種服務。

   這ESB內部，獲得移動app傳來的數據，好比是xml把，而後把xml轉換成soap或者restful，而後再ESB內部調用後端service，而後把數據在轉換好，發給移動APP。

      

   WSO2 ESB提供不少組件，去處理請求。它能夠不移動app發過來的任何格式，轉換成任何格式，post到後端的service，獲得數據後，再把數據轉換成符合移動app的格式。

      

   在WSO2 esb能夠用腳本語言，JS，python，ruby處理不一樣格式之間的轉換。也能夠用

   org.apache.axiom.om （java）。。

      

3. 全棧工程師？

   這樣開發移動app的能夠在界面用js來寫，在服務端能夠node.js來寫，在後端的WSO2 ESB能夠用js來寫web service來獲得數據。

   這樣主要後端提供好基礎數據，前端就能夠全棧快速的開發知足需求的功能和產品。

      

   

這些僅僅是個人簡單理解和隨筆。工做中，我是在一個後端WCF webservice team的，最新咱們可能準備使用WOS2 ESB來爲移動app提供快速的服務，因此有機會使用WSO2 ESB來作前期的調查。