5 月 1 日 ~6 月 30 日 分為三個階段

一、 5 月 1 日 ~5 月 21 日。完成初期文檔

1-2? 需求分析階段

說明：用于了解 SOA 及項目的具體要求

3-5? 討論并形成系統構架的雛形

說明：這三天時比較關鍵的三天，主要是基于前 2 天對項目的理解，大家行進大量的討論。討論的主要目標應該是項目的主體框架，主要的功能，最終形成一個框架圖和功能列表（功能可能會不全，應盡力去想）。注意及時做筆記。

6-7??????? 形成系統構架的初稿

說明：因為這兩天是周末，時間比較集中，可以三個人在一起研究并把系統架構形成文檔的形式，并對各個組件進行分工。

8-9??????? 收集并研究各組件的資料

說明：這兩天的任務是收集所設計組建方面的資料。包括：組件所需技術，實現所需軟件列表，更主要的是組件的設計。關鍵是怎樣設計的，其他人可以提出意見。

10-11?????? 形成組件設計的文檔

說明：把前兩天的東西形成文檔的形式。

12-13??????? 把系統構架和組件設計兩個文檔放到一起加工、整合、修改，形成設計文檔。

14???? ? 解釋 SOA 思想和方法在本系統開發中的應用。

15-19??????? 分工進行業務模式分析和設計，服務模型分析和設計。

說明：這幾天的任務要重一些，而且要分頭進行，因為這個是可選的交付件，我想我們還是把它做了吧。主要是搜集資料，明確定義，并做筆記。

20??????? 形成前面的文檔

說明：這一天是周末，一天的時間寫一個文檔，應該不累吧。

21??????? 最終的審核，第一階段結束。

?

二、 5 月 22 日 ~5 月 31 日。第二階段 開發工具的學習

三、 6 月 1 日 ~6 月 27 日。第三階段 做出演示版，形成系統的雛形。（這兩個階段等到具體時間再細化）

判定樹是判定表的變種，也能清晰地表示復雜的條件組合與應做的動作之間的對應關系。判定書樹的優點在于，它的形式簡單到不需任何說明，一眼就可以看出其含義，因此易于掌握和使用。

結構化的最后一部份就是實現了，通常把編碼和測試成為實現。在測試中分黑盒測試和白盒測試。如果已經知道了產品應該具有的功能，可以通過測試來檢查是否每個功能都能正常使用；如果知道產品內部工作過程，可以通過測試來檢驗產品內部動作是否按照規格說明書的規定正常進行。前一個方法稱為黑盒測試，后一個方法稱為白盒測試。另外測試的時候還要遵守測試準則：

l???????? 所有的測試都應該能追溯到用戶需求。

l???????? 應該在測試開始之前的相當長時間，就制定出測試計劃。

l???????? 把Pareto原理應用和軟件測試。

l???????? 測試應該從“小規模”開始，并逐步進行“大規模”測試。

l???????? 窮舉測試是不可能的。

l???????? 為了達到最佳的測試效果，應該由獨立的第三方來從事測試工作。

在設計測試方案時，往往需要仔細分析程序的控制流。為了突出表示程序的控制流，可以使用流圖。流圖僅僅描繪程序的控制流程，它完全不表現對數據的具體操作揖及分支或循環的具體條件。在流圖中用圓表示節點，一個圓代表一條或多條語句。程序流程圖中的一個處理框序列和一個菱形判定框，可以映射成流圖中的一個節點。流圖中的箭頭線稱為邊，它和程序流程圖中的箭頭線類似，代表控制流。在流圖中一條邊必須終止于一個節點，即使這個節點并不代表任何語句。由邊和節點圍成的面積稱為區域，當計算區域數時應該包括圖外部未被圍起來的那個區域。

