在操作層協(xié)調(diào)java服務(wù)簡介


摘要

迄今為止，web應(yīng)用程序開發(fā)的焦點在于將業(yè)務(wù)邏輯封裝成服務(wù)。在這篇文章中,Masayuki Otoshi建議將業(yè)務(wù)流程也剝離出來,就像那些業(yè)務(wù)過程管理/工作流產(chǎn)品一樣，應(yīng)用基于XML的文檔來描述業(yè)務(wù)。但是這里他深入到了更低的粒度-操作。這篇文章同時展示了可繼承的XML如何容許開發(fā)人員應(yīng)用面向?qū)ο蟮母拍钊ビ行У谋硎玖鞒獭?

在開發(fā)web應(yīng)用程序的過程中，我們經(jīng)常看到業(yè)務(wù)流程和邏輯在action中一起被實現(xiàn)，比如JSF中的后臺bean和Struts中的action類。在現(xiàn)有框架的幫助下，比如EJB和Spring,我們能把業(yè)務(wù)邏輯剝離出來，但是業(yè)務(wù)流程始終還是嵌入在具體操作中。

BPM(業(yè)務(wù)流程管理)標(biāo)準(zhǔn)，比如BPMN(業(yè)務(wù)流程建模符號)和BPEL（業(yè)務(wù)流程執(zhí)行語言），提供了一種分離業(yè)務(wù)流程的途徑，那就是應(yīng)用基于XML文檔來描述這種分離。這種方法的另外一個好處可以在SOA(面向服務(wù)架構(gòu))基礎(chǔ)上設(shè)計應(yīng)用程序。但是，這種方法使得在web應(yīng)用程序不能很好地應(yīng)用action.actoin的粒度對于BPM/工作流產(chǎn)品來講太低了。他們通常專注于更高的業(yè)務(wù)范圍，如B2B應(yīng)用程序和企業(yè)級的應(yīng)用整合，而且他們假定業(yè)務(wù)分析人員會按照圖1所示的方法來描述流程。但是在更低的粒度上，比如action，流程再用的可能性更大。


圖1. 粒度比較

在這篇文章中，對于比較小的業(yè)務(wù)需求范疇，我建議java開發(fā)人員使用J-SOFA（Java Services Orchestration for Actions, Action級JAVA服務(wù)協(xié)調(diào)）。J-SOFA是一種協(xié)調(diào)服務(wù)的框架，這里的服務(wù)對應(yīng)于類中的一個方法，無論是POJO(簡單潔凈Java對象)或者web服務(wù)。

由于粒度不同，J-SOFA并不支持消息，狀態(tài)管理，監(jiān)控等等的同步。但是不用擔(dān)心，目前的BPM/工作流產(chǎn)品都支持這些功能，我們可以直接應(yīng)用這些產(chǎn)品。這篇文章所講到的服務(wù)協(xié)調(diào)框架主要關(guān)注于提供業(yè)務(wù)流程的可用性，就像服務(wù)那樣。
圖2說明了剝離的業(yè)務(wù)流程可以被其他應(yīng)用程序重復(fù)利用。


圖 2. 可重用的業(yè)務(wù)流程及服務(wù)

