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恰恰要避開它們。但是，我們還是決定冒險把這些不同方法中的一些元素提取出來，放入到乙個一致的架構實踐中。
在soa中有三個抽象層次，按照soa的第一條準則：業務驅動服務、服務驅動技術。am將業務模型直接和實踐連線起來，表現在平台相關的模型之中。mda並沒有把業務模型和平台無關模型分開來，而是把平台無關模型做為起點。soa必須連線這些模型，或者說抽象層次，得到單一的架構方法。我們將從五個檢視的架構實現方法來實現這個連線。
soa的五檢視實現方法
四個方框表示對乙個架構的不同審視方法，分別代表不同的涉眾（stakeholder）。弟五個檢視，use-case檢視涵蓋了其它檢視，在架構中扮演的是乙個特殊的角色。部署檢視將軟體對映到底層平台和相關硬體上，是系統部署人員對架構的檢視；實現檢視描述了軟體**的組織，是從開發人員角度出發的檢視；業務分析人員則利用過程檢視進行工作，它描述的是軟體系統的執行時特性。最後，邏輯檢視表示的是使用者的功能需求。在soa中，面向服務的架構必須能夠以use-case檢視中的用例將使用者連線到服務，將服務連線到底層的技術。
為了表示物件導向的架構是如何工作在這些檢視之上，讓我們將他們置於soa元模型的上下文之中。soa中兩個領域存在重疊：由業務模型和服務模型表示的業務領域和由服務模型及平台相關模型表示的技術領域（兩個領域共享服務模型）。業務使用者通過邏輯檢視和過程檢視處理粗粒度的業務服務，根據變化的業務需求，按照需要將它們安排在過程之中。另一方面，技術專家的工作是建立並維護服務和地層技術之間的抽象層。表示這些服務的中間模型，起到的是軸心的作用，業務以它為中心進行。
soa元模型從mda中繼承平台無關模型和平台相關模型，但是新增了am和使用者互動以及敏捷的反饋這兩部分，後者通過橢圓之間的雙向箭頭來表現。類似地，元模型通過引入由中心的服務模型提供的中間層抽象解決了am在伸縮性方面的問題。這樣，服務模型中的任何需求的變化，都會反映到使用者每天的業務處理中。同樣，由於底層技術是模型驅動的，技術專家也可以根據這些變化的需求迅速而有效地作出應變。
soa實踐和過去解決企業架構傳統方式的不同之處就在於其對敏捷性的支援。如前所說，soa的第三條原則就在於它總在變化之中。這種恆在的變化性環境是soa實踐的基石。如圖所示，涉眾（stakeholders，譯者注：rup中也有這個詞，表示軟體開發中涉及到的各種角色如：使用者、設計人員、開發人員乃至測試人員等等。）在乙個必需的基礎上影響到整個架構的變化。在當技術專家在每天的日常工作中不斷對變化的業務需求作出響應的這種情況下，設計階段和執行階段之間的界限變得模糊起來，很難清晰地分離這兩個階段。
剩下的部分
我們已經為面向服務的架構提供了乙個高層次的框架，其中mda和am的元素幫助工具的使用者來建立和維護soa。但是，soa中還缺少一些內容－那就是軟體開發商和專業的服務組織必需提供的。理想情況下，開發商必需提供面向服務的業務流程、工作流以及服務的協調工具和服務；另外，能夠以一種敏捷的、平台無關的方式充分反映業務服務的建模工具也是必須的；技術專家必須配備可以從模型中自動生成**，並在**變化時更新模型的工具，最後，開發商必須提供支援soa的軟體，幫助面向服務的架構設計師以一種可信並且可伸縮的方式建立位於服務和底層技術之間的抽象層次。幸運的是，這方面的產品即將上市。
另外，最重要的就是貫穿本文的自頂而下的soa實現方法了。今天關於web services的大部分思考都是自底而上的：「這是如何建立web services的方法，現在，我們來使用它們整合吧」，對web services技術的這種方法是偉大的第一步，因為它可以驚人地降低整合的開銷，這是現在的技術管理人員最樂意見到的了。但當經濟進一步發展，it走出低谷，企業會尋求it的幫助來提高組織戰略意義上的核心價值。使用面向服務的架構，it可以提供給企業實現業務敏捷性的這樣乙個框架。
關於快速開發，大家可以來談談自己的看法
大家都知道，現在和以前比起來，網際網路行業 軟體行業已經天差地別了。現在處處都在搞資訊化建設，人人都知道網際網路思維。這樣的資訊化時代，對於軟體開發者 對於軟體開發公司來說，是乙個巨大的機遇。在門外漢看來，軟體開發是機遇大 成本低，只要叫幾個程式設計師，就能搞出個軟體公司來。但是，事實情況是這個樣子...
關於快速開發，大家可以來談談自己的看法
大家都知道，現在和以前比起來，網際網路行業 軟體行業已經天差地別了。現在處處都在搞資訊化建設，人人都知道網際網路思維。這樣的資訊化時代，對於軟體開發者 對於軟體開發公司來說，是乙個巨大的機遇。在門外漢看來，軟體開發是機遇大 成本低，只要叫幾個程式設計師，就能搞出個軟體公司來。但是，事實情況是這個樣子...
大家曬曬自己的夢想吧！
最後一節口語課上，外教巴布老師要大家回答幾個問題，你爸爸做什麼工作的？你媽媽做什麼工作的？他們希望你將來成為什麼樣的人？你的夢想是什麼？各種各樣的回答都有，有夢想做boos的，有夢想做software engineer，有夢想做ceo的，也有夢想做家庭主婦的.我們家三代貧農，我爸媽都是地地道道的農民...