邏輯覆蓋式設計白盒測試方案的一種技術。設計測試方案時測試階段的關鍵技術問題。所謂測試方案包括具體的測試目的，應該輸入的測試數據和預期的輸出結果。通常又把測試數據和預期的輸出結果稱為測試用例。覆蓋標準大概有以下幾種：語句覆蓋、判定覆蓋、條件覆蓋、判定/條件覆蓋、條件組合覆蓋。語句覆蓋式含義是，選擇足夠多的測試數據，使被測試程序中每個語句至少執行一次。判定覆蓋又叫分支覆蓋，它的含義是，不僅每個語句必須至少執行一次，也就是每個判定的每個分支都至少執行一次。條件覆蓋的含義是，不僅每個語句至少執行一次，而且使判定表達式中每個條件都取到各種可能的結果。既然判定覆蓋不一定包含條件覆蓋，條件覆蓋也不一定包含判定覆蓋，自然會提出一種能同時滿足這兩種覆蓋標準的邏輯覆蓋，這就是判定/條件覆蓋。它的含義是，選取足夠多的測試詩句，使得判定表達式中的每個條件都取到各種可能的值，而且每個判定表達式也都取到各種可能的結果。條件組合覆蓋式更強的邏輯覆蓋標準，它要求選區足夠多的測試數據，使得每個判定表達式中條件的各種可能組合都至少出現一次。

基本路徑測試是一種白盒測試技術，它的步驟如下：

l???????? 根據過程設計結果畫出相應的流圖

l???????? 計算流圖的環形復雜度

l???????? 確定線性獨立路徑的基本集合

l???????? 設計可強制執行基本集合中每條路徑的測試用例

結構化部分介紹完了，下面開始介紹面相對象的設計。通常需要建立三種形式的模型，它們分別是描述系統數據結構的對象模型，描述系統控制結構的動態模型和描述系統功能的功能模型。對象模型表示靜態的、結構化的系統的“數據”性質。它是對模擬客觀世界實體的對象以及對象彼此間的關系的映射，描述了系統的靜態結構。面向對象方法強調圍繞對象而不是圍繞功能來構造系統。對象模型為建立動態模型和功能模型，提供了實質性的框架。

動態模型表示瞬時的、行為化的系統的“控制”性質，它規定了對象模型中的對象的合法變化序列。功能模型表示變化的系統的“功能”性質，它指明了系統應該“做什么”，因此更直接地反映了用戶對目標系統的需求。

最近正在猛看軟件工程，發現這門學科真的很有用，尤其是對于企業級別的軟件的開發作用巨大。下面我就寫一些關于軟件工程方面的東西，就當作總結一下所學的內容吧。

我想這個問題應該從軟件危機開始講起吧，軟件危機是指在計算機軟件的開發和維護過程中所遇到的一系列嚴重的問題。具體來說：

l???????? 對軟件開發成本和進度的估計常常很不準確。

l???????? 用戶對“已完成的”軟件系統不滿意的現象經常發生。

l???????? 軟件產品的質量往往靠不住。

l???????? 軟件常常是不可維護的。

l???????? 軟件通常沒有適當的文檔資料。

l???????? 軟件成本在計算機系統總成本中所占的比例逐年上升。

l???????? 軟件開發生產率提高的速度，既跟不上硬件的發展速度，也遠遠跟不上計算機應用迅速普及深入的趨勢。

　　而軟件工程這門學科的出現也是為了從宏觀的角度來觀察軟件，解決危機。軟件工程師把系統化的、規范的、可度量的途徑應用于軟件開發、運行和維護的過程，也就是把工程化應用于軟件中；研究中提到的途徑。

軟件工程的過程可以用軟件生命周期來表示，生命周期的具體內容為：問題定義、可行性研究、需求分析、概要設計、詳細設計、編碼和單元測試、綜合測試、軟件維護。生命周期模型又分為以下幾種：瀑布模型、快速原型模型、增量模型、螺旋模型、噴泉模型。

E-R 圖、數據流圖、狀態轉換圖是結構化分析中的重點圖。 E-R 圖中包含了實體、關系和屬性等三種基本成分。通常用矩形框代表實體，用連接相關實體的菱形框表示關系、用橢圓形或圓角矩形表示實體的屬性，并用無向邊把實體與其屬性連接起來。數據流圖有四種基本符號：正方形表示數據的源點或終點；圓角矩形代表變換數據的處理；開口矩形代表數據存儲；箭頭表示數據流，即特定數據的流動方向。在狀態圖中，初態用實心圖表示，終態有一對同心圓表示。中間狀態用圓角矩形表示，可以用兩條水平橫線把它分成上、中、下 3 個部分。上面部分為狀態的名稱，這部分是必須有的；中間部分為狀態變量的名字和值，這部分時可選的；下面部分是活動表，這部分也是可選。