版權(quán)聲明：任何獲得Matrix授權(quán)的網(wǎng)站，轉(zhuǎn)載時請務(wù)必保留以下作者信息和鏈接
作者:Masayuki Otoshi ; rainh95 (作者的blog: http://blog.matrix.org.cn/page/rainh95 )
原文: http://www.javaworld.com/javaworld/jw-04-2006/jw-0417-sofa.html?lsrc=jwrss
Matrix: http://www.matrix.org.cn/resource/article/44/44500_Business+Services.html
關(guān)鍵字:Business;Services

JSF中的簡單action

讓我們來看看用JSF開發(fā)的web應(yīng)用程序中的一些簡單action的代碼。我們的例子是一個簡單的模型搜索程序：根據(jù)用戶輸入的模型ID返回模型具體信息。

你可以從這個資源下載這個示例的源代碼。

在搜索jsp頁面上，有一個文本框和一個submit按鈕，用戶可以輸入model id然后提交。這個jsp頁面通過一個叫ModelBean的后臺bean調(diào)用showModel()方法。如列表1所示:

列表 1. search.jsp中的inputText及Submit按鈕

    <h:inputText id="modelId" value="#{ModelBean.modelId}" />
    

    <h:commandButton type="submit" value="Submit" action="#{ModelBean.showModel}" />
  

為了產(chǎn)生模型具體信息頁面(搜索結(jié)果頁面)，showModel()方法創(chuàng)建Model對象和特征表，再賦值到屬性當(dāng)中

列表 2. 在backing bean中的showModel()方法

    public String showModel() {
    

     if (modelId > 0) {
    

    ModelService modelService = new ModelService();
    

    BeanUtils.copyProperties(this, modelService.create(modelId));
    

    setFeatures(modelService.getFeatures(modelId));
    

     }
    

     ...
    

    }
  

高級開發(fā)人員可以像上面展示的代碼一樣將業(yè)務(wù)邏輯從具體操作中分離出來，通過一個model的service實現(xiàn)創(chuàng)建model和features，再通過interface來調(diào)用它。不管怎樣，如果其他人來維護后臺bean，我們還能保持這個方法這樣簡單嗎？這樣做可能被證明非常困難，因為不是所有的開發(fā)人員都明白隔離展現(xiàn)層和業(yè)務(wù)層的好處。如果一個持有不同觀點的開發(fā)人員開發(fā)維護后臺bean,她/他可能會將業(yè)務(wù)邏輯加入到showModel()中去。在項目中，這種狀況是很平常的，因為程序設(shè)計語言，比如這個例子中用到的java,容許我們用它強大的表現(xiàn)能力去實現(xiàn)任何業(yè)務(wù)邏輯。因此，我們應(yīng)該用另外一種語言去實現(xiàn)業(yè)務(wù)流程，而不是java。

從一個框架的角度來看，預(yù)防開發(fā)人員沉溺于將流程和邏輯放在一起是非常重要的。描述業(yè)務(wù)流程的語言可能難于實現(xiàn)邏輯，但與此同時，卻能像編程語言一樣富有表現(xiàn)力。目前，需要應(yīng)用BPM/工作流的概念去增加框架的解決方案。對于這個問題，我建議用XML-based文檔（程序定義XML）去描述流程，它可以指定需要按照什么順序調(diào)用哪些service。從而，應(yīng)用了J-SOFA之后, showModel()方法中的流程可以像下面這樣表示:

列表 3. process.xml

    <process>
    

     <if test="${modelId > 0}">
    

    <service name="modelService" operation="create">
    

    

     <return name="model" />
    

    </service>
    

    

    <service name="modelService" operation="getFeatures">
    

    

     <return name="features" />
    

    </service>
    

     </if>
    

    </process>
  

在上面的XML中,modelService的兩個操作通過service標(biāo)簽被調(diào)用，service標(biāo)簽對應(yīng)于service組件中所實現(xiàn)的方法。他們也可以被應(yīng)用于條件或循環(huán)語句中，如if,choose,forEach等。然而，他們還是不如編程語言富于表現(xiàn)力。另外，J-SOFA并不能執(zhí)行從service標(biāo)簽中獲得的模型和特性對象的方法，除非是通過getter方法。這些限制條件要求開發(fā)人員用XML描述業(yè)務(wù)邏輯時具備更加復(fù)雜的知識才干，不管怎樣，它們還是能幫助開發(fā)人員決定哪些業(yè)務(wù)邏輯應(yīng)該用service類實現(xiàn)。有這些service方式實現(xiàn)的業(yè)務(wù)邏輯，我們可以開發(fā)基于SOA的應(yīng)用程序，更能快速適應(yīng)各種各樣業(yè)務(wù)模型的變化。

典型的web應(yīng)用程序框架不支持服務(wù)協(xié)調(diào)，如JSF和Struts。所以，我們必須在showModel()方法中編寫下面的代碼去執(zhí)行處理：

列表 4. 調(diào)用流程的showModel()方法

    public String showModel() {
    

     ProcessInstance process = new ProcessInstance("process.xml");
    

    

     ProcessContext context = new ProcessContext();
    

     context.put("modelId", modelId);
    

     process.execute(context);
    

    

     BeanUtils.copyProperties(this, context.get("model"));
    

     setFeatures((List) context.get("features"));
    

     ...
    

    }
  

無論如何，如果框架擁有支持調(diào)用處理的功能，我們不需要創(chuàng)建action。相反，我們需要：
--創(chuàng)建流程定義XML
--創(chuàng)建用于在處理中被調(diào)用的service組件
--在JSP頁面編寫顯示處理返回值的代碼

在這部分，我解釋了流程定義XML如何為action定義流程；無論如何，其中的有些定義可以在真實世界中被重用。在下一節(jié)中，我將用另外一個例子去說明如何再利用流程。

可繼承的XML

創(chuàng)建流程的時候，我們發(fā)現(xiàn)有些流可以被其他的流程共享。舉個例子，我創(chuàng)建了4個頁面，如下圖3所示：模型總覽，模型特性，和其他兩種分類索引頁面。所有的頁面包含相同的標(biāo)題和頁腳。前兩個模型頁面用同一個Model對象來顯示模型信息，如模型名稱。后兩個分類頁面同樣那個也是用一個Category對象。最后，每個頁面有自己單獨的頁面處理進程。


圖3. 流程中的共享流

在這個案例中，每個流，如模型特性，能用subProcess標(biāo)簽標(biāo)識，它能執(zhí)行另外一個叫做“sub-process”的流程。

列表 5. modelFeatures.xml調(diào)用sub-processes
(注意：在這個和后面的清單中，為了簡化代碼，service標(biāo)簽中的子標(biāo)簽將被省略)

    <process>
    

     <subProcess path="page.xml" />---------- (1)
    

     <subProcess path="model.xml" /> ---------- (2)
    

     <service name="modelService" operation="getFeatures" /> ----- (3)
    

    </process>
  

頁面和模型流程隱藏在每個sub-process中，但是我們?nèi)匀荒苷业綇?1) 到 (3)的連續(xù)流。所以，如果我們要修改流，比如改變流的順序為(2), (3), (1),那么在另外的流程中，也不得不做這種改變。

