需要ESB/SOA才能做BPM嗎?

要談這個題目，自然得解釋一下ESB/SOA。由於相關的專業文章非常多，在此僅簡單做個入門概念性的介紹。

先由知名度較高的SOA說起：SOA全名Service-Oriented Architecture。【S】指的是Enterprise Service（ERP、CRM、HR、MRP…etc）也就是企業資訊應用服務，【O】則跟另一個有名的【OO】(Object Oriented－物件導向)的第二個O相同，指的是以某某為主導取向的概念。非軟體背景對OO不了解的人則請參考這裡，有對於一般性Oriented用法的舉例解釋。【A】則是指設計架構，對土木而言是建築架構，對資訊而言就是系統架構。簡單合起來說就是以企業資訊應用為導向的系統架構，主要目的一是與當年OO類似：OO希望能透過物件化的程式設計來增進新軟體開發時程式元件模組化的程度。而模組化的好處一是讓不同開發人員所開發的程式仍能以較有效率的方式兜合起來，一是提升重複利用率(re-use)進而縮短新軟體開發所需的時間，最理想的狀況則是靠物件的【組裝】便可完成大部分的工作。而SOA的理想則是將【組裝】的對象由物件化程式的層次提升到了應用服務的層次，期望透過【服務導向的組裝概念】來最大化重複利用既有的系統服務而不用老是處理一些類似的重覆工作。這其實也不算新概念，LDAP就可算是一個已經相當成功普遍的Service-Oriented應用：不同的系統均可透過標準的LDAP介面來做登入認證，免除了各系統各自帳號與密碼管理的問題。SOA則是將層面拉大到將所有企業系統均納入相同的期望考量，希望所有的企業系統在其他系統有需要時均可透過類似LDAP一般明確公開的方式來直接取得所需的服務而不用每次都得大費周章的點對點EAI一番。且無論是哪一家軟體公司的產品，內部如何實作，開放出來供其他系統取用的服務均採用相同方式，而不再是SAP有RFC、Oracle用Store Procedure、IBM用MQ與其他不同的機制來做整合。好比現在您能瀏覽這篇文章，Google能搜尋到對的關鍵字文章乃是因為大家均是採用相同的html標準來互動。SOA想要架構的就是類似的【書同文、車同軌】的跨系統溝通世界。

ESB全名Enterprise Service Bus，顧名思義簡單說來就像園區的交通車，只是一般交通車是將乘客運輸到園區的不同站牌（公司/工廠）。而ESB的乘客是資訊（如:XML），站牌則是不同的Enterprise Service（ERP、CRM、HR、MRP…etc）。至於為何需要把資訊在不同系統間傳遞，為的自然就是要做EAI啦，好讓企業的資訊系統能更有效且準確的提供所應提供的服務（Service），這裡有些Java Open source相關的選擇資訊供有興趣者參考。

而ESB與SOA的關係由【Bus】與【Architecture】的差異就可感覺出企圖心的差異：ESB提供的是較具體較明確的運輸載具(公車)與路線，而SOA想解決的則是架構性的問題。好比在設計園區的交通網絡架構時，固定路線的交通車（小巴）是一種可考量的普遍選擇但卻不一定是唯一的選擇。對於特殊地區特殊需要的園區而言，或許地鐵、人員輸送帶、直升機等會是更好甚至是不得不的選擇。ESB注重的是架構一個可運行無礙的公車路線與站牌交通網。SOA則是除了交通網的建造外更要確保既有與未來要進駐之廠商需能符合這個交通網的交通相關規範。

由以上的簡介，對BPM已有些概念的人當可感覺出SOA的理想與BPM的部份理想其實相當接近：將各資訊平台均當作支援企業的資訊服務，而非單一平台大小通吃。不過在本質上則還是不同的：SOA是一種技術上的資訊架構方法論，BPM則是管理上的流程協調作業理念。

歷史事實是在沒有SOA之前，BPM產品就已經出現並成功應用。好比國光號不會因為高速公路封閉就因此停開，因為還有省道等替代道路可用，只不過走省道會比較慢比較耗油因此可能得調整票價與班次時間。同理沒有ESB/SOA也不會因而無法做BPM。沒有ESB/SOA則當BPM的流程需要跨系統傳遞時就需依靠較傳統的EAI方式來開發，而有了ESB/SOA則在跨系統部分的整合開發就會簡單與標準化的多。好比沒有統一的portlet標準前，EIP(Enterprise Information Portal)要顯示其他系統的訊息都得從頭客製（短則一週長則月餘），有了portlet後則只要把各系統提供的既有portlet掛到EIP上即可立即顯示（deploy與調整平均半小時）。不過好比宣稱有提供portlet的系統不見得剛好有提供所需顯示於EIP上資訊的portlet，比方某HR系統有提供組織圖、公司行事曆等的portlet，但卻不見得會提供員工修改個人資料、薪資查詢、獎懲查詢等的portlet，因此當有需求在EIP上顯示相關資訊時那只有兩個方法：一是走回老路用EAI的方式達到，另一種則是對HR系統客製新的所需的符合標準的portlet。若僅為解決單一一次性的需求，前者技術上使用直接抓DB或是iFrame的方式可能比用portlet快的多，但是若哪天換了portal或是其他系統也剛好需要，那就得重新review。

　　同理有了ESB/SOA也不代表剛好BPM所需要的service都已經打包好等人用。只不過有了SOA，BPM與各系統就有了比較一致統一的溝通方式，不管是web service或是ESB等，BPM導入廠商不用再得RFC、MQ、Store Procedure等不同介面樣樣精通才能取得不同系統的資訊，因此導入跨系統BPM時的導入障礙與溝通曲線會因此大幅降低。

　　最重要的是之前於BPM會不會引起內部革命中曾提過，Business Process Refine是BPM重要精神之ㄧ，而對一個跨系統的BPM而言，要能靈活的Refine可不是一件簡單的事。但在理想的SOA架構下，BPM是將所需的Service依照業務流程需要依序【組裝】起來，因此增加了Business Process Refine的彈性與應變效率，也讓BPM得以朝理想更接近。