數據字典是所有與系統相關的數據元素的有組織的列表，并且包含了對這些數據元素的精確、嚴格的定義，從而使得用戶和系統分析員雙方對輸入、輸出、存儲的成分甚至中間計算有結果有共同的理解。簡而言之，數據字典是描述數據的信息的集合，是對系統中使用的所有數據元素的定義的集合。大多數數據字典都包含以下信息：名字、別名、使用地點與方式、內容描述、補充信息。

說完了結構化分析，該說說結構化設計了。其中模塊是很重要的概念。模塊是由邊界元素限定的相鄰的程序元素的序列，而且有一個總體標識符來代表它。有五條標準來評價一種設計方法定義有效的模塊系統的能力：模塊可分解性、模塊可組裝性、模塊可理解性、模塊連續性、模塊保護性。有效的模塊化的軟件比較容易開發出來。這是由于能夠分割功能而且接口可以簡化，當許多人分工合作開發同一個軟件時，這個優點尤其重要。獨立的模塊比較容易測試和維護。這是因為相對說來。修改設計和程序需要的工作量比較小，錯誤傳播范圍小，需要擴充功能時能夠“插入”模塊。模塊的獨立程度可以由兩個定性標準來度量，這兩個標準分別成為內聚和耦合。耦合衡量不同模塊彼此間互相依賴的緊密程度；內聚衡量一個模塊內部各個元素彼此結合的緊密程度。最好能做到松耦合、高內聚。

表示軟件結構的圖形工具有層次圖、 HIPO 圖和結構圖，通常使用層次圖描繪軟件的層次結構。在層次圖中一個矩形框代表一個模塊，框間的連線表示調用關系。在自頂向下逐步求精設計軟件的過程中，使用層次圖很方便。 HIPO 圖是美國 IBM 公司發明的“層次圖加輸入 / 處理 / 輸出圖”的英文縮寫。為了使 HIPO 圖具有可追蹤性，在層次圖里除了頂層的方框之外，每個方框都加了編號。結構圖和層次圖類似，也是描述軟件結構的圖形工具，圖中一個方框代表一個模塊，框內注明模塊的名字或主要功能；方框之間的箭頭（或直線）表示模塊的調用關系。因為按照慣例總是圖中位于上方的方框代表的模塊調用下方的模塊，即使不用箭頭也不會產生二義性，為了簡單起見，可以只用直線而不用箭頭表示模塊間的調用關系。

之后應該是過程設計了。過程設計的工具有：程序流程圖、盒圖（ N_S 圖）、 PAD 圖、判定表、判定樹、過程設計語言（ PDL ）。程序流程圖又成為程序框圖，它是歷史最悠久的使用最廣泛的描述過程設計的方法，然而它也是用得最混亂的一種方法。盒圖有下述特點：

l???????? 功能域明確，可以從盒圖上一眼就看出來。

l???????? 不可能任意轉移控制。

l???????? 很容易確定局部和全程數據的作用域。

l???????? 很容易表現嵌套關系，也可以表示模塊層次結構。

PAD 圖是問題分析圖的英文縮寫，自 1973 年由日本日立公司發明以后，已得到一定程度的推廣。判定表能清晰地表示復雜的條件組合與應做的動作之間的對應關系。一張判定表由四部分組成，左上部列出所有條件，左下部是所有可能作的動作，右上部是表示各種條件組合的一個矩陣，右下部是和每種條件組合相對應的動作。判定表右半部的每一列實質上是一條規則，規定了與特定的條件組合相對應的動作。（未完待續）

從上圖中可以注意到一個 IT 難題，那就是大多數應用程序之間直接相互通信。當應用程序需要修改或淘汰時，這種依賴便成為一個實際問題。任何修改都可能會按其自身的方式更新每條唯一的通信線路。因此，這種變更可能代價高昂。這種情況被稱為應用程序間的緊耦合，也逐漸成為讓一些企業頭疼的問題。

