最早遇到Service Oriented Architecture(SOA)相關的專案,快要回推到約五年前的專案了,當時SOA如日中天,不論是技術相關書籍網站、或是商業相關雜誌,幾乎一窩瘋的推廣SOA,有點像現在在談的雲端運算的情況。現在回過頭來看SOA,當然就有些個人的想法,不過也因為是個人的看法,如果有誤還煩請見諒與指教。

 SOA_Cartoon.jpg 

<圖片引自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是一個很好的選擇,但若是高度仰賴交易控管來做關鍵性的業務系統,建議先不要納入,否則很可能會是一個大黑洞,不斷的將資源向內捲入而無法掙脫了。


創作者介紹

Min's Web Life: 談網路產業研究與生活閒聊

miin1130 發表在 痞客邦 PIXNET 留言(0) 人氣()