在 IBM Bluemix 云平臺上開發(fā)并部署您的下一個應(yīng)用。
引言
在《面向服務(wù)體系架構(gòu)（SOA）和業(yè)務(wù)組件（BC）的思考》（以下簡稱《 SOA 和 BC 》）一文中介紹了基于面向服務(wù)體系架構(gòu)（SOA）的組件模型，本文按照“分離”的原則，通過比較當前多種流行的客戶端和服務(wù)器端的通訊機制，進一步把業(yè)務(wù)組件進行分離，采用面向資源體系架構(gòu)（ROA）把業(yè)務(wù)組件界面層和業(yè)務(wù)邏輯層分離開，構(gòu)建一個多終端多技術(shù)平臺可復(fù)用的組件模型。
多層架構(gòu)中的通訊方式
軟件體系架構(gòu)是沿著單機到 CS 架構(gòu)，再到 BS 的三層架構(gòu)甚至多層架構(gòu)逐步發(fā)展過來的，關(guān)于多層架構(gòu)，本文不再詳細介紹，可以參考相關(guān)的資料，下面首先來分析一下當前比較流行的客戶端技術(shù)以及客戶端和服務(wù)器之間的通訊方式。
基于 MVC 的 J2EE 多層模型
在一個標準的基于 MVC 的 J2EE 的模型架構(gòu)的代碼中，從對象的類別來看，一般包含 BO、DAO、POJO 等 Java 類，另外還包含 JSP、Servlet 等，如下圖所示：
圖 1. 基于 MVC 的 J2EE 多層模型
POJO：簡單 Java 對象（Plain Ordinary Java Object，POJO），一個中間對象，在不同階段可以轉(zhuǎn)化為 PO、DTO、VO，POJO 持久化以后就是 PO，在應(yīng)用中的不同層次傳遞為 DTO，直接用來對應(yīng)表示層就是 VO。
PO：持久對象（Persistant Object，PO），也稱為 Data 對象，對應(yīng)數(shù)據(jù)庫中的 Entity，可以簡單認為一個 PO 對應(yīng)數(shù)據(jù)庫中的一條記錄。PO 中不包含任何對數(shù)據(jù)庫的操作。
VO ：表現(xiàn)層對象（View Object，VO）主要對應(yīng)界面顯示的數(shù)據(jù)對象。對于一個 WEB 頁面，或者 SWT、SWING 界面，用一個 VO 對象對應(yīng)整個界面的值。根據(jù)業(yè)務(wù)的需要可以和表對應(yīng)，也可以不對應(yīng)。
DTO ：數(shù)據(jù)傳輸對象（Data Transfer Object，DTO） 主要用于遠程調(diào)用等需要大量傳輸對象的地方。對象不應(yīng)該包含業(yè)務(wù)邏輯，其僅僅需要傳遞需要的屬性，而不是 PO 的所有屬性。
BO：業(yè)務(wù)對象 （Business Object，BO）主要作用是把業(yè)務(wù)邏輯封裝為一個對象。這個對象可以包括一個或多個其它的對象。通常一個 BO 包含多個 PO，通常需要將 BO 轉(zhuǎn)化成 PO，才能進行數(shù)據(jù)的持久化，反之，從 DB 中得到的 PO，需要轉(zhuǎn)化成 BO 才能在業(yè)務(wù)層使用。BO 建議只包含業(yè)務(wù)方法，屬性在 POJO 中。
DAO：數(shù)據(jù)訪問對象（Data Access Object，DAO）主要用來封裝對數(shù)據(jù)庫的訪問。通過它可以把 POJO 持久化為 PO，用 PO 組裝出來 VO、DTO。主要用來封裝對 DB 的訪問，把 POJO 持久化為 PO。
JSP 是通過 HTTP 請求，直接調(diào)用 Servlet 的。當前，在 J2EE 架構(gòu)下，有 Struts 、Spring 、Hibernate 等開源架構(gòu)完美的實現(xiàn)了界面、邏輯和實例化的操作。
Applet 和 J2EE 的通訊
Applet 可以直接連接數(shù)據(jù)庫，可以使用象 JDBC、RMI 這樣的協(xié)議來訪問象數(shù)據(jù)庫、LDAP 目錄和 Enterprise JavaBeans 組件這樣的后端信息。也可以通過 HTTP 連接后臺的 Java Servlet，和 JSP 連接方式相同，通過 Servlet 處理后臺邏輯，Applet 僅僅用來處理前端的工作。
Flex 和 J2EE 的通訊
Flex 是 Macromedia 發(fā)布的展現(xiàn)服務(wù) (Presentation Server)，根據(jù) mxml 文件 ( 純粹的 XML 描述文件和 ActionScript) 產(chǎn)生相應(yīng)得 swf 文件，傳送到客戶端，由客戶端的解釋執(zhí)行。 Flex 提供了三種方式和 Java 進行數(shù)據(jù)交互：HTTPService，RemoteObject 和 Web 服務(wù)。其中，HTTPService 方式可以傳輸 Text、XML 或者 JSON (JavaScript Object Notation) 等。由于 Flex 具有 Flash 打下的良好用戶基礎(chǔ)，同時具有豐富的展現(xiàn)效果，正在成為一種流行的客戶端展示實現(xiàn)技術(shù)。
AJAX 和 J2EE 的通訊
AJAX(Asynchronous JavaScript and XML) 是多種技術(shù)的綜合，它使用 XHTML 和 CSS 標準化呈現(xiàn)，使用 DOM 實現(xiàn)動態(tài)顯示和交互，使用 XML 和 XSTL 進行數(shù)據(jù)交換與處理，使用 Javascript 綁定和處理所有數(shù)據(jù)，Javascript 是一種粘合劑使 AJAX 應(yīng)用的各部分集成在一起，中 JavaScript 主要被用來傳遞用戶界面上的數(shù)據(jù)到服務(wù)端并返回結(jié)果。AJAX 使用 XMLHttpRequest 對象進行異步數(shù)據(jù)讀取， XMLHttpRequest 對象用來響應(yīng)通過 HTTP 傳遞的數(shù)據(jù)，一旦數(shù)據(jù)返回到客戶端就可以立刻使用 DOM 將數(shù)據(jù)放到網(wǎng)面上。在 Ajax 中，XMLHttpRequest 是核心，XMLHttpRequest 對象在大部分瀏覽器上已經(jīng)實現(xiàn)而且擁有一個簡單的接口允許數(shù)據(jù)從客戶端傳遞到服務(wù)端，但并不會打斷用戶當前的操作。使用 XMLHttpRequest 傳送的數(shù)據(jù)可以是任何格式，包括可以傳輸 Text、XML 或者 JSON。
其他客戶端和 J2EE 的通訊
除了前文所描述常見的瀏覽器支持的技術(shù)標準，當前富客戶端（Rich Internet Applications ，RIA）發(fā)展也很快，比較流行的有 AIR、WPF 、JavaFX 等。
AIR (Adobe Integrated Runtime) 是 Macromedia 發(fā)布一個跨操作系統(tǒng)運行的 RIA 技術(shù)解決方案，利用現(xiàn)有的 Web 開發(fā)技術(shù)（Flash，F(xiàn)lex，HTML，JavaScript，Ajax）來構(gòu)建富客戶端，并部署為桌面應(yīng)用程序，其本質(zhì)上采用的是前述 Web 開發(fā)技術(shù)和后臺通訊。由于 AIR 可以訪問客戶端的資源，并可以實現(xiàn)離線操作，所有具有廣闊的應(yīng)用前景。
WPF (Windows Presentation Foundation) 是 Microsoft 的 .Net 平臺的 RIA 技術(shù)解決方案，WPF 通過擴展應(yīng)用程序標記語言（eXtensible Application Markup Language ，XAML）把界面和業(yè)務(wù)邏輯分開，以開發(fā)出界面炫麗，功能強大的應(yīng)用程序。WPF 可以通過基于 SOAP 的 Web 服務(wù)或者 RESTful Web 服務(wù)跟后臺 J2EE 服務(wù)器交互。另外輕量級的基于瀏覽器的 Silverlight 可以采用這種技術(shù)。
JavaFX 是 Java 的 RIA 技術(shù)解決方案，和早期的 Applet、 Java Web Start 等技術(shù)一脈相承， 其使用的是領(lǐng)域?qū)Ｓ谜Z言（Domain Specific Language，DSL），和后臺通訊方式同 Applet。
通訊方式總結(jié)
如前文所述，客戶端和服務(wù)器端的通信有很多種，但是有兩種是都支持的，基于 SOAP 的 Web 服務(wù)和 RESTful Web 服務(wù)。
Web 服務(wù)是通過簡單對象訪問協(xié)議（Simple Object Access Protocol，SOAP）傳輸?shù)?，SOAP 是一種基于 XML 的協(xié)議， 可以和現(xiàn)存的許多因特網(wǎng)協(xié)議和格式結(jié)合使用，包括超文本傳輸協(xié)議（ HTTP），簡單郵件傳輸協(xié)議（SMTP），多用途網(wǎng)際郵件擴充協(xié)議（MIME），基于“通用”傳輸協(xié)議是 SOAP 的一個優(yōu)點。它還支持從消息系統(tǒng)到遠程過程調(diào)用（Remote Procedure Call， RPC）等大量的應(yīng)用程序。SOAP 提供了一系列的標準，如 WSRM（WS-Reliable Messaging）形式化契約確?？煽啃耘c安全性，確保異步處理與調(diào)用；WS-Security、WS-Transactions 和 WS-Coordination 等標準提供了上下文信息與對話狀態(tài)管理。
相對而言，SOAP 協(xié)議屬于復(fù)雜的、重量級的協(xié)議，當前隨著 Web2.0 的興起，表述性狀態(tài)轉(zhuǎn)移（Representational State Transfer，REST）逐步成為一個流行的架構(gòu)風(fēng)格。REST 是一種輕量級的 Web Service 架構(gòu)風(fēng)格，其實現(xiàn)和操作比 SOAP 和 XML-RPC 更為簡潔，可以完全通過 HTTP 協(xié)議實現(xiàn)，還可以利用緩存 Cache 來提高響應(yīng)速度，性能、效率和易用性上都優(yōu)于 SOAP 協(xié)議。REST 架構(gòu)對資源的操作包括獲取、創(chuàng)建、修改和刪除資源的操作正好對應(yīng) HTTP 協(xié)議提供的 GET、POST、PUT 和 DELETE 方法，這種針對網(wǎng)絡(luò)應(yīng)用的設(shè)計和開發(fā)方式，可以降低開發(fā)的復(fù)雜性，提高系統(tǒng)的可伸縮性。REST 架構(gòu)尤其適用于完全無狀態(tài)的 CRUD（Create、 Read、 Update、 Delete，創(chuàng)建、讀取、更新、刪除）操作。
基于 REST 的軟件體系結(jié)構(gòu)風(fēng)格（Software Architecture Style）稱之為面向資源體系架構(gòu)（Resource-oriented Architecture，ROA）。按照 REST 原則設(shè)計的軟件、體系結(jié)構(gòu)，通常被稱為“REST 式的”（RESTful），在本文中以下稱之為 RESTful Web 服務(wù)，以便于和基于 SOAP 的 Web 服務(wù)區(qū)別。
服務(wù)器端采用 J2EE，客戶端采用 JSP、Flex、JavaFX、AIR 等可以直接調(diào)用 Servlet，其他的實現(xiàn)技術(shù)基本上不能直接調(diào)用，但是無論是那種客戶端，對于基于 SOAP 的 Web 服務(wù)或者基于 RESTful Web 服務(wù)務(wù)都是支持的，如 AJAX 的 XMLHttpRequest、Flex 的 HTTPService 等。如下圖所示：
圖 2. 客戶端和服務(wù)器端的通訊方式
基于 SOAP 和 REST 的分層模型
結(jié)合前文所述客戶端和服務(wù)器端的通訊方式比較和分析以及在《 SOA 和 BC 》一文中描述的業(yè)務(wù)組件模型，下文給出了在界面層和業(yè)務(wù)邏輯層采用輕量級的 RESTful Web 服務(wù)，不同業(yè)務(wù)組件之間采用基于 SOAP 的 Web 服務(wù)的業(yè)務(wù)組件模型。
基于 ROA 的業(yè)務(wù)組件界面層和業(yè)務(wù)邏輯層接口
在多層架構(gòu)下，特別是當前客戶端技術(shù)發(fā)展迅速，有不同的技術(shù)實現(xiàn)方式，將界面層和業(yè)務(wù)邏輯層分離將能更好的實現(xiàn)業(yè)務(wù)組件的重用，業(yè)務(wù)邏輯不受不同客戶端技術(shù)技術(shù)影響，從而更好的保證了業(yè)務(wù)邏輯的重用。為了支持各種客戶端技術(shù)，需要采用各種客戶端技術(shù)都能支持的標準的接口方式，在前文所述兩種通用標準中，SOAP 相對來講屬于重量級協(xié)議，而且基于 SOAP 的 Web 服務(wù)將會增加軟件開發(fā)的難度，影響系統(tǒng)的性能，因此采用輕量級的 RESTful Web 服務(wù)務(wù)，來實現(xiàn)界面層和業(yè)務(wù)邏輯層的分離，如下圖所示：
圖 3. 界面層和業(yè)務(wù)邏輯層的通信模式
為了保持和基于 SOAP 的 Web 服務(wù)方式傳輸?shù)膬?nèi)容一致，其傳輸?shù)臄?shù)據(jù)格式均采用標準的 XML，比如傳遞一個客戶信息，基于 SOAP 的 Web 服務(wù)傳遞的參數(shù)和 RESTful Web 服務(wù)格式分別如下：
清單 1. XML樣例
<?xml version="1.0" encoding="gb2312"?> <CUSTOMER> <ORG_CODE> 1000 </ORG_CODE> <CUST_CODE> 100010001</CUST_CODE> <CUST_NAME>張三</CUST_NAME> <CUST_TYPE_CODE>11 </CUST_TYPE_CODE> <CUST_STATUS>01 </CUST_STATUS></CUSTOMER>
這樣不管是通過基于 SOAP 的 Web 服務(wù)和和基于 REST 的 XML，在業(yè)務(wù)邏輯層，可以通用一個 toString 方法，轉(zhuǎn)換成一個 XML 文件就可以了。最終是采用 SOAP 的 Web 服務(wù)還是 RESTful Web 服務(wù)，只是通過配置輸出不同的協(xié)議就可以了。Axis2 可以很好的支持這個架構(gòu)，Axis2 是一套嶄新的 WebService 引擎，該版本是對 Axis1.x 重新設(shè)計的產(chǎn)物。Axis2 不僅支持 SOAP1.1 和 SOAP1.2，還集成了 RESTful Web 服務(wù)，同時還支持 Spring、JSON 等技術(shù)。
清單 2. 生成XML代碼示例
public String toString (){ String strXML=””; ······; if (null != orgCode) { sb.append("<ORG_CODE>"); sb.append(orgCode); sb.append("</ORG_CODE>"); }if (null != custCode) { sb.append("<CUST_CODE>"); sb.append(custCode); sb.append("</CUST_CODE>"); } ······; return strXML; }這樣業(yè)務(wù)組件只是提供一個標準的 XML 格式輸出，由 Axis2 來管理生成基于 SOAP 的 Web 服務(wù)或者 RESTful Web 服務(wù)。界面層和業(yè)務(wù)邏輯層的通訊全部通過 RESTful Web 服務(wù)，不管客戶端采用什么實現(xiàn)技術(shù)，可以重用一個接口。
在業(yè)務(wù)組件內(nèi)部可以進一步分層，把協(xié)議層和業(yè)務(wù)邏輯層分離開，不管是采用直接調(diào)用 Servlet 還是 REST、SOAP 等，其后臺業(yè)務(wù)邏輯不變，使得業(yè)務(wù)邏輯更加獨立。如果是采用多層架構(gòu)，如上圖所示，其業(yè)務(wù)邏輯部分的代碼甚至可以在單機程序中使用，這樣分離之后，可以更方便的對代碼進行測試，本文不再進一步詳述。
采用 REST 架構(gòu)，實現(xiàn)界面層和業(yè)務(wù)邏輯層分離，業(yè)務(wù)邏輯在業(yè)務(wù)組件中實現(xiàn)重用，不會因為界面層的變化而引起業(yè)務(wù)邏輯層面的變化，實現(xiàn)界面層和業(yè)務(wù)邏輯層的獨立升級而不會有大的影響。界面層分離出來之后就可以實現(xiàn)界面開發(fā)和業(yè)務(wù)邏輯開發(fā)分開，在界面層可以任意采用基于 BS 架構(gòu)的的 JSP、HTML（DHTML）、ASP.NET、PHP、Applet、Flex 等，基于 CS 架構(gòu)的 Java、.Net、AIR 等任何一種界面開發(fā)技術(shù)，界面層的開發(fā)可以由獨立的 UI 小組完成，其成員可以不用關(guān)心業(yè)務(wù)邏輯，從而更加專注于人機交互體驗的完善。
基于 SOAP 和 REST 的業(yè)務(wù)組件（BC）接口模型
一個完整的業(yè)務(wù)組件需要實現(xiàn)松耦合，需要對外提供三種類別的接口：界面、服務(wù)、數(shù)據(jù)。界面主要是實現(xiàn)業(yè)務(wù)組件和人之間的人機交互媒介，服務(wù)是業(yè)務(wù)組件和業(yè)務(wù)組件或者系統(tǒng)之間的交互，是信息系統(tǒng)之間的交互媒介，數(shù)據(jù)是業(yè)務(wù)組件和共享數(shù)據(jù)庫之間的交互媒介（參見《面向服務(wù)體系架構(gòu)（SOA）和數(shù)據(jù)倉庫（DW）的思考》所述共享庫的概念），其中服務(wù)根據(jù)作用又可以進一步分成三小類：和人機交互相關(guān)的服務(wù)、和業(yè)務(wù)組件之間的交換以及和數(shù)據(jù)庫之間的交換。如下圖所示：
圖 4. 業(yè)務(wù)組件接口模型
- 人機交互媒介： 采用 Portlet 標準，對外提供標準的門戶程序，通過門戶集成平臺進行門戶集成。對外的門戶程序可以以兩種方式提供，一種是完全獨立的門戶程序，可以任意的集成到任何一個獨立的門戶界面，但是如果所有的界面都定制，考慮到性能和定制工作量比較大，可以采用另外的一種方式，即把多個界面定義到一個門戶程序中，可以將一系列的界面在一個門戶程序中完成，減少配置以及管理的工作，使得系統(tǒng)更加易于集成。比如可以把客戶信息展示作為一個簡單的門戶程序，僅僅實現(xiàn)客戶信息展示，也可以把客戶維護，客戶信息展示、客戶拜訪管理、客戶分類管理等所有客戶相關(guān)的信息在一個門戶程序中實現(xiàn)，并且在門戶程序中以菜單的方式進行選擇，相當于是內(nèi)嵌了一個小的應(yīng)用功能界面。
- Portlet 屬于比較重量級的標準，但是由于 Web2.0 尚未統(tǒng)一標準，如果輕量級的 Web2.0 有通用標準之后，采用 Widget 等將會是未來的發(fā)展方向。
- 對于同一一個開發(fā)商來說，在內(nèi)部可以采用自己定制的 Widget 標準方式，包含 Widget 的定義、Widget 之間的數(shù)據(jù)交互、界面風(fēng)格設(shè)定等。
- 服務(wù)接口： 服務(wù)接口按照類型可以分為 6 種，其中人交互服務(wù)和信息服務(wù)比較特殊，，分別實現(xiàn)人機交互和數(shù)據(jù)交換的功能，是以服務(wù)的方式提供人機交互媒介和數(shù)據(jù)接口內(nèi)容。
- 人機交互服務(wù)，將人機交互內(nèi)容以服務(wù)的方式提供，通過處理后在界面層次統(tǒng)一展示，通過這種方式，可以實現(xiàn)將不同的業(yè)務(wù)組件的服務(wù)混搭（Mashup）成一個門戶程序，而不是通過兩個門戶程序進行整合。人機交互服務(wù)和 Portlet 的差異是采用的標準不同，前者基于 Portlet 標準，后者基于基于 SOA 的 Web 服務(wù)或 RESTful Web 服務(wù)；前者直接以界面的方式對外提供，后者主要提供數(shù)據(jù)（可以同時提供展示方式，即一段 HTML 代碼），通過前端的定制工具實現(xiàn)界面展示，通過這種方式，在門戶系統(tǒng)進行界面整合，將不同系統(tǒng)的數(shù)據(jù)在界面進行統(tǒng)一展示，比如可以將財務(wù)系統(tǒng)的人員工資信息、人力資源信息等分別以服務(wù)的方式對外提供，然后在門戶的界面整合工具在門戶中統(tǒng)一進行展現(xiàn)，而不是通過 Portlet 的方式實現(xiàn)。如前文所述，采用 RESTful Web 服務(wù)
- 業(yè)務(wù)服務(wù)，業(yè)務(wù)組件為實現(xiàn)的業(yè)務(wù)組件核型功能的對外相關(guān)服務(wù)，是業(yè)務(wù)組件核心服務(wù)，主要用于本業(yè)務(wù)組件和其他的業(yè)務(wù)組件之間的業(yè)務(wù)交互，使得多個業(yè)務(wù)組件或者系統(tǒng)共同完成企業(yè)的業(yè)務(wù)流程。為了保證業(yè)務(wù)組件的高內(nèi)聚，松耦合，要合理的規(guī)劃業(yè)務(wù)組件對外提供的服務(wù)的粒度，即能保持靈活性，又可以保證對外提供的服務(wù)不至于太多，不宜管理。業(yè)務(wù)組件的 web 服務(wù)結(jié)構(gòu)是企業(yè)業(yè)務(wù)組件規(guī)劃中的最為重要的標準化功能，用于確定不同業(yè)務(wù)組件之間的邊界。
- 主數(shù)據(jù)服務(wù)，主數(shù)據(jù)相關(guān)的服務(wù)，是共用的服務(wù)，主數(shù)據(jù)管理業(yè)務(wù)組件也是屬于企業(yè)公共服務(wù)平臺管理范圍，是企業(yè)級的公共業(yè)務(wù)組件。
- 流程服務(wù)，涉及工作流程的服務(wù)，相關(guān)信息提供到工作流引擎，是共用的服務(wù)，流程管理業(yè)務(wù)組件也是屬于企業(yè)公共服務(wù)平臺管理范圍，是企業(yè)級的公共業(yè)務(wù)組件。
- 系統(tǒng)管理服務(wù)，是由系統(tǒng)管理公共組件提供的服務(wù)，主要包含用戶認證、權(quán)限管理等相關(guān)的服務(wù)，是共用的服務(wù)，系統(tǒng)管理相關(guān)業(yè)務(wù)組件屬于企業(yè)公共服務(wù)平臺管理范圍，是企業(yè)級的公共業(yè)務(wù)組件。主數(shù)據(jù)服務(wù)、流程服務(wù)和系統(tǒng)管理服務(wù)是企業(yè)架構(gòu)平臺提供的公共服務(wù)，是集成平臺的核心內(nèi)容。
- 信息服務(wù)，和數(shù)據(jù)庫相關(guān)的服務(wù)，直接從數(shù)據(jù)庫獲取相關(guān)信息。由于業(yè)務(wù)組件的數(shù)據(jù)是私有的，為了保證業(yè)務(wù)組件的數(shù)據(jù)能夠得到更好的應(yīng)用，需要將業(yè)務(wù)組件的數(shù)據(jù)公布出來，基于企業(yè)的數(shù)據(jù)模型，把業(yè)務(wù)組件的私有數(shù)據(jù)公開為企業(yè)數(shù)據(jù)中的數(shù)據(jù)。信息服務(wù)可以采用實時、或者準實時的方式對外提供。在某些特殊情況下，可以認為業(yè)務(wù)組件不存放數(shù)據(jù)，業(yè)務(wù)組件僅僅是獲得數(shù)據(jù)，處理數(shù)據(jù)，然后將數(shù)據(jù)在放到企業(yè)數(shù)據(jù)庫中。
- 數(shù)據(jù)接口： 基于視圖或者表直接對數(shù)據(jù)庫進行操作，即業(yè)務(wù)組件對外提供一個直接訪問數(shù)據(jù)庫的接口，如果數(shù)據(jù)庫結(jié)構(gòu)是按照這個接口設(shè)計的，這個業(yè)務(wù)組件可以直接訪問數(shù)據(jù)庫，而不需要通過其它的服務(wù)，需要明確每個組件對表的讀寫權(quán)限，并進行嚴格管理，通過數(shù)據(jù)接口的方式，核心是需要建立企業(yè)數(shù)據(jù)架構(gòu)，建立共享的數(shù)據(jù)結(jié)構(gòu)。通過數(shù)據(jù)聯(lián)邦、數(shù)據(jù)復(fù)制實現(xiàn)。一般來說，不建議這樣實現(xiàn)，特別是跨應(yīng)用的數(shù)據(jù)訪問，盡量通過信息服務(wù)實現(xiàn)。
以上通對業(yè)務(wù)組件模型對外提供的接口類型進行分析，規(guī)劃了一個業(yè)務(wù)組件接口模型，所有的業(yè)務(wù)組件將對外提供以上三類對外的接口。
基于 SOA 和 ROA 的整體技術(shù)架構(gòu)
結(jié)合當前流行的 SOA、Web2.0、3G、三網(wǎng)融合等技術(shù)，在基于 SOAP 和 REST 的分層模型的基礎(chǔ)上，開發(fā)的時候采用組件化開發(fā)，業(yè)務(wù)組件和業(yè)務(wù)組件之間的交互采用基于 SOAP 的 Web 服務(wù)作為接口模式，實現(xiàn)組件時間的松偶合，降低組件之間的關(guān)聯(lián)關(guān)系，不同的業(yè)務(wù)組件可以由不同的廠商實現(xiàn)；業(yè)務(wù)組件界面層和業(yè)務(wù)邏輯層之間的采用 RESTful Web 服務(wù)作為接口模式，實現(xiàn)界面層和業(yè)務(wù)邏輯層分離，客戶端可以采用電腦、手機、電視、各種 POS 機以及各種特殊終端設(shè)備，客戶端實現(xiàn)技術(shù)可以任意采用基于 BS 架構(gòu)的的 JSP、HTML（DHTML）、ASP.NET、PHP、Applet、Flex 等，或者基于 CS 架構(gòu)的 Java、.Net、AIR、C 等，在服務(wù)器端采用 J2EE 平臺實現(xiàn)業(yè)務(wù)邏輯，構(gòu)建一個多終端多技術(shù)平臺可復(fù)用的業(yè)務(wù)組件模型，如下圖所示：
圖 5. 基于 SOAP 和 REST 的業(yè)務(wù)組件模型
比如建立一個購物網(wǎng)站，在界面層可以采用 Flex 實現(xiàn)虛擬現(xiàn)實的 3D 技術(shù)實現(xiàn)游戲風(fēng)格的界面，同時實現(xiàn)業(yè)務(wù)操作，以提高用戶的使用體驗，使得網(wǎng)站更加有趣味性，更好的黏住用戶；或者采用 Flex 控件實現(xiàn)在 CS 架構(gòu)下才能實現(xiàn)的易用性，讓用戶在瀏覽器中能體驗到 CS 架構(gòu)程序的方便。采用 Flex 對于網(wǎng)絡(luò)的要求比較高，可以采用 JSP 實現(xiàn)基于 HTTP 的傳統(tǒng)的網(wǎng)頁購物界面和基于 WAP 手機購物界面，網(wǎng)頁購物界滿足大信息量，快速的數(shù)據(jù)瀏覽的需要，用戶可以快速完成交易；WAP 手機購物滿足無法上網(wǎng)，或者臨時無法上網(wǎng)的用戶，可以提供基于 WAP 的簡單網(wǎng)頁瀏覽，通過手機之間完成購物。
通過以上所述多終端多技術(shù)平臺可復(fù)用的業(yè)務(wù)組件模型，實現(xiàn)了業(yè)務(wù)邏輯的重用，并能夠靈活適用于各種場景。
總結(jié)
通過對 SOAP 和 REST 的對比分析，本文給出了一種基于 SOAP 和 REST 的組件模型，從而給出了了業(yè)務(wù)邏輯和界面展示分離的方法以及業(yè)務(wù)組件之間的服務(wù)定義。在界面層和業(yè)務(wù)邏輯層采用輕量級的 RESTful Web 服務(wù)，不同業(yè)務(wù)組件之間采用基于 SOAP 的 Web 服務(wù)將會是未來最有生命力的發(fā)展方向。
參考資料
學(xué)習(xí)
- 面向服務(wù)體系架構(gòu)（SOA）和業(yè)務(wù)組件（BC）的思考： 在基于面向服務(wù)體系架構(gòu)（SOA）中，“組件化”是一個很重要的概念，如何進行“組件化”開發(fā)是搭建企業(yè)級業(yè)務(wù)基礎(chǔ)平臺時需要考慮的一個重要課題，本文通 過建立業(yè)務(wù)組件（BC）接口模型及內(nèi)部結(jié)構(gòu)模型，提供了一個在新開發(fā)系統(tǒng)環(huán)境下基于 Web 服務(wù)和 OSGi 標準的組件化開發(fā)模型。
- 了解更多關(guān)于 WAS 的知識。WebSphere Application Server 產(chǎn)品專題
- 參考 Web 服務(wù)與 Axis2 體系結(jié)構(gòu)，了解 Axis2 內(nèi)容。