另一方面，SOA 將松耦合作為成功的企業級應用程序集成的一個主要原則。與緊耦合相反，松耦合是：

限制請求者應用程序代碼和提供者應用程序代碼的相互了解。如果耦合的服務任何方面有所變化，那么，請求者或提供者的應用程序代碼（更可能是兩者同時）必須改變。如果任何一方（請求者、提供者或中介基礎架構）對解耦的服務任何方面作出改變，那么其它幾方不必隨之改變。

連續兩次的發郵件都被返，理由是IBM沒有soacontest這個郵箱！我們都快崩潰了。幸好我們是實習生，有IBM內部的通訊工具。在報名的網站找到了叫王婷婷的負責人的email，但是不幸的事又發生了，那個email也不好用。最后只能搜索人名了，找到了3個叫王婷婷的人。第一個，第二個都不是。終于第三個找到了她，但是她還是讓我往那個郵箱里發信，我解釋了一下。說我已經發了兩次了，都不好使。faint~,最后她只能用I will check來結束我們的對話，我也只能等待她的消息了。希望能夠早些把名報上吧。唉！

又讀完了一個系列7篇文章，感覺對SOA有個更深的理解，我總結之！繼續！
第一部分：
編程模型的定義為：
程序員構建的一套部件類型。部件類型包括多種編程模型構件：超文本標記語言（HTML）文件、數據庫存儲過程、Java 類、可擴展標記語言（XML）Schema 定義、定義 MQSeries 消息的 C 結構，等等。
一系列角色，將具備相似技能和知識的開發和管理人員分組。用這種方式對開發人員分類有助于生產適應于角色的工具，使非程序員可以實現服務并將服務組裝為解決方案。業務分析人員定義業務流程，銷售專家定義顧客分類的策略并計算產品折扣。每一種角色包含：
1.角色所具備的技能。例如，用戶界面開發人員開發界面，用來呈現應用程序或者解決方案的功能構件。假設這個角色了解正在開發的應用程序和它的業務目標，充分了解應用程序的用戶及他們的任務，精通一些用戶界面設計方法，能夠通過為每個任務選擇恰當的類型來創建易于使用的用戶接口。
2.角色交互（消費或者生產）所用的部件類型和應用程序接口。例如，動態頁面設計人員 -- 角色 -- 生產 JavaServer Page（JSP）并消費 EJB-- 部件類型 -- 包裝現有的信息資源和應用程序。
3.角色使用的工具。例如，Web 開發人員所用的適合于角色的工具是所見即所得的頁面設計工具，用來構建動態頁面，使用與 HTML 和 JSP 標簽庫相關的控件，并將控件連接到 EJB。
第二部分：
這部分提出了一個很重要的概念-----服務對象數據（Service Data Object，SDO），它使用統一的抽象代替了各種各樣的數據訪問模型來創建、檢索、更新和刪除供服務實現使用的業務數據。SDO 定義了一種單一的、統一的方法來訪問和操作來自異構數據源的數據，包括關系型數據庫、可擴展標記語言eXtensible Markup Language，XML）數據源、Web 服務以及企業信息系統 (EIS)。它們是基于數據圖（data graph）的概念。數據圖就是一組可以從數據源中分離出來的樹形結構的對象。SDO 可以在整個應用程序體系結構中使用。
這部分還給出了許多的示例:
示例 1. 使用 XML 的 SDO 類型定義

<? xml?version="1.0"?encoding="UTF-8" ?>
< schema? xmlns ="http://www.w3.org/2001/XMLSchema" ?
????????????????xmlns:tns ="http://www.myvalue.com"
????????targetNamespace ="http://www.myvalue.com" >
???? < element? name ="customer" ?type ="Customer" />
???? < complexType? name ="Customer" >
???????? < sequence >
???????????? < element? name ="customerID" ?type ="string" />
???????????? < element? name ="firstName" ?type ="string" />
???????????? < element? name ="lastName" ?type ="string" />
???????????? < element? name ="stockSymbol" ?type ="string" />
???????????? < element? name ="stockQuantity" ?type ="int" />
???????? </ sequence >
???? </ complexType >
</ schema >