為了解決這個問題，J-SOFA支持一種基于繼承的解決方法。基本的思路是提供這樣一種機制：容許導(dǎo)出一個基礎(chǔ)過程中的標(biāo)簽，然后再重寫它。

我們可以在process標(biāo)簽中用extends屬性創(chuàng)建一個導(dǎo)出過程。在這個例子中，過程的層次結(jié)構(gòu)能用如圖4表示：


圖 4. 流程等級圖

Header和footer在基礎(chǔ)過程中定義，model和Category在導(dǎo)出過程中定義，導(dǎo)出過程從基礎(chǔ)過程中繼承了header和footer標(biāo)簽。每一個代表一個特定的頁面的過程，可以看成是model或category過程的擴展。
在page.xml中，我們產(chǎn)生一個header和footer,可是，我們并不知道到底在這個頁面中會顯示什么內(nèi)容(模型或者分類？)在此刻，abstract標(biāo)簽會被導(dǎo)出流程中的其他標(biāo)簽重寫，可以按如下方式應(yīng)用:

列表 6. page.xml (基礎(chǔ)流程)

    <process>
    

     <service id="header" name="commonService" operation="getHeader" />
    

     <service id="footer" name="commonService" operation="getFooter" />
    

     <abstract id="contents" />
    

    </process>
  

在列表7中，model.xml可以看成是從page.xml得到的，所以，page.xml被列入process標(biāo)簽的extends屬性中。在這個XML塊中，我們只需要描述需要重寫的標(biāo)簽。在這個案例中，model.xml中的group標(biāo)簽重寫了abstract標(biāo)簽，它在page.xml中有著相同的id ”contents”.

在這個時候，我們知道必須創(chuàng)建Model對象，可是我們不知道究竟哪個頁面會調(diào)用這個過程。因此，我們不創(chuàng)建一個具體的過程，而是用abstract標(biāo)簽表示特定頁面的內(nèi)容：

列表 7. model.xml (繼承流程)

    <process extends="page.xml">
    

     <group id="contents">
    

    <service name="modelService" operation="create" />
    

    <abstract id="pageContents" />
    

     </group>
    

    </process>
  

如列表8所示,具體頁面內(nèi)容在從model.xml繼承的modelFeatures.xml中描述。除了特性表之外所有我們需要創(chuàng)建的服務(wù)，都已經(jīng)在基礎(chǔ)過程中定義，所以我們只需要重寫abstract標(biāo)簽，用service標(biāo)簽調(diào)用getFeature()操作。這樣，開發(fā)人員可以將焦點放在跟特定頁面相關(guān)的處理上。

列表 8. modelFeatures.xml (具體流程)

    <process extends="model.xml">
    

     <service id="pageContents" name="modelService" operation="getFeatures" />
    

    </process>
  

當(dāng)過程實例被實例化時，page.xml,model.xml和modelFeatures.xml這三個XML文檔在執(zhí)行之前被創(chuàng)建,如下面列表9所標(biāo)示的那樣:

列表 9. Model Features的復(fù)合流程

    <process>
    

     <service id="header" name="commonService" operation="getHeader" />
    

     <service id="footer" name="commonService" operation="getFooter" />
    

     <group id="contents">
    

    <service name="modelService" operation="create" />
    

    <service id="pageContents" name="modelService" operation="getFeatures" />
    

     </group>
    

    </process>
  

應(yīng)用XML繼承方法,開發(fā)人員能夠重用在基礎(chǔ)過程中表述的工作流。開發(fā)人員同樣可以提供定義通用流的抽象過程,給其他開發(fā)人員描述特定頁面的過程。

結(jié)論
用XML-based文檔描述工作流這個概念已經(jīng)在BPM和工作流產(chǎn)品中實施。不管怎樣,到目前為止,它主要用于高層次業(yè)務(wù)描述中。在本文中,我們看到,這個概念同樣適用于web應(yīng)用程序中的action。
服務(wù)協(xié)調(diào)框架將直接幫助開發(fā)人員決定哪些流應(yīng)該用過程XML描述,哪些邏輯應(yīng)用用service實現(xiàn)。結(jié)果是,應(yīng)用程序會基于SOA設(shè)計和開發(fā),重用性會變得越來越好。

把業(yè)務(wù)流程從操作中剝離出來