又讀完了一個系列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的具體實現又貼近了一步，更加豐富自己這方面的知識。繼續努力吧！