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