基于Java的SOA分層研究與設計*

徐遇霄

(武漢市長虹橋37-1號 武漢 430064)

1 引言

霍金曾說:復雜性是21世紀的科學。當代對復雜系統的研究也表明,復雜性是由簡單性進化而來的。那么,我們如何將復雜的難事變為簡單的易事?對一般的復雜問題,將其分割為簡單的橫向子問題,就可以達到效果。對于更加復雜的問題,則需要在橫向子問題分割的基礎上,實行縱向分層。縱向分層也是一種抽象的分解復雜問題的方法。現在,一個軟件系統,往往是一巨型復雜系統。對于這種復雜系統的分析與實現,分層理論認為,降低其復雜性與提高效率的最好辦法是將系統分層實現。從軟件研究和開發的發展歷史、現行軟件的體系結構來看,分層方法一直都是軟件研發普遍適用的基本的思想方法。因此,在軟件體系結構中,把層次性系統作為架構風格,應用的相當廣泛。

2 SOA的分層研究

SOA的主要特點之一是平臺中立,平臺中立的Java Web服務技術是構建SOA系統一種很自然的選擇。在Java世界中,J2EE多層架構是一個典型的分層體系,同樣,基于Java的SOA系統也可采用分層模型。SOA有3個角色,其中服務請求者是服務的最終消費者,它對服務進行應用,則位于SOA的頂層-應用層。服務注冊中心負責服務的注冊,以便請求者能發現服務,在一定程度上履行了服務接口的功能。服務提供者構建實現服務的業務邏輯,部署服務并提供調用服務的環境。業務邏輯都由業務組件構成,業務邏輯層應該是獨立的一層。業務組件需要部署為服務,并要提供服務的描述以及調用服務的環境,請求者才能消費服務,因此,在應用層與業務層之間,可定義服務接口層,以實現業務層到應用層的平滑過渡。業務層一般要訪問數據庫,但不是直接訪問,可通過一個中間層來進行。中間層的作用是屏蔽訪問不同數據庫的差異,使數據庫對業務層是透明的。因此,數據庫位于系統的最底層,而業務層與數據庫之間的中間層可定義為數據接口層。至此,基于SOA的應用系統從上到下可劃分為如下5層:應用層、服務接口層、業務層、數據接口層和數據庫層,如圖1所示。

圖1 基于Java的SOA分層架構

服務接口層為應用層調用服務提供標準化的接口,從而使得該服務可提供給任何異構平臺和任何本地或者遠程用戶使用。

業務層主要提供系統的業務邏輯和控制,由一些基本的組件構成。

數據接口層為業務層提供統一的訪問數據庫的方式,以屏蔽業務層訪問不同數據庫的差異。

數據庫層完成數據的持久化功能。它提供了數據信息和數據邏輯,所有與數據有關的安全性、完整性、數據的一致性、并發操作等都在數據庫層。

數據接口層和數據庫層統稱為數據層。

3 數據層的設計

1)數據實體類的設計

在數據接口層的上一層業務層中,對數據的操作體現在業務管理類和業務處理類與業務數據類的交互。業務數據類是數據實體類的一部分。為了使業務層以一致的方式處理數據,首先,數據實體類應該采用一致的數據表示方式。在業務層中,所有的數據都由數據實體類來統一表示,這些類是基本的JavaBean,被稱為POJO或ValueObject,只有屬性和Get/Set方法,其作用就是供業務類使用,是業務類操作的對象。為了增強程序的可讀性并方便記憶,可將類的名稱定義為與表名相同,將類中的屬性名與表的字段名定義相同。這些數據類與數據庫進行映射,一般將數據實體類的屬性映射為數據庫中對應表的字段,非原子屬性則映射為表,這種映射關系通常由一個XML映射配置文件來完成。由于基于XML文本的配置文件可以靈活的改變,因此提高了系統的可移植性及易維護性,同時也在數據層體現了系統的松耦合性。

2)持久化技術的選擇

目前,在基于Java的程序設計中,常用的主要有以下幾種持久化技術:

(1)BMP(Bean-Managed Persistence),即Bean本身管理持久化。這種方式由在Java組件中嵌入JDBC代碼來實現,顯然,這是一種緊耦合的方式。

(2)CMP(Container-Managed Persistence),即容器管理持久化,表示由EJB容器來管理實體EJB的持久化。EJB容器封裝了對象/關系的映射及數據訪問細節。這是一種框架化的持久性機制,在這類機制中,由框架調用業務處理的類。這種機制的一個特點就是它提供一個管理環境,在這個環境中進行對象持久化。一旦離開這個環境,代碼就不能運行了。并且,理解并使用EJB的規范也不是很輕松的事情。