示例 2. 使用 Java 的 SDO 類型定義

public ? interface ?Customer? {
????String?getCustomerID();
???? void ?setCustomerID(String?customerID);
????String?getFirstName();
???? void ?setFirstName(String?firstName);
????String?getLastName();
???? void ?setLastName(String?lastName);????
????????String?getStockSymbol();
???? void ?setStockSymbol(String?stockSymbol);
???? int ?getStockQuantity();
???? void ?setStockQuantity( int ?stockQuantity);
}

還有一些示例，可以查看http://www.shnenglu.com/zhangji198543/archive/2006/04/17/5702.html
第三部分：
這部分講了業務流程和業務狀態機。概要地列出了 BPEL 的一些特性以及 IBM 的 WebSphere Business Integration 中的 BPEL 實現所提供的擴展：
1.可以與多個合作伙伴交互的長時間運行的業務流程。
2.將人員整合到流程。
3.將流程嵌入到 Java? 2 Platform, Enterprise Edition (J2EE)。
4.服務質量。
5.與 WebSphere 集成。
下圖為表示訂購單的業務狀態機，很有啟發性：

第四部分：
這一部分對IBM 企業服務總線做了介紹，IBM ESB 模式提供以下幾方面的虛擬化：
1.位置和標識。
2.交互協議。
3.接口。
4.（交互）服務質量 (QoS)。
另外用戶角色也是很重要的，對我們以后的開發人員分配有幫助。業務分析人員確定業務需求，并檢查業務流程。他們將概括出解決方案的目標、涉及的業務流程、監視解決方案的運行狀況和狀態的關鍵指標，以及 IT 系統需要提供的業務服務的類型。
解決方案架構師確定哪些業務需求可以通過對現有 IT 資產進行重用、修改或組合得到滿足，哪些需要編寫或購買新的 IT 資產。他們定義 IT 資產間的交互，包括消息交換的內容。
開發工作在三個角色中分配。實現人員編寫新的應用程序代碼，這些代碼將通過服務接口調用。適配器開發人員構建包裝現有或新采購的應用程序和軟件包的服務，從而為其他服務提供可訪問性。集成開發人員使用 ESB 的相關工具和技術構建邏輯，以控制請求在這些服務間路由的方式。
最后講了ESB模式:
1.交互模式：允許服務交互點將消息發送到總線或從總線接收消息。
2.中介模式：允許對消息交換進行操作。
3.部署模式：支持將解決方案部署到聯合基礎設施中。
模型-視圖-控制器（Model-View-Controller，MVC）范例是現代大多數 UI 應用程序框架的基礎。SOA 操作提供模型層，而 UI 位于視圖層。UI 技術可以在各種設備上呈現信息，這些設備包括的范圍很廣，從窗口小部件和智能電話到瀏覽器和能夠進行大量客戶端處理的富客戶機。中間件和工具將視圖層 UI 技術連接到模型層 Web 服務和數據。
第五部分:

在 SOA 方法中，宿主組件的環境抽象成容器，它提供已知的服務集。從 UI 的角度來說，承載客戶端 UI 組件的三個主要的容器是：

基本 Web 瀏覽器。
使用 Java?Script 和動態 HTML 增強的 Web 瀏覽器。
IBM Workplace? Client Technology?——具有本地 IBM WebSphere? Application Server 客戶機支持的 Eclipse 富客戶機。
這些容器可以通過支持下列技術得以增強：Servlet、JavaServer Page (JSP) 和 JSP Tag；用于頁面排序的 Struts；用于高級頁面組合的 JavaServer Face (JSF)；以及合并在同一頁面上的多應用程序視圖的 Portlet 技術。

UI 開發框架可以簡化創建面對用戶的復雜應用程序的過程。通常使用下列的 UI 框架來創建 UI 組件：
1.Struts，
2.JavaServer Faces
3.Java Widget Library (JWL)

