在操作層協(xié)調(diào)java服務(wù)簡介
摘要
迄今為止，web應(yīng)用程序開發(fā)的焦點(diǎn)在于將業(yè)務(wù)邏輯封裝成服務(wù)。在這篇文章中,Masayuki Otoshi建議將業(yè)務(wù)流程也剝離出來,就像那些業(yè)務(wù)過程治理/工作流產(chǎn)品一樣，應(yīng)用基于xml的文檔來描述業(yè)務(wù)。但是這里他深入到了更低的粒度-操作。這篇文章同時(shí)展示了可繼續(xù)的XML如何容許開發(fā)人員應(yīng)用面向?qū)ο蟮母拍钊ビ行У谋硎玖鞒獭?br />
在開發(fā)web應(yīng)用程序的過程中，我們經(jīng)常看到業(yè)務(wù)流程和邏輯在action中一起被實(shí)現(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文檔來描述這種分離。這種方法的另外一個(gè)好處可以在SOA(面向服務(wù)架構(gòu))基礎(chǔ)上設(shè)計(jì)應(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)于類中的一個(gè)方法，無論是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)載時(shí)請務(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
要害字:Business;Services
JSF中的簡單action
讓我們來看看用JSF開發(fā)的web應(yīng)用程序中的一些簡單action的代碼。我們的例子是一個(gè)簡單的模型搜索程序：根據(jù)用戶輸入的模型ID返回模型具體信息。
你可以從這個(gè)資源下載這個(gè)示例的源代碼。
在搜索jsp頁面上，有一個(gè)文本框和一個(gè)submit按鈕，用戶可以輸入model id然后提交。這個(gè)jsp頁面通過一個(gè)叫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ù)邏輯從具體操作中分離出來，通過一個(gè)model的service實(shí)現(xiàn)創(chuàng)建model和features，再通過interface來調(diào)用它。不管怎樣，假如其他人來維護(hù)后臺bean，我們還能保持這個(gè)方法這樣簡單嗎？這樣做可能被證實(shí)非常困難，因?yàn)椴皇撬械拈_發(fā)人員都明白隔離展現(xiàn)層和業(yè)務(wù)層的好處。假如一個(gè)持有不同觀點(diǎn)的開發(fā)人員開發(fā)維護(hù)后臺bean,她/他可能會將業(yè)務(wù)邏輯加入到showModel()中去。在項(xiàng)目中，這種狀況是很平常的，因?yàn)槌绦蛟O(shè)計(jì)語言，比如這個(gè)例子中用到的java,容許我們用它強(qiáng)大的表現(xiàn)能力去實(shí)現(xiàn)任何業(yè)務(wù)邏輯。因此，我們應(yīng)該用另外一種語言去實(shí)現(xiàn)業(yè)務(wù)流程，而不是java。
從一個(gè)框架的角度來看，預(yù)防開發(fā)人員沉溺于將流程和邏輯放在一起是非常重要的。描述業(yè)務(wù)流程的語言可能難于實(shí)現(xiàn)邏輯，但與此同時(shí)，卻能像編程語言一樣富有表現(xiàn)力。目前，需要應(yīng)用BPM/工作流的概念去增加框架的解決方案。對于這個(gè)問題，我建議用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的兩個(gè)操作通過service標(biāo)簽被調(diào)用，service標(biāo)簽對應(yīng)于service組件中所實(shí)現(xiàn)的方法。他們也可以被應(yīng)用于條件或循環(huán)語句中，如if,choose,forEach等。然而，他們還是不如編程語言富于表現(xiàn)力。另外，J-SOFA并不能執(zhí)行從service標(biāo)簽中獲得的模型和特性對象的方法，除非是通過getter方法。這些限制條件要求開發(fā)人員用XML描述業(yè)務(wù)邏輯時(shí)具備更加復(fù)雜的知識才干，不管怎樣，它們還是能幫助開發(fā)人員決定哪些業(yè)務(wù)邏輯應(yīng)該用service類實(shí)現(xiàn)。有這些service方式實(shí)現(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)用處理的功能，我們不需要?jiǎng)?chuàng)建action。相反，我們需要：
--創(chuàng)建流程定義XML
--創(chuàng)建用于在處理中被調(diào)用的service組件
--在JSP頁面編寫顯示處理返回值的代碼
在這部分，我解釋了流程定義XML如何為action定義流程；無論如何，其中的有些定義可以在真實(shí)世界中被重用。在下一節(jié)中，我將用另外一個(gè)例子去說明如何再利用流程。
可繼續(xù)的XML
創(chuàng)建流程的時(shí)候，我們發(fā)現(xiàn)有些流可以被其他的流程共享。舉個(gè)例子，我創(chuàng)建了4個(gè)頁面，如下圖3所示：模型總覽，模型特性，和其他兩種分類索引頁面。所有的頁面包含相同的標(biāo)題和頁腳。前兩個(gè)模型頁面用同一個(gè)Model對象來顯示模型信息，如模型名稱。后兩個(gè)分類頁面同樣那個(gè)也是用一個(gè)Category對象。最后，每個(gè)頁面有自己單獨(dú)的頁面處理進(jìn)程。
圖3. 流程中的共享流
在這個(gè)案例中，每個(gè)流，如模型特性，能用subProcess標(biāo)簽標(biāo)識，它能執(zhí)行另外一個(gè)叫做“sub-process”的流程。
列表 5. modelFeatures.xml調(diào)用sub-processes
(注重：在這個(gè)和后面的清單中，為了簡化代碼，service標(biāo)簽中的子標(biāo)簽將被省略)
<process>
<subProcess path="page.xml" /> ---------- (1)
<subProcess path="model.xml" /> ---------- (2)
<service name="modelService" operation="getFeatures" /> ----- (3)
</process>
頁面和模型流程隱藏在每個(gè)sub-process中，但是我們?nèi)匀荒苷业綇?1) 到 (3)的連續(xù)流。所以，假如我們要修改流，比如改變流的順序?yàn)?2), (3), (1),那么在另外的流程中，也不得不做這種改變。
為了解決這個(gè)問題，J-SOFA支持一種基于繼續(xù)的解決方法。基本的思路是提供這樣一種機(jī)制：容許導(dǎo)出一個(gè)基礎(chǔ)過程中的標(biāo)簽，然后再重寫它。
我們可以在process標(biāo)簽中用extends屬性創(chuàng)建一個(gè)導(dǎo)出過程。在這個(gè)例子中，過程的層次結(jié)構(gòu)能用如圖4表示：
圖 4. 流程等級圖
Header和footer在基礎(chǔ)過程中定義，model和Category在導(dǎo)出過程中定義，導(dǎo)出過程從基礎(chǔ)過程中繼續(xù)了header和footer標(biāo)簽。每一個(gè)代表一個(gè)特定的頁面的過程，可以看成是model或category過程的擴(kuò)展。
在page.xml中，我們產(chǎn)生一個(gè)header和footer,可是，我們并不知道到底在這個(gè)頁面中會顯示什么內(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屬性中。在這個(gè)XML塊中，我們只需要描述需要重寫的標(biāo)簽。在這個(gè)案例中，model.xml中的group標(biāo)簽重寫了abstract標(biāo)簽，它在page.xml中有著相同的id ”contents”.
在這個(gè)時(shí)候，我們知道必須創(chuàng)建Model對象，可是我們不知道究竟哪個(gè)頁面會調(diào)用這個(gè)過程。因此，我們不創(chuàng)建一個(gè)具體的過程，而是用abstract標(biāo)簽表示特定頁面的內(nèi)容：
列表 7. model.xml (繼續(xù)流程)
<process extends="page.xml">
<group id="contents">
<service name="modelService" operation="create" />
<abstract id="pageContents" />
</group>
</process>
如列表8所示,具體頁面內(nèi)容在從model.xml繼續(xù)的modelFeatures.xml中描述。除了特性表之外所有我們需要?jiǎng)?chuàng)建的服務(wù)，都已經(jīng)在基礎(chǔ)過程中定義，所以我們只需要重寫abstract標(biāo)簽，用service標(biāo)簽調(diào)用getFeature()操作。這樣，開發(fā)人員可以將焦點(diǎn)放在跟特定頁面相關(guān)的處理上。
列表 8. modelFeatures.xml (具體流程)
<process extends="model.xml">
<service id="pageContents" name="modelService" operation="getFeatures" />
</process>
當(dāng)過程實(shí)例被實(shí)例化時(shí)，page.xml,model.xml和modelFeatures.xml這三個(gè)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繼續(xù)方法,開發(fā)人員能夠重用在基礎(chǔ)過程中表述的工作流。開發(fā)人員同樣可以提供定義通用流的抽象過程,給其他開發(fā)人員描述特定頁面的過程。
結(jié)論
用XML-based文檔描述工作流這個(gè)概念已經(jīng)在BPM和工作流產(chǎn)品中實(shí)施。不管怎樣,到目前為止,它主要用于高層次業(yè)務(wù)描述中。在本文中,我們看到,這個(gè)概念同樣適用于web應(yīng)用程序中的action。
服務(wù)協(xié)調(diào)框架將直接幫助開發(fā)人員決定哪些流應(yīng)該用過程XML描述,哪些邏輯應(yīng)用用service實(shí)現(xiàn)。結(jié)果是,應(yīng)用程序會基于SOA設(shè)計(jì)和開發(fā),重用性會變得越來越好。
關(guān)于作者
Masayuki Otoshi 是一個(gè)家公司的開發(fā)Web應(yīng)用的高級程序員。他還負(fù)責(zé)這家公司的應(yīng)用框架的設(shè)計(jì)與開發(fā)。
