在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部門在封裝、標準、可重用性等方面的整體要求。無疑這將嚴重影響交付進度。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