第六部分：
組件是這篇文章的重點。組件這個概念在其他方面的程序設計中也是經常用的到。而對 SOA來說良好定義的組件應該支持生態系統中的各種用戶角色——例如業務分析人員、集成開發人員、適配器開發人員和解決方案管理員——通過實例化、使用、組裝和自定義符合用戶目標、技能和概念性框架的不同組件類型，來創建面向服務的應用程序。
SOA 是一種分布式組件體系結構。SOA 組件封裝功能，并支持通過業務分析人員和業務模型建模的抽象級別的重用。聲明性的、計算機可處理的約定允許第三方訪問 SOA 組件提供的服務。可以動態地發現、選擇、綁定（通過其聲明性屬性）和集成SOA 組件。

我們的 SOA 是由以下規范定義的：

一、服務規范 以組件提供和使用的一組服務的形式提供了組件的視圖。它由以下三組規范定義：
1.接口，通常是 WSDL portTypes。
2.策略，記錄 QoS 屬性，例如事務行為和安全性。
3.行為描述，例如 BPEL4WS 抽象流程。另一個例子可能是統一建模語言 V2 (UML2) 狀態模型，該模型指定了哪些操作對不同的狀態和操作所引發的狀態事務是有效的。調用方可以通過狀態模型計算有效的操作序列。
二、服務組件實現 是由以下四組規范定義的：
1.提供的服務規范。
2.需要的服務規范。
3.可以在組件上設置以調整或自定義的屬性。
4.為此提供基本支持的屬性；更復雜的方案使用可變點和對自定義組件的外部調用。
5.對所有實現實例都保持不變的容器指示（策略）。
6.定義組件實現的實現構件（例如 Java 類、BPEL 文檔或 XSLT 規則集）。
三、服務組件（實例）由以下規范定義：
1.名稱。
2.服務組件實現。
3.實現的任何屬性的值，設置用于調整實例。
4.任何服務的規范，解析實現需要的服務規范。它們可以是連接組件實例的“網絡”，也可以是在運行時執行以查找組件的“查詢”，所查找的組件實現相關接口，具有相關的 QoS 策略，并且匹配指定的行為（例如抽象流程或狀態模型）。

有兩種定義 SOA 組件的基本方法。這些定義可以通過開發工具生成，也可以由開發人員手動創建。

第一種方法是控制文件，顧名思義，控制文件即關聯或聯接組件的所有部分的文檔。例如，控制文件可以引用 WSDL 定義（提供的接口）、實現組件的 Java 類（實現構件）或相關的策略文檔（策略斷言）。 它們可以是對文件系統、類路徑、源代碼管理系統或 Web URL 的引用。控制文件方法將多個單獨開發的構件聚合在一起組成組件。應用程序開發工具可以幫助定義控制文件。

第二種方法是使用 pragmas，指定相同信息的語言元素，但是包含在單個源文件的主體中。Java 方面的支持正在不斷增加（例如，JSR 175 中的 XDoclet 標記），以用 Java 語言編寫這些批注部分。但是這種方法尚不支持其他等同的有效 SOA 組件實現技術（如 SQL 或 XQuery 語句集）。每種組件類型都有用于其實現構件的相關源文件格式，例如 Java 文件、狀態機或 SQL 文件。IBM WebSphere? Rapid Deployment 中的批注支持可以生成所有組成包含 pragmas 的源文件中的組件的單個元素。例如，Java 源文件中的結構化注釋指示哪些 Java 方法將成為所生成的定義組件的服務接口中的 Web 服務操作。

第七部分：
次篇文章在安全性的角度討論了SOA，尤其是如何去保護SOA應用程序。
總之，通過閱讀這一系列文章，感覺到離SOA的具體實現又貼近了一步，更加豐富自己這方面的知識。繼續努力吧！

1. 范圍 <此架構適用于企業的哪個領域>
2. 操作系統層
   1. 打包的應用程序
   2. 自定義應用程序
   3. 架構決策
3. 企業組件層
   1. 企業組件支持的功能范圍
   2. <這個企業組件支持業務領域、目標和過程>
   3. 關于控制的決策
      1. <作為這個客戶端組織內部企業組件來選擇某物的標準>
   4. 架構決策
4. 服務層
   1. 服務分類表
   2. 架構決策
