我對SOA的理解

每次給客戶做工作流程培訓，都要接觸不同的行業，但我每次都被問了一個同樣的問題：HongSoft老師，請問應該怎麼理解SOA？這個問題其實和工作流程培訓關係不大，但現在如火如荼的SOA的推廣都和BPEL扯上了關係，而BPEL又和工作流程間“說不清，道不明”，所以我還真要說說，我是怎麼理解SOA的。

7/80年代，流行的是過程式程式設計。我們一般要採用自頂向下分析方法做功能分解，這個是最自然最原始的想法，而分解的單位就是function。就比如用學生報到交學費為例：學校有3個部門：教務處負責登記；財務處負責收學費；政務處負責發行李，可能還要收住宿費。
這裡就會有4個function存在。登記();收學費();發行李();收住宿費()。首先要明白的一點就是：這裡是按學校的內部規則（軟體系統內部功能）來劃分的，不是從學生（使用者）的角度來考慮。然後如果你做過比較大型的C語言的開發應該會知道一點：收學費()這個function和
收住宿費()這個function兩個名稱很有可能都取名為了收費()，在其中一個function是放在.so包中的情況下，C編譯器是不一定抱錯的。曾經有個這樣的問題花了我2天的時間來排查（用到了第3方公司的包）。

8/90年代出現了oo。oo的核心是對象。這裡可能就有3個包：教務處/財務處/政務處；政務處這個包可能還會分為好幾個對象：檢查員對象檢查財務處蓋章，倉庫員對象負責發行李等等。這樣就解決了過程式程式設計的問題，而且對學生（軟體的使用者）來說，是基本按使用者的思路來考慮的，這也是老毛同志“為人民服務”的思路。

但這樣其實是不夠的。檢查員對象檢查財務處蓋章，是和另外的財務處包掛鈎的。財務處包可能會經常發生變動：今年的特招生要多收3W/year；明年的特困生要可以貸款入學。。。。等等。這樣就會對檢查員對象檢查財務處蓋章產生影響：可能上面沒有章，但也要讓該生入住。
在這樣的情況下，就產生了用service為核心來架構軟體系統的思路。service是按實際的公司專屬應用程式為單位來劃分的。 比如 政務處手續就可以定為一個這樣的service: 檢查員對象檢查財務處蓋章-->收住宿費-->發行李。service實際上是一個流程，而其中的一個流程單元有可能要和另外的service產生關係。SOA這樣來劃分系統的作用，就是減少服務和服務之間的耦合。
我們現在的機關單位提倡的”一站式服務“在SOA架構下變成了很大的可能。學生到“學校報道處”交了學費，填表。然後後面的執行流程自動運轉，自動到“教務處負責登記；財務處負責收學費；政務處負責發行李”等不同的service裡面去，最後，“學校報道處”通知學生：請你到B-305入住。

從上面的技術分析，也可以看到管理領域，特別是BPM管理領域的一些思想。 

=========================

08.16修改：經過網友指認，本文參考了

http://www.hibernate.org.cn/viewtopic.php?t=14437&highlight=   對原貼的作者表示感謝！

另外請看

http://blog.csdn.net/hongbo781202/archive/2006/08/16/1069051.aspx  和一個HW人的BPEL交流