一個糟糕的SOA應用不如不用？

不同的人對於SOA的認識各不相同。有人認為它是概念，有人認為它是架構，有人則認為它是服務。本文將說說SOA在整個應用軟體開發生命週期中的作用。

    在SOA的概念提出以前，應用軟體開發過程就已存在很多難題。最早的CORBA、COM等就是希望能借助工具解決這些問題，很可惜它們沒有成功。但SOA 就是成功的嗎？事實上，換一個角度看，SOA並沒有解決應用開發中需求、交付和管理這三個階段的問題，甚至有可能讓它們變得更加糟糕。

需求階段

    應用開發皆始於需求。這是某個業務用來明確它到底需要IT系統幫助滿足哪些要求的階段。在這一階段，最大的難題是橫亙在業務人員和技術人員之間的溝通鴻溝。說鴻溝可能是誇大了，也許這只是一道小小的縫隙，也足以讓需求陰差陽錯。

    業務人員無法讓技術人員完全和準確地理解他們所需要的功能。技術人員同樣無法將業務需求轉換為規範的需求文件，而只有根據文件開發人員才能明確如何展開產 品開發。進一步地，再將這些需求規範轉換為實際產品時，業務人員同樣無法充分理解它們，以至沒法決定是否可以開始由技術人員構建原型了。

    SOA的應用並不能解決這兩方面的問題。它沒有為技術人員和業務人員提供一個通用的“語彙表”，讓他們能夠彼此理解對方所需要的和表述的。所以，在SOA驅動開發專案的需求階段，對於需求和規範文件的錯誤理解依然存在。

    對於業務人員，他們更適合討論使用者希望建立怎樣的服務，而無法理解資料庫、應用伺服器、介面這些實現服務的具體技術。隨著SOA的應用，技術人員開始考慮 採用何種標準技術來保證服務的規範，是Java、.Net、BPEL、SOAP還是XML？這些對於使用者依然沒有意義。SOA的應用讓開發人員不再擔心在 基於元件開發時代就已規範的細粒度元件問題。但是，業務人員依然對諸如EJB、BPEL和XSLT等SOA元件的粒度大惑不解。所以，SOA並沒有彌補需 求階段的這一溝通問題。

交付階段

    再來看看產品交付階段。在這一階段，開發者已經實現了全部或部分功能，並準備將其形成真正的產品。這一階段面臨的最大問題是交付時間，而追根溯源問題還是來自整個生命週期的早期——需求階段。

    由於對需求的誤讀，開發人員可能錯誤地或者部分地實現了所需功能。沒辦法，業務人員正好讓技術人員一遍一遍地進行修改，直到使用者滿意為止。採用了Web服務和SOA，是否就能讓這一過程變得更加容易呢？事實上，可能性不大。

    當開發人員採用細粒度元件構建系統時，他們可以很容易地返回初始設計，並修改細粒度元件，甚至是大段程式碼，而無需太過擔心這些變化會影響到正在開發的其他 專案，這些專案將更多地依賴於粗粒度服務。採用SOA後，系統可能是多個Web服務的聚合，如果某一應用服務發生改變，就必須考慮是否會影響整個系統中其 他並行服務的實現。在最壞的情況下，為了滿足新的業務需求，可能需要更換所有的現有服務。

    更糟糕的是，對需求的重新認識，可能會發現在服務庫里根本沒有可以替代的可選服務，開發人員不得不從頭開始建立一個或更多的新服務。這些新服務同樣必須滿足IT部門在封裝、標準、可重用性等方面的整體要求。無疑這將嚴重影響交付進度。

    IT部門承諾產品的交付時間大都基於一個進度估算，很多情況他們僅僅考慮了通過已有服務聚合產生新產品所需時間。當突然需要構建新服務時，交付時間就不得 不隨之延長。對於業務人員和使用者，他們不關心產品是否採用了更為高效地開發方式，他們所想要的只是根據預期按時交付產品這樣一個結果。

    因此，SOA同樣沒有解決如何令使用者滿意地交付應用和系統這個大難題。

管理階段

    最後來看看應用生命週期的管理階段。在SOA出現之前，管理應用軟體開發專案實在不是一項容易的工作。採用SOA以後，根據SOA應用開發所採用的粒度大 小，整個開發專案需要分解成若干小的部分，以便開發團隊能夠採用分散式地方式對它們進行開發。對於管理者，這同樣不是一件容易的事情。應用SOA本身對此 並無幫助。而專案經理則開始需要應付諸如選擇工具、標準、可重用性和文件等涉及開發的標準問題。

    SOA應用給管理者們帶來了一個必須時時關注的服務庫，此外，他們還需要關注諸如SOA治理等問題，這包括了誰能“擁有”某些特定服務，服務的版本控制，共享服務的安全影響，以及這些共享服務的變化給其他應用帶來的影響等。

    SOA沒有解決管理應用開發專案的所面對的問題。事實上，它反而加重了管理人員的負擔。他們不得不時刻留心某一變化對本身和其他與交付業務相關應用服務的 影響。一旦應用程式交付，大部分的系統管理和服務管理技術都能幫助IT部門跟蹤瓶頸、錯誤或缺陷。相較於SOA部署，這些技術對於更多傳統應用基礎設施更 為適用。

一個糟糕的SOA應用不如不用？

    說了這麼多，希望讀者不要誤解我的意思。正確地實施SOA確實可以產生巨大的效益，它的可重用、更容實現複合應用（或稱之為聚合）的能力，甚至對於業務和 技術人員溝通語言的改善，都有相當的可取之處。但是，同樣也要看到，如果你不能首先控制應用開發最根本的挑戰，那麼SOA將是比基於元件的傳統開發方式更 大的挑戰。所以，一個糟糕的SOA應用不如不用。