5. 業務過程和合成層
   1. 業務過程可以表現為舞蹈編排（choreographies）
   2. 架構決策
      1. <哪一個過程需要編排在舞蹈編排里面以及哪一個鑲嵌在應用程序里面？>
6. 訪問或者表現層
   1. <證明這層中 Web 服務和 SOA 的含意；即便要。例如，在用戶接口級別上調用 Web 服務的 portlet 的使用，以及在此層機能上的含意。>
7. 集成層
   1. <包含 ESB 因素>
   1. <我們如何確保使用服務的客戶端系統級的一致性（SLA）和服務質量（QoS）？>
   2. 安全問題和決策
   3. 性能問題和決策
   4. 技術和標準的局限性以及決策
   5. 服務的監控和管理
      1. 描述和決策

層 1：操作系統層。本層包含現有的自定義構建的應用程序，也叫做 遺留系統，包含現有的 CRM 和 ERP 打包應用程序，以及 較舊的基于對象的系統實現，還有業務智能應用程序。SOA 的復合層架構可以利用現有的系統并且用基于服務的集成技術來集成它們。

層 2：企業組件層。本層由那些負責實現功能和保持公開服務 QoS 的企業組件組成。這些特殊的組件是企業和業務單元級支持的企業資產的受管理和控制的集合。 同企業范圍資產一樣，他們通過架構最佳實踐應用程序來負責確保 SLAs 的一致。大多數情況下，本層使用基于容器的技術，比如實現組件、負載均衡、高可用性和工作量管理的應用服務器。

層 3：服務層。業務選擇來支持和公開的服務處在這一層。它們可以被 發現或者直接靜態綁定，接下來被調用，或者可能的話，編排到合成服務中。這個服務公開層同樣提供了獲取企業范圍組件，業務單元特定組件，以及有些情況下，特定項目組建的機制，并且以服務描述的形式具體化了他們的接口子集。因此，企業組件使用它們接口提供的功能在運行時提供服務實現。在這一層的接口公開為一個服務描述，在這層中他們被公開以提供使用。他們可以獨立存在或者作為合成服務。

層 4：業務過程合成或編排層。第三層中公開的服務的合成和編排在這一層中被定義。通過配合、編排，服務被綁定成一個流程，并且從而作為單獨的應用程序而共同作用。這些應用程序支持特殊的用例和業務過程。這里，可視的流程合成工具，比如 IBM? WebSphere? Business Integration Modeler 或者 Websphere Application Developer Integration Edition，都可以用來設計應用程序流程。

層 5：訪問或表現層。盡管這一層經常超出了圍繞 SOA 討論的范圍，但是它卻變得越來越有意義。在這里我描述它因為標準越來越集中，比如用于 Remote Portlets Version 2.0 的 Web 服務和其他技術，這些技術追求在應用程序接口或者表現層來利用 Web 服務。你可以把它作為將來的層用來滿足將來的解決方案的需求。注意到以下這兩點是非常重要的：SOA 將用戶接口從組件中分離出來；最終你需要提供從訪問路線到服務或者合成服務的端到端解決方案。

層 6：集成（ESB）。這一層使服務可以集成，通過引入一系列可靠的性能的集合，比如智能路由，協議中介和其他轉化機制，經常被描述為 ESB（參閱 參考資料）。Web Services Description Language（WSDL）制定了綁定，其包含提供服務的地址。另一方面，ESB 為集成提供了位置獨立機制。

層 7：QoS。這一層提供了監視，管理和維持諸如安全，性能和可用性等 QoS 的能力。這是一個通過 sense-and-respond 機制和監測 SOA 應用程序健康的工具來進行的后臺處理過程，包括 WS-Management 和其他相關協議的所有的重要的標準實現以及為 SOA 實現服務質量的標準。

好不容易到了個周六，疲憊的身軀可以暫歇了。不過下周六還有《軟件工程》考試，抓緊學習了。
從學習SOA開始到現在，已經有6天了。文章也看了不少了，可是我們還是不知如何下手。那些文章都是理論上了，至少暫時并沒發現有多少代碼。面對這次比賽的醫療機械行業的實例來說還是有些棘手，哎，慢慢來吧，堅持就是勝利。