(3)JDO(Java Data Objects),Sun公司制定的描述對象持久化語義的標準API。嚴格的說,JDO并不是對象/關系映射接口,因為它支持把對象持久化到任意一種存儲系統中,包括關系數據庫、面向對象的數據庫、基于XML的數據庫,以及其他專有存儲系統。由于關系數據庫是目前最流行的存儲系統,許多JDO的實現都包含了對象/關系映射服務。JDO的出現似乎有了一些改觀,但是,JDO沒有一個好的開源免費實現。好的產品一般都是商業產品,并且在國內沒有銷售和技術支持。JDO也不是一個輕量級封裝,它建立的持久層框架很不完善,造成了JDO感覺比較笨重,使得很多操作方式很是煩瑣,JDO的應用在人們心理上一直布滿陰影。

(4)Hibernate,輕量級的開源ORM模型。它的一大優勢就在于可以把被持久化的對象實現成脫離這個持久化環境依然可以運行的類。Hibenate利用XML文件將應用程序的數據實體類與數據庫中的表進行映射,并通過框架的內部機制對復雜的數據操作提供支持,包括記錄的添加、修改和刪除等操作。因此,在基于Java的程序設計中,Hibernate成為持久層流行的框架技術,而它對于構建基于SOA的應用系統,也無疑是一個很優的選擇。下面簡要介紹Hibernate的原理。

Hibernate是一種比較徹底的Java對象關系映射工具,支持使用各種Java思想,如Inheritance(繼承),Association(關聯),Composition(組合),Collections(集合)等來實現對象關系映射。它可以直接映射大部分的POJO型的JavaBean,而不需要對它們作任何修改,即使需要修改,最多只在Bean里面加上一些私有訪問方法。它還可以將一個用戶定義的多個類的實例映射到一張表的同一行,甚至可以利用代理模式來簡化載入類的過程。這些功能都大大減少了利用HQL從數據庫提取數據的代碼編寫量,從而節約開發時間和開發成本。Hibernate利用Reflection機制,在系統啟動時生成SQL語句,進行對象的持久管理。Hibernate對每一種數據庫都有對應的Dialect進行操作優化,從而提高它在各種情況下的效率。

圖2所示 Hibernate的持久化服務在一個數據庫應用中的作用:應用程序通過

圖2 Hibernate持久化原理

Hibernate 連接到數據庫,對數據進行操作。Hibernate自身通過Properties或類的映射文件(Mapping XML)將數據實體類映射到數據庫的行。因此Application可以通過持久化的數據類直接訪問數據庫,而不必使用JDBC和SQL進行數據的操作。

Hibernate具有很大的靈活性,界于它的最大模式和最小模式之間的某些功能構件是可選的。在最小模式下,可選擇使用JDBC,可以利用JTA管理自己的事務,也可以使用JNDI。這時Hibernate通過 SessionFactory提供 Session,在 Session中對持久化對象進行操作。在最大模式下,Hibernate在自己的底層管理 JNDI、JDBC和 JTA,在上層向外提供 SessionFactory、Session和 Transaction的接口,供 Client控制Persistent Object之用。

3)數據庫訪問的設計

(1)數據實體類與表的映射

Hibernate定義了類到數據庫的基于XML的映射文件。映射文件中的“class”元素定義了需持久化的類與數據庫中表的映射關系,“name”屬性指定了類名,而“table”屬性指定了數據庫中的表。“id”元素定義了鍵屬性。“property”元素定義了類的屬性與表中字段的映射。具體的映射文件可見后文的實現部分。

(2)配置 Hibernate

配置Hibernate通過設置其配置文件來完成。該文件描述了數據庫的驅動程序以及數據庫的URL等連接數據庫的信息。Hibernate在應用程序啟動時自動進行初始化工作。配置描述文件可以是hibernate.cfg.xml或 Hibernate.properties文件。

Hibernate對JDBC進行了封裝,自動進行JDBC連接,并使用SessionFactory來打開數據庫的連接。使用Hibernate時,我們可以提供外部連接池,亦可配置Hibernate使用它自己直接支持的池(C3PO,Proxcool)。Hibernate可以根據用戶的數據庫設置一個正確的hibernate.dialect語言。它支持 Oracle、Ms SQL、My SQL 、DB2等多種語言 。Hibernate提供的HQL也支持外部連接查詢,這些連接類型是從SQL中借鑒來的:inner join(內連接)、left outer join(左外連接)、right outer join(右外連接)、full join(全連接,并不常用)。但外連接也可通過設置Outer-join屬性為False來禁止,因為使用它會占用過多的資源。

Hibernate可靈活地設置數據庫的驅動程序及數據庫的URL。這樣,在進行系統設計時,我們可以不去關心底層采用的是何種數據庫。加之我們引入ORM技術,使得業務邏輯和數據邏輯分離。在此二者基礎上,我們就構建了出一個抽象層—數據接口層。數據接口層的引入一方面增強了系統的靈活性和可移植性,另一方面也體現了SOA的松散耦合性。

