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