每次給客戶做工作流培訓，都要接觸不同的行業，但我每次都被問了乙個同樣的問題：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管理領域的一些思想。
http://www.hibernate.org.cn/viewtopic.php?t=14437&highlight= 對原貼的作者表示感謝！
另外請看
http://blog.csdn.net/hongbo781202/archive/2006/08/16/1069051.aspx 和乙個hw人的bpel交流
對SOA的理解
昨天與兩個同事聊到soa，由於大家都有在電信領域開發的背景，討論中形成了對soa較為準確和生動的理解，特寫此文以記之。現在soa的話語權主要集中在ibm，bea這樣的大公司手裡，在我看來，他們最擅於將簡單問題複雜化，用時下流行的話說，叫做 忽悠 愣是可以把乙個簡單的soa，劃分若干個看似nb的組成要...
我對SOA的反思 SOA架構的本質
年初的時候，寫過一篇名為 國內eai正當時，bpm為時尚早，workflow持續增長，soa依然概念 的blog日誌。那個時候，我認為soa還依然是個很 虛 的概念。而現在，我只能說 sorry，那時候的我，錯了。soa已經不再是概念，而是乙個實實在在的構架了。在寫完那篇帖子之後，我一直在反思soa...
我對SOA的反思 SOA架構的本質
年初的時候，寫過一篇名為 國內eai正當時，bpm為時尚早，workflow持續增長，soa依然概念 的blog日誌。那個時候，我認為soa還依然是個很 虛 的概念。而現在，我只能說 sorry，那時候的我，錯了。soa已經不再是概念，而是乙個實實在在的構架了。在寫完那篇帖子之後，我一直在反思soa...