SOA實現中的4個最差實踐

在鋪天蓋地的SOA宣傳文章中，最佳實踐是出現頻率最高的詞彙之一。相比起來，最差實踐就沒那麼風光了。但是，俗話說得好“吃一塹，長一智”，看看別人犯過的錯，未嘗對自己沒有幫助。最近，Information Builders的市場副總裁Jake Freivald就撰文介紹了SOA實現中常見的4種最差實踐，並針對每個實踐給出瞭解決方案：

1. 過分強調低階別的程式碼
   • 上榜理由：重用性差，難以根據業務的變化迅速地做出反應。
   • 解決辦法：關注業務級別的服務。將整個系統切分成邏輯的構建單元——即所謂的服務——將建立出一個隨業務需求一道成長的可持續解決方案。Jake Freivald將服務分為3層：細粒度服務、粗粒度服務和全域性服務。並寫道：

     當組織過於強調細粒度的服務時，其結果就是有太多無法聚合成業務層服務的服務。照這種方式編碼，將建立出難以維護或複用、低效且複雜的流程

2. 集中設計和部署
   • 上榜理由：其一，知識依賴個人，當這些人離開時，知識也隨之一起離開；其二，個人不可能熟悉所有系統，當需要設計和構建服務的系統超出其知識範圍時，難以設計出好的服務。
   • 解決辦法：分散服務建立。服務的分散化和本地維護，這使得粗粒度和全域性服務的開發者不必時刻關心底層資訊資產，而且底層服務開發者的變更不會影響到整個系統
3. 撕碎並替換遺留軟體
   • 上榜理由：只看到了資料的重要性，卻沒有意識到遺留應用同樣也是資訊資產之一。並且由於對資料遷移的困難估計不足，造成專案延誤，更有甚者直接有損於日常業務。
   • 解決辦法：重用為王。只要遺留系統還能工作，就不要管它。為技術而升級技術永遠不是一個好的業務選擇。
4. 購買沒有支援的軟體
   • 上榜理由：缺乏對操作SOA軟體的足夠認識，很可能會構建出過於複雜的系統，以及沒有為任務選擇合適的工具。
   • 解決辦法：要成功，就要有支援。就算企業有SOA架構師來幫助組織來建立SOA的原則，但要想成功，依舊需要把工作落到實處。

     組織設計的成果是訊息轉換還是訊息分拆，到底有多大影響？最好預先花時間把這搞明白，免得再在架構上線執行之後去去和效率問題相糾纏。通過足夠支援的保駕護航，組織可以避免開發出過於複雜的系統，並知道哪個工具是針對哪項工作的合適工具。

Loraine Lawson對這篇文章評論道

Freivald特別提到了與“使用SOA作為一種整合解決方案”相關的最差實踐。現在，我知道，有些人說SOA不應該用作整合。其總的觀點是避免點對點、緊耦合的方式。但是，如果做得好，SOA可以解決很多你的整合問題。

Jignesh Shah則對於Freivald的“分散服務建立”表示出了不同看法（注：見該文的評論部分）。

看到服務的“集中設計和部署”被列為一個最差實踐著實令人覺得有趣。我們越來越多地看到客戶建立“共享服務”組織給他們乳臭未乾的SOA來掌舵和提供動力。這樣一個組織負責圍繞企業範圍內的核心繫統識別、設計和交付服務。這有幾個好處，包括可以全盤考慮整個企業的服務組合的塑形，簡化資助模型，以及打通政策壁壘。

這樣一個組織要對他們準備在其之上構建服務的系統非常瞭解，Freivald在這一點上是對的。這是為什麼實際常常選擇整合團隊作為SOA共享服務組織的原因。這個小組有企業的視角，有處理核心系統的經驗，理解異構環境下的挑戰，並擁有所要求的中介軟體相關的技術技能。

Freivald建議的“分散服務建立”方法實際要求一個理想化的公司，在那裡，他人利益排在每個小組利益的前面。這在大多數開始建立SOA的大型組織中實在難以出現。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/14780828/viewspace-573218/，如需轉載，請註明出處，否則將追究法律責任。