bsp;service中就已經(jīng)采用互操作技術了。在SOA中，通過服務之間既定的通信協(xié)議進行互操作。主要有同步和異步兩種通信機制。SOA提供服務的互操作特性更利于其在多個場合被重用。
　　·服務是自治的(Autonomous)功能實體。服務是由組件組成的組合模塊，是自包含和模塊化的。
　　SOA非常強調(diào)架構中提供服務的功能實體的完全獨立自主的能力。傳統(tǒng)的組件技術，如.NET Remoting， EJB，COM或者CORBA，都需要有一個宿主(Host或者Server)來存放和管理這些功能實體；當這些宿主運行結束時這些組件的壽命也隨之結束。這樣當宿主本身或者其它功能部分出現(xiàn)問題的時候，在該宿主上運行的其它應用服務就會受到影響。
　　SOA架構中非常強調(diào)實體自我管理和恢復能力。常見的用來進行自我恢復的技術，比如事務處理(Transaction)，消息隊列(Message Queue)，冗余部署(Redundant Deployment)和集群系統(tǒng)(Cluster)在SOA中都起到至關重要的作用。
　　·服務之間的松耦合度(Loosly Coupled)。服務請求者到服務提供者的綁定與服務之間應該是松耦合的。這就意味著，服務請求者不知道提供者實現(xiàn)的技術細節(jié)，比如程序設計語言、部署平臺，等等。服務請求者往往通過消息調(diào)用操作，請求消息和響應，而不是通過使用 API 和文件格式。
　　這個松耦合使會話一端的軟件可以在不影響另一端的情況下發(fā)生改變，前提是消息模式保持不變。在一個極端的情況下，服務提供者可以將以前基于遺留代碼(例如，COBOL)的實現(xiàn)完全用基于 Java 語言的新代碼取代，同時又不對服務請求者造成任何影響。這種情況是真實的，只要新代碼支持相同的通信協(xié)議。
　　·服務是位置透明的(location transparency)。服務是針對業(yè)務需求設計的。需要反應需求的變化，即所謂敏捷(agility)設計。要想真正實現(xiàn)業(yè)務與服務的分離。就必須使得服務的設計和部署對用戶來說是完全透明的。也就是說，用戶完全不必知道響應自己需求的服務的位置，甚至不必知道具體是哪個服務參與了響應。
　　4.三個抽象級
　　從概念上講，SOA 中有三個主要的抽象級別：
　　·操作：代表單個邏輯工作單元(LUW)的事務。執(zhí)行操作通常會導致讀、寫或修改一個或多個持久性數(shù)據(jù)。SOA 操作可以直接與面向?qū)ο?nbsp;(OO) 的方法相比。它們都有特定的結構化接口，并且返回結構化的響應。完全同方法一樣，特定操作的執(zhí)行可能涉及調(diào)用附加的操作。
　　·服務：代表操作的邏輯分組。服務可以分層，以降低耦合度和復雜性。一個服務的粒度(granularity)大小也與系統(tǒng)的性能息息相關。粒度太小，會增加服務間互操作通訊的開銷；粒度太大，又會影響服務面對需求變化的敏捷性。
　　·業(yè)務流程：為實現(xiàn)特定業(yè)務目標而執(zhí)行的一組長期運行的動作或活動。業(yè)務流程通常包括多個業(yè)務調(diào)用。
　　在SOA中，業(yè)務流程包括依據(jù)一組業(yè)務規(guī)則按照有序序列執(zhí)行的一系列操作。操作的排序、選擇和執(zhí)行稱為服務或流程編排。典型的情況是調(diào)用已編排服務來響應業(yè)務事件。從建模的觀點來看，由此帶來的挑戰(zhàn)是如何描述設計良好的操作、服務和流程抽象的特征以及如何系統(tǒng)地構造它們。這些涉及服務建模、特征抽取的問題已經(jīng)成為現(xiàn)階段人們關注的焦點。
　　三、建立一套行之有效的，在項目啟動階段就應該得到客戶認可的需求管理制度 
　　對變更的內(nèi)容進行嚴格的控制實施需求變更管理需要遵循如下原則：
　　1.建立需求基線。需求基線

    項目經(jīng)理勝任力免費測評PMQ上線啦！快來測測你排多少名吧~

    http://m.opto-elec.com.cn/pmqhd/index.html