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