通過 29-31 為期 3 天的 IBM WPS 培訓。使我對 IBM WID 有了感觀上的認識，并對炒的火熱的一些概念（ SOA 、 SCA 、 SDO ）更進一步的認識。現就我理解對 WID 的培訓進行總結，若哪里有問題，請各位指正。
SCA
剛上課， IBM 講師就開始大談 SCA ，現在就我理解談下對 SCA 的認識。 Service Component Architecture 是 SCA 的縮寫，可譯為“組件（構件）服務體系架構”。 SCA 是基于組件開發，目的是為了可復用、可組裝，將幾個組件組裝到一起就形成一個新的應用。其實在 SCA 的概念出現前，我們就已經使用基于組件方式開發了。所以 SCA 概念也可謂是新瓶裝老酒。現在 SCA 已經逐漸規范，相關組織已經對其制定規范、標準。其中國內普元軟件也參與制定，在國內 SCA 廠商算是首屈一指。
而在 WID 中， IBM 對 SCA 編程模型的概念包括：服務組件、服務模塊、導入導出、共享庫、 Standalone Reference 。現對其概念進行闡述。
服務組件是 SCA 中的基本組成元素和基本構建單位，也是我們具體實現業務邏輯的地方。我們可以把它看成是構建我們應用的積木。我們可以非常容易地把傳統的 POJO ，無狀態會話 BEAN 等包裝成 SCA 中的服務組件。 SCA 服務組件的主要接口規范是基于 WSDL （ Web Service Description Language ）的，另外為了給 Java 編程人員提供一個比較直接的接口， SCA 的部分服務組件也提供了 Java 接口。因此，使用服務組件的客戶端可以選擇使用 WSDL 接口或 Java 接口。
服務模塊（簡稱模塊）由一個或多個具有內在業務聯系的服務組件構成。把多少服務組件放在一個模塊中，或者把哪些服務組件放在一起主要取決于業務需求和部署上靈活性的要求。
導入、導出是導入（ Import ），它的作用是使得模塊中的服務組件可以調用模塊外部的服務。另一個是導出（ Export ），它的作用是使得模塊外部的應用可以調用模塊中的服務組件。
當我們在構建了多個模塊的時候，如果有一些資源可以在不同模塊之間共享，那么我們可以選擇創建一份可以在不同模塊之間進行共享的資源，而不是在不同模塊中重復創建。共享庫就是存放這些共享資源的地方。
模塊中的服務組件是不能直接被外部 Java 代碼使用的，為了外部的 Java 代碼，比如 JSP/Servlet 使用模塊中的服務組件， WID 工具在模塊中提供了一個特殊的端點，叫做 Standalone Reference 。這個端點只有引用（ Reference ），而沒有接口（ Interface ）。只要把這個端點的引用連接到需要調用的服務組件的接口，外部的 Java 代碼通過這個引用的名稱來調用相應的服務組件了。
在講師講完 SCA 概念及 WID 概述的時候，我曾私下問過，“ BEA WORKSPACE 360 與 WID 有什么區別？”。老師的回答是， WID 以 SCA 模型開發，而 WORKSPACE 360 的開發模型為 SOA ，因為 SCA 已經規范化，標準化，所以更規范一些，適合企業集成。而 SOA 的概念還是顯得相對抽象的，沒有正確的標準。
圖一 SCA 編程模型
SDO
SDO 全稱 Service Data Objects ， SDO 應有服務引擎做支持，服務引擎主要的工作：整合多個 DB 、 LDAP 作為同一個數據源。通過數據源可以訪問多個 DB 、 LDAP ，訪問多個 DB 、 LDAP 對開發人員是透明的，開發人員只訪問一個數據源，就相當于訪問一個 DB ，而引擎內部使用 XML 存儲，引擎應支持事務及安全管理。
SDO 是 IBM 提出的一個框架規范。 SDO 框架由三部分組成： DMS （ Data Mediator Services ）， Data Graph 和 DataObject 。 DMS 負責生成 Data Graph ， Data Graph 包含一系列關聯的 Data Object 。客戶和 DataGraph 打交道，而 DMS 如何生成 Data Graph 又如何從 Data Graph 更新后面的數據則無需關心。 Data Graph 是 Disconnected Mode 的數據處理方式，即對其進行的修改操作，將不會立刻體現，需要將修改過的 Data Graph 由 DMS 來更新到數據源。 Data Graph 是通過 log change summary 來實現的。
在 Spec 中說道， Data Graph 被序列化為 XML 也能從 XML 中被反序列化。這使得在 Services 和其 Caller 之間傳遞 DataGraph 非常直接。同時也提出了系統內部、系統之間數據交互的一致方式 —— 通過 XML 序列化過的 Data Graph 。
Data Object 可以被動態實現（程序里將看不見具體的 Data Object 類，比如 Employee 類，因此也無需定義 XML Schema ），也可以被靜態生成（例如預先建模后使用工具生成，目前 IBM 基于 EMF 的 RI 可以使用 EMF 來生成）。
DMS 可以有許多實現方式，在 IBM 的 SDO Specification 中并沒有任何關于 DMS 實現方式的規范。實際上， DMS 在 SDO Spec V2.0 里面已經改稱 DAS （ Data Access Services ），我們發現這命名和 DAO （ Data Access Object ）模式何其相似。不過這里是 Service 。那么可以想象在 SOA 中，我們可以提供這樣的 DAS 來提供數據并作數據更新。難道與 DAO 類似這將會成為一種 SOA 模式？
更重要的是， DAS 可以在 J2EE 的各層都能被使用。你可以使用 JDBC 實現 DAS 用它做一個持久化服務層，你可以用 EJB 實現 DAS 并且暴露成 Web Service…… 你甚至可以使用 Hibernate 、 JDO 這樣的持久化工具來實現 DAS 。
所以我們不可能混淆 SDO 框架和 Hibernate 、 JDO 等工具 —— 因為后者只是持久化工具存在于 EIS 之上；也無需懷疑 SDO 的價值 ——SDO 確實可以為整個 J2EE 應用尤其是 SOA 提供一個一致的數據處理方式。
BPEL
BPEL 全程為 Business Process Execution Language 提供了一種 XML 注釋和語義，內部描述為 XML 。是一種處理流程的語言，會通過流程來編排 Web 服務。向合作伙伴暴露 web 服務接口。也就是因為這個，實現向 ESB 上發布服務接口。現在想想 BEA 的流程引擎應該也是基于 BPEL 開發的。
Human Task
Human Task （人工任務）組件類型實現在業務流程和任意服務編排中涉及到相關人員的 Human Task 。人工任務在 Human Task Manager 內運行，后者是 WebSphere Process Server 內的人工任務的一個特殊容器。
Business Rule
商業規則引擎，其實就是說有些業務相當復雜， if else 的業務判斷很多。 IBM 的 Business Rule 可以做到業務人員使用業務語言配置開發人員要寫的 if else 才能實現業務判斷工作。這使我們的應用程序的核心行為和用戶界面對象能保持完整和不改變的，即使業務邏輯的更改。
State Machine
State Machine （狀態機）是一些服務組件，它們對象或交互在其使用期間響應事件時的狀態順序、響應順序以及所采取操作的順序。
狀態機提供了其他對業務流程進行建模的方法。這使您能夠選擇基于狀態和事件而非連續的業務流程模型來描述業務流程。利用狀態機機制，可以方便的將改變流程的流向。
至于什么時候用 BPEL ？什么時候用 State Machine ？ IBM 講師給出解釋，若流程為順序的（包括流轉），沒有跳躍性質的，連續性的。應該選用 BPEL ，否則應選用 State Machine 。
CEI (Common Event Infrastructure) 本質上是一種用來封裝應用程序中產生事件的通用機制。 State Machine 采用 CEI 機制。 CEI 是 WebSphere Process Server 的重要組成部分 , 并通過它為每一個 SCA 服務組件生成一組特定的事件。
ESB
Enterprise Service Bus 企業總線， ESB 是 SOA 體系架構中的信息流動與交換的基礎。 ESB 的參與主體是服務，總線提供了服務間消息的識別，轉換與路由的載體， ESB 是一種概念。 ESB 的主要作用： 1 、通過 ESB 統一服務接口。很多廠商需要共享服務接口，這時各廠商相互提供的接口就顯得零落，考慮可以命名用 ESB 管理，所有服務接口需注冊到 ESB ，各廠商調用服務接口時，需向 ESB 調用，由 ESB 轉發。有點路由的意思。 2 、通過 ESB 進行協議的轉換， ESB 應支持 EJB 、 RMI 、 COBRA 、 WEB SERVICE 等，應支持 HTTP 、 TELNET 、 FTP 、 SOCKET 協議。其中多種協議及接口可以相互轉換，例如： A 廠商將 COBRA 接口注冊到 ESB ，而 B 廠商可以通過 WEB SERVICE 方式訪問。其中的轉換工作由 ESB 完成。
以下是我在網絡上找到的幾句話、供參考。
SCA/SDO/BPEL 之所以會成為未來十年軟件開發的主流，就是因為他們正徹底地解決新的十年中客戶的關鍵問題，程朝輝表示。
可以說， SCA 與 SDO/BPEL 一道，將成為簡化 SOA ( 面向服務架構 ) 的應用程序開發新模式，讓 SOA 更容易落地的新技術與事實標準。
IBM WebSphere Integration Developer 與 Bea WorkSpace 360 的異同。
相同點：
1 ．都是實現 SOA 體系架構。
2 ．基本概念相同， SDO ， ESB ， PORTAL 。
不同點：
1． WID SCA 模型實現 SOA 體系架構。更規范、更利于企業集成。而 WorkSpace 在 SCA 標準方面相對差些。
2． WID 在流程中提供業務規則引擎。而 BEA 中的 ALBPM 沒有。
3． 如果看 WID 的圖就可以看出， WID 本身自己就是 SCA 的例子，更方便擴展。而且 WID 由 eclipse 開發，使合作伙伴開發擴展工具成為可能。
4． 相對來講 BEA 的 ALBPM 開發流程相對簡單，而 WID 相對復雜。
5． 據 IBM 講師介紹， WID 提供的 Process API 可以做到事務控制，在組織結構集成方面，可以實現 IBM 提供的接口，可以做到組織結構的同步。相對 BEA 來說要簡單， BEA ALBPM 的 FDI ， PAPI 的事務問題未能解決。
6． WID 的 SCA ，相對來講做業務（非流程）開發時相對簡單，用鼠標拖來拖去，就可實現 component 的開發。接口的實現也可以有多種方式，比如 POJO ， EJB ， WEB SERVICE 。事務由 WID 控制。 WORKSPACE 沒有使用過，對這方面不了解。
7.WID基于BPEL，而albpm基于bpm