(3)使用Hibernate進行數據庫訪問

Hibernate運用框架模型如圖3所示。

圖3 Hibernate應用框架模型

其中:*.hbm.xml是數據實體類與表的映射文件,*_Access.class是數據訪問類文件,*.class是POJO型的數據實體類文件。

4 業務層的設計

1)業務邏輯的實現策略

我們可以將業務層類分為三大類:業務管理類、業務處理類和業務輔助類,如圖4所示。在數據接口層提供的數據實體對象和對象的持久性存儲機制的基礎之上,就可以將這些對象根據業務需求由業務層的類組合起來,構建系統的業務邏輯處理程序。

圖4 業務層類框架圖

2)服務粒度的選擇

我們可以用服務樹來刻畫服務的粒度。所謂服務樹,是把要部署為服務的功能模塊用樹型結構來進行表示,如圖5網上定購服務樹所示。

圖5 服務樹圖

服務樹清晰地反映出了服務的粒度,是構建SOA系統時決定服務粒度的有力工具。我們可以利用服務樹找到SOA系統最佳的服務粒度方式。

服務接口層通過部署,將業務層的業務管理類暴露為服務,因此,業務管理類所實現的業務邏輯的粒度就決定了系統服務的粒度。SOA傾向于粗粒度的服務,在進行系統之間的通信時,這有很大的優勢,因為粗粒度的服務減少了系統之間的交互,提高了系統的運行效率,特別是異構異地的系統之間的通信。但在進行企業內部應用系統之間集成,或系統內部的構建時,粗粒度的服務降低了系統的靈活性,增大了系統的耦合性。所以,我們在構建SOA系統時,要選擇一個合適的服務粒度。

5 服務接口層的設計

1)Web服務引擎AXIS

Apache可擴展交互系統(Apache eXtensible Interaction System,AXIS)是在基于可配置的消息鏈和Handler對象重新設計SOAP的過程中發展而來的。它是基于 Java的、最新的SOAP規范(SOAP 1.2)和SOAP with Attachments規范的開源實現。圖6表示了AXIS引擎的基礎結構。

圖6 AXIS基礎結構

AXIS可作為Web服務引擎工作于服務接口層,也可作為服務請求方環境運行于應用層,因此,它是構建基于Java的Web服務的良好選擇。

2)使用AXIS部署服務

使用AXIS將業務層的組件部署為Web服務有以下3種方式:

(1)最簡單的方式:jws方式

AXIS提供了一種將帶有.jws擴展的Java類部署為Web服務的簡單方式。它的實質是AXIS將Servlet引擎中的Java Servlet自動部署為Web服務。常用的Servlet引擎是Apache的 Tomcat容器。這種方式以Java類的源文件為基礎,部署方法很簡單,只須將以.java為擴展名的源文件,重命名為以.jws為擴展名的文件,復制到Axis Web應用程序的主目錄中。當該Web服務被訪問時,Axis會根據.jws文件自動生成相應的 WSDL及SOAP端點,即自動將.jw s文件部署為Web服務,而無需WSDD部署描述符。這種方式也無需編譯該文件,Axis運行庫會自動進行類及其所有方法的編譯。

獲取該服務的WSDL與其它方式相同,只需在訪問該服務的URL后加“?WSDL”參數即可,如“http://localhost:8080/axis/HelloWorld.jws?WSDL”。

以.jws文件形式創建Web服務的方法,從簡易性及可操作性的角度來看,非常類似于JSP。這種方式一般用于建立單一的或簡易的Web服務。

(2)使用WSDD將JSE組件部署為Web服務

以.jws文件部署基于Java的Web服務雖然既簡單有快捷,但缺乏服務部署的靈活性,例如,我們需要將JSE組件中的某些方法而非全部發布為Web服務。Axis提供了 Web服務部署描述符(Web Service Deployment Description,WSDD)的方法,可以對Java Web服務進行一些高級的定制部署。該方法需要創建一個部署服務(deployment)的XM L描述文件(*.wsdd)和一個卸載服務(undeployment)的XML描述文件。這些文件將告訴AXIS如何處理對Java Web服務的特定調用。

(3)使用WSDD將EJB部署為Web服務

在開源的EJB服務器(或容器)中,我們選擇JBoss公司的JBoss服務器。JBoss集成Axis時,需將Axis文件夾復制到JBoss的部署目錄中。另外,我們還要確保Axis能夠為EJB載入類文件,方法是將該EJB的.jar包文件復制一份到Axixlib文件夾中。一般情況下,我們使用Axis將JBoss中的無狀態會話(Stateless SessionBean)類型的EJB發布為Web服務,目前可采用如下兩種常用的方法:

①使用基于EJB的WSDD,這種方式同上述第2種情形大致相似,只是WSDD中有更多的元素來描述EJB,因為EJB相對于JSE,有更多的要遵循的規范。

②使用JBoss的 JBoss.NET模塊,用 XML Web服務描述符來部署。JBoss.NET[29]是JBoss集成了Axis后的部署Web服務的一個工具。利用它進行部署工作要依賴于.wsr文件,該文件可視為打包版的Axis的WSDD。.wsr文件是一個標準的.jar文件,僅包含一個名為META-INTweb_service.xml的XML Web服務描述符。

JBoss公司目前正在進行一個被稱為“JBoss-WS”的項目,其目標是重構JBoss應用服務器,以使用他自己的SOAP協議棧而不是集成Axis。

6 應用層的設計

應用層客戶端在構建用戶的業務流程時,一般要先完成調用服務以及基于XML的數據處理兩項任務。客戶端調用服務大多數情況下是為了進行數據通信。對于服務的請求方和提供方,二者都基于XML的數據格式進行通信,因而在調用服務進行數據通信時,需要將用戶關心的數據進行串行化或反串行化(AXIS引擎只自動實現SOAP消息的串行化或反串行化)。所謂串行化數據是指將應用程序的數據格式轉換為XML格式,反串行化則反之。根據數據的流向,可分為兩種情形,一是通過調用服務向服務提供方發送數據(如圖7所示),如向網上商店提交的訂單,需要進行數據串行化。

圖7 串行化流程

二是調用服務從服務提供方獲取數據(如圖8所示),如獲取商家的產品信息,這與第一種情形正好相反,需要進行數據的反串行化。

圖8 反串行化流程

對于第一種情形,客戶端應用程序先將數據串行化為XML格式,然后用SOAP協議進行封裝,調用服務發送即可。對于另一種情形,客戶端一般先接收調用服務所獲取的基于XML格式的字符串,然后將其反串行化為用戶所需類型的數據。

圖9 應用層數據處理架構

客戶端在調用服務發送數據,進行數據的串行化之前,需要采集原始數據。而在調用服務獲取數據并進行反串行化之后,需要顯示數據或進行持久化。因此,應用層除了要進行數據串行化或反串行化外,還需要實現數據的顯示或提交邏輯。對于客戶端,這一處理邏輯可以基于C/S方式,為用戶提供靈活友好的使用界面,進行顯式處理,或直接用程序組件隱式處理。客戶端亦可基于B/S方式,建立精美的Web頁面顯示或提交數據。應用層數據處理的架構如圖9所示。

7 結語

本文所論述的應用層側重于服務調用的設計,而沒有過多涉及應用系統客戶端的具體實現。因為實際上,客戶端程序都將調用服務作為函數(或過程)來實現。系統開發人員在構建客戶端應用程序時,可以采用B/S或C/S方式,并在其中調用訪問Web服務的函數,來構建最終的應用系統。而不論是B/S還是C/S,都已經是很成熟的模型,這兩種模型也都有非常成熟的技術可以實現。

作為一個剛剛步入實踐的新事物,SOA還面臨著很多的挑戰。SOA還正處在不斷的發展之中,它的成熟度和完善性還有待于研究人員和企業在理論和實踐中不斷的加以提高和改善。雖然被稱為是繼面向過程和面向組件的下一代軟件體系結構,但目前還沒有以上兩種架構成熟,且目前的應用才剛剛起步。然而,由于SOA自身具有的優勢順應了未來軟件發展的趨勢,并隨著各大軟件供應商在此展開的深入研究和激烈競爭,它必然會成為成熟的下一代軟件體系架構和主流開發技術而得到廣泛支持和應用。可以預見在未來的幾年里,SOA將會取得長足的發展。

[1]胡光.基于Jini的查找服務實現[J].計算機應用研究,2005(2)http://www.bea.com/framework.jsp?CNT=index.htm&FP=/content/solutions/technical/web_services

[2][美]科耶爾.XM L、Web服務和數據革命[M].袁勤勇,等譯.清華大學出版社,2003

[3]蔡月茹,柳西玲.Web Service基礎教程[M].北京:清華大學出版社,2005,6

[4]張凱.軟件復雜性與質量控制[M].北京:中國財政經濟出版社,2005,11

[5]姜璐.復雜系統的層次結構,復雜性研究[M].北京:科學出版社,1993,7

[6]伽瑪,等.設計模式:可復用面向對象軟件的基礎[M].李英軍,等譯.北京:機械工業出版社,2000,9

[7][美]尼戈潘,等.Java Web服務開發[M].龐太剛,陶程,譯.2004,5