關鍵字：SOA 構建 原則 SOA是一種企業架構，因此，它是從企業的需求開始的。但是，SOA和其它企業架構方法的不同之處在于SOA提供的業務敏捷性。業務敏捷性是指企業對變更快速和有效地進行響應、并且利用變更來得到競爭優勢的能力。對架構設計師來說，創建一個業務敏捷的架構意味著創建這樣一個IT架構，它可以滿足當前還未知的業務需求。要滿足這種業務敏捷性，SOA的實踐必須遵循以下原則：
業務驅動服務，服務驅動技術
從本質上說，在抽象層次上，服務位于業務和技術中間。面向服務的架構設計師一方面必須理解在業務需求和可以提供的服務之間的動態關系，另一方面，同樣要理解服務與提供這些服務的底層技術之間的關系。
業務敏捷是基本的業務需求
SOA考慮的是下一個抽象層次：提供響應變化需求的能力是新的“元需求”，而不是處理一些業務上的固定不變的需求。從硬件系統而上的整個架構都必須滿足業務敏捷的需求，因為，在SOA中任何的瓶頸都會影響到整個IT環境的靈活性。
一個成功的SOA總在變化之中
SOA工作的場景，更象是一個活的生物體，而不是象傳統所說的“蓋一棟房子”。IT環境唯一不變的就是變化，因此面向服務架構設計師的工作永遠不會結束。對于習慣于蓋房子的設計師來說，要轉向設計一個活的生物體要求嶄新的思維方式。如下文所寫的，SOA的基礎還是一些類似的架構準則。
SOA基礎
在IT行業有兩個越來越普遍的發展方向，一個是架構方面的，一個是方法學方面的，面向服務的架構設計師可以從中有所收獲。第一個就是MDA（模型驅動架構），由提出CORBA的OMG模型提出。MDA認為架構設計師首先要對待創建的系統有一個形式化的UML（也是由OMG提出）的模型。MDA首先給出一個平臺無關的模型來表示系統的功能需求和use cases，根據系統搭建的平臺，架構設計師可以由這個平臺無關的模型得到平臺相關的模型，這些平臺相關模型足夠詳細，以至于可以用來直接生成需要的代碼。
MDA的核心就在于在設計階段系統就已經完全描述，這樣，在創建系統的時候，幾乎就沒有錯誤解釋的可能，模型也就可以直接生成代碼。但MDA有一些局限性：首先，MDA假設在創建模型之前，業務需求已經全部描述，而這一點，在當前典型的動態業務環境中幾乎是不可能的。第二，MDA沒有一個反饋機制。如果開發人員對模型有需要改動的地方，并沒有提供給他們這么一個途徑。
SOA的另一個基礎是敏捷方法（AM），其中非常有名的方法是極限編程（XP）。象XP這樣的AM提供了在需求未知或者多變的環境中創建軟件系統的過程。XP要求在開發團隊中要有一個用戶代表，他幫助書寫測試來指導開發人員的日常工作。開發團隊中的所有成員都參與到設計之中，并且設計要盡量小并且非形式化。AM的目標是僅僅創建用戶想要的，而不是在一些形式化模型上耗費工作量。AM的核心思想就在于其敏捷性－處理需求變更的敏捷性。AM的主要弱點是其規模上的限制，例如，XP在一個小團隊和中型項目中效果不錯，但是當項目規模增大時，如果沒有一個一致的清晰的計劃，項目成員很難把握項目中的方方面面。
從表面看來，MDA和AM似乎是相對立的－MDA假定需求是固定的，而AM恰恰相反。MDA的中心是形式化的模型，而AM恰恰要避開它們。但是，我們還是決定冒險把這些不同方法中的一些元素提取出來，放入到一個一致的架構實踐中。
文章來源于領測軟件測試網 http://www.kjueaiud.com/