最早遇到Service Oriented Architecture(SOA)相關的專案，快要回推到約五年前的專案了，當時SOA如日中天，不論是技術相關書籍網站、或是商業相關雜誌，幾乎一窩瘋的推廣SOA，有點像現在在談的雲端運算的情況。現在回過頭來看SOA，當然就有些個人的想法，不過也因為是個人的看法，如果有誤還煩請見諒與指教。
<圖片引自gemsres.com/story/sep07/431009/SOA_Cartoon.jpg>
SOA促進了SSO(單一登入)的快速成長
SOA是一個多系統的平台架構，當然也包含了安控機制在內，簡單的說，如果要推行SOA，最好要將SSO一併規畫在內，實作方式有很多，LDAP是一種常見的方式，就這個角度來看，SSO可以算是之中推動最好的一部份，就個人所經歷過的專案，不論有沒有採用SOA，幾乎都有規畫SSO的作業。
ESB的興起，讓SOA更容易實作
Enterprise Service Bus(ESB)主要的作業，就是負責各項服務的訊息繞徑，在早期實作的時候，並沒有這類工具，所以我們只好拿流程引擎來充當，這讓整個設計的複雜度提高了許多，經由ESB這類工具的簡化，讓我們在實作上更加簡單，甚至現在還有免費軟體可供使用了，除非您是建置大系統，個人覺得許多免費的已經相當不錯了，沒有必要浪費這些錢，並且還受氣於大廠的高傲態度。
Web Services 逐漸被REST所取代
促成SOA的興起，還有一個重要因素，那就是Web Services應用的興起，經由Web Services解決了不同程式語言間API(應用系統介面)資料拋轉的問題，但Web Services的問題也是顯而易見，就是他複雜與重量級的溝通方式如SOAP，是一種沒有效率的溝通方式，這讓REST這類輕量級的溝通方式獲得了更大的成功，這幾年在實務上，Web Services仍有在使用，但REST卻是看到更多。
交易控管的難以使用
SOA有一個很大的特色，就是可以跨系統的服務整合，除非您是一對一的連接，否則很難迴避掉交易控管的問題，而現行除非人工撰寫相關的程式或透過MQ來，否則很難做好交易控管，但前述方式的成本相當大，而且不容易做的很完善，這個部份，個人認為是SOA在推動上的一個很大帳礙，而這障礙還會受限於現有系統所使用老舊技術問題。
最大致命傷，誰說舊系統不用改?
當最初在推動SOA時，一個很大的利基談的就是可以將舊有的系統Reuse，以服務的觀點重新包裝就可以了。但個人的經驗卻跟我說，這句話要打上一個問號! 怎麼說，可以從兩個角度來說明，(1)忘了物件導向或完美的多層次設計架構吧!! 這些後期提出的架構設計概念在早期是沒有的，加上臺灣多是專案導向，能在時限內趕出來就很拼了，期待利用現有物件程式，開發出新的服務介接，有時候重寫還比較快。(2)服務的定義是什麼，一個API可以稱為服務，一個具有完整商業邏輯的作業也可以稱為服務，重新規畫過的服務，就如同(1)所提到的，很可能是現有系統根本就不存在或分散在各處，混亂的程式架構，外加原開發者因為公司用過即丟的態度，早就換了好幾手，重寫有時候是更好的選擇，但新寫的程式從未經過歲月的磨練，不穩定是正常的，成本將比遠先預估高的多。
結論
綜合來說，個人覺得SOA是一個很不錯的架構觀念，但在實務上，有兩主要個問題要克服，首先就是交易控管的問題，另一個就是舊系統在開發時的架構問題。第一個問題有可能隨新技術的發展而獲得根本的解決(但暫時未見到，就稱為歷史包袱吧)，第二個問題則很難利用技術來解決，除了服務的規畫外，也跟舊系統的發展有很大的關係，建議在成本規畫要保守一些，只是反過來說，就算未來要重寫，還不如趁導入SOA時一併重寫，更符合一次性的經濟效益。簡單的說，如果您的系統沒有複雜的交易控管，或是可以容忍偶爾有交易控管上失誤，SOA是一個很好的選擇，但若是高度仰賴交易控管來做關鍵性的業務系統，建議先不要納入，否則很可能會是一個大黑洞，不斷的將資源向內捲入而無法掙脫了。
留言列表
