在操作層協(xié)調java服務簡介
摘要
迄今為止，web應用程序開發(fā)的焦點在于將業(yè)務邏輯封裝成服務。在這篇文章中,Masayuki Otoshi建議將業(yè)務流程也剝離出來,就像那些業(yè)務過程管理/工作流產品一樣，應用基于XML的文檔來描述業(yè)務。但是這里他深入到了更低的粒度-操作。這篇文章同時展示了可繼承的XML如何容許開發(fā)人員應用面向對象的概念去有效的表示流程。
在開發(fā)web應用程序的過程中，我們經常看到業(yè)務流程和邏輯在action中一起被實現(xiàn)，比如JSF中的后臺bean和Struts中的action類。在現(xiàn)有框架的幫助下，比如EJB和Spring,我們能把業(yè)務邏輯剝離出來，但是業(yè)務流程始終還是嵌入在具體操作中。
BPM(業(yè)務流程管理)標準，比如BPMN(業(yè)務流程建模符號)和BPEL（業(yè)務流程執(zhí)行語言），提供了一種分離業(yè)務流程的途徑，那就是應用基于XML文檔來描述這種分離。這種方法的另外一個好處可以在SOA(面向服務架構)基礎上設計應用程序。但是，這種方法使得在web應用程序不能很好地應用action.actoin的粒度對于BPM/工作流產品來講太低了。他們通常專注于更高的業(yè)務范圍，如B2B應用程序和企業(yè)級的應用整合，而且他們假定業(yè)務分析人員會按照圖1所示的方法來描述流程。但是在更低的粒度上，比如action，流程再用的可能性更大。
圖1. 粒度比較
在這篇文章中，對于比較小的業(yè)務需求范疇，我建議java開發(fā)人員使用J-SOFA（Java Services Orchestration for Actions, Action級JAVA服務協(xié)調）。J-SOFA是一種協(xié)調服務的框架，這里的服務對應于類中的一個方法，無論是POJO(簡單潔凈Java對象)或者web服務。
由于粒度不同，J-SOFA并不支持消息，狀態(tài)管理，監(jiān)控等等的同步。但是不用擔心，目前的BPM/工作流產品都支持這些功能，我們可以直接應用這些產品。這篇文章所講到的服務協(xié)調框架主要關注于提供業(yè)務流程的可用性，就像服務那樣。
圖2說明了剝離的業(yè)務流程可以被其他應用程序重復利用。
圖 2. 可重用的業(yè)務流程及服務
版權聲明：任何獲得Matrix授權的網站，轉載時請務必保留以下作者信息和鏈接作者:Masayuki Otoshi ;
rainh95(作者的blog:
http://blog.matrix.org.cn/page/rainh95)
原文:
http://www.javaworld.com/javaworld/jw-04-2006/jw-0417-sofa.html?lsrc=jwrssMatrix:
http://www.matrix.org.cn/resource/article/44/44500_Business+Services.html關鍵字:Business;Services
JSF中的簡單action讓我們來看看用JSF開發(fā)的web應用程序中的一些簡單action的代碼。我們的例子是一個簡單的模型搜索程序：根據用戶輸入的模型ID返回模型具體信息。
你可以從這個資源下載這個示例的源代碼。
在搜索jsp頁面上，有一個文本框和一個submit按鈕，用戶可以輸入model id然后提交。這個jsp頁面通過一個叫ModelBean的后臺bean調用showModel()方法。如列表1所示:
列表 1. search.jsp中的inputText及Submit按鈕<h:inputText id="modelId" value="#{ModelBean.modelId}" />
<h:commandButton type="submit" value="Submit" action="#{ModelBean.showModel}" />為了產生模型具體信息頁面(搜索結果頁面)，showModel()方法創(chuàng)建Model對象和特征表，再賦值到屬性當中
列表 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è)務邏輯從具體操作中分離出來，通過一個model的service實現(xiàn)創(chuàng)建model和features，再通過interface來調用它。不管怎樣，如果其他人來維護后臺bean，我們還能保持這個方法這樣簡單嗎？這樣做可能被證明非常困難，因為不是所有的開發(fā)人員都明白隔離展現(xiàn)層和業(yè)務層的好處。如果一個持有不同觀點的開發(fā)人員開發(fā)維護后臺bean,她/他可能會將業(yè)務邏輯加入到showModel()中去。在項目中，這種狀況是很平常的，因為程序設計語言，比如這個例子中用到的java,容許我們用它強大的表現(xiàn)能力去實現(xiàn)任何業(yè)務邏輯。因此，我們應該用另外一種語言去實現(xiàn)業(yè)務流程，而不是java。
從一個框架的角度來看，預防開發(fā)人員沉溺于將流程和邏輯放在一起是非常重要的。描述業(yè)務流程的語言可能難于實現(xiàn)邏輯，但與此同時，卻能像編程語言一樣富有表現(xiàn)力。目前，需要應用BPM/工作流的概念去增加框架的解決方案。對于這個問題，我建議用XML-based文檔（程序定義XML）去描述流程，它可以指定需要按照什么順序調用哪些service。從而，應用了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標簽被調用，service標簽對應于service組件中所實現(xiàn)的方法。他們也可以被應用于條件或循環(huán)語句中，如if,choose,forEach等。然而，他們還是不如編程語言富于表現(xiàn)力。另外，J-SOFA并不能執(zhí)行從service標簽中獲得的模型和特性對象的方法，除非是通過getter方法。這些限制條件要求開發(fā)人員用XML描述業(yè)務邏輯時具備更加復雜的知識才干，不管怎樣，它們還是能幫助開發(fā)人員決定哪些業(yè)務邏輯應該用service類實現(xiàn)。有這些service方式實現(xiàn)的業(yè)務邏輯，我們可以開發(fā)基于SOA的應用程序，更能快速適應各種各樣業(yè)務模型的變化。
典型的web應用程序框架不支持服務協(xié)調，如JSF和Struts。所以，我們必須在showModel()方法中編寫下面的代碼去執(zhí)行處理：
列表 4. 調用流程的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"));
?? ...
}無論如何，如果框架擁有支持調用處理的功能，我們不需要創(chuàng)建action。相反，我們需要：
--創(chuàng)建流程定義XML
--創(chuàng)建用于在處理中被調用的service組件
--在JSP頁面編寫顯示處理返回值的代碼
在這部分，我解釋了流程定義XML如何為action定義流程；無論如何，其中的有些定義可以在真實世界中被重用。在下一節(jié)中，我將用另外一個例子去說明如何再利用流程。
可繼承的XML創(chuàng)建流程的時候，我們發(fā)現(xiàn)有些流可以被其他的流程共享。舉個例子，我創(chuàng)建了4個頁面，如下圖3所示：模型總覽，模型特性，和其他兩種分類索引頁面。所有的頁面包含相同的標題和頁腳。前兩個模型頁面用同一個Model對象來顯示模型信息，如模型名稱。后兩個分類頁面同樣那個也是用一個Category對象。最后，每個頁面有自己單獨的頁面處理進程。
圖3. 流程中的共享流
在這個案例中，每個流，如模型特性，能用subProcess標簽標識，它能執(zhí)行另外一個叫做“sub-process”的流程。
列表 5. modelFeatures.xml調用sub-processes(注意：在這個和后面的清單中，為了簡化代碼，service標簽中的子標簽將被省略)
<process>
?? <subProcess path="page.xml" />??---------- (1)
?? <subProcess path="model.xml" /> ---------- (2)
?? <service name="modelService" operation="getFeatures" /> ----- (3)
</process>
頁面和模型流程隱藏在每個sub-process中，但是我們仍然能找到從(1) 到 (3)的連續(xù)流。所以，如果我們要修改流，比如改變流的順序為(2), (3), (1),那么在另外的流程中，也不得不做這種改變。
為了解決這個問題，J-SOFA支持一種基于繼承的解決方法。基本的思路是提供這樣一種機制：容許導出一個基礎過程中的標簽，然后再重寫它。
我們可以在process標簽中用extends屬性創(chuàng)建一個導出過程。在這個例子中，過程的層次結構能用如圖4表示：
圖 4. 流程等級圖
Header和footer在基礎過程中定義，model和Category在導出過程中定義，導出過程從基礎過程中繼承了header和footer標簽。每一個代表一個特定的頁面的過程，可以看成是model或category過程的擴展。
在page.xml中，我們產生一個header和footer,可是，我們并不知道到底在這個頁面中會顯示什么內容(模型或者分類？)在此刻，abstract標簽會被導出流程中的其他標簽重寫，可以按如下方式應用:
列表 6. page.xml (基礎流程) <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標簽的extends屬性中。在這個XML塊中，我們只需要描述需要重寫的標簽。在這個案例中，model.xml中的group標簽重寫了abstract標簽，它在page.xml中有著相同的id ”contents”.
在這個時候，我們知道必須創(chuàng)建Model對象，可是我們不知道究竟哪個頁面會調用這個過程。因此，我們不創(chuàng)建一個具體的過程，而是用abstract標簽表示特定頁面的內容：
列表 7. model.xml (繼承流程) <process extends="page.xml">
?? <group id="contents">
??????<service name="modelService" operation="create" />
??????<abstract id="pageContents" />
?? </group>
</process>
如列表8所示,具體頁面內容在從model.xml繼承的modelFeatures.xml中描述。除了特性表之外所有我們需要創(chuàng)建的服務，都已經在基礎過程中定義，所以我們只需要重寫abstract標簽，用service標簽調用getFeature()操作。這樣，開發(fā)人員可以將焦點放在跟特定頁面相關的處理上。
列表 8. modelFeatures.xml (具體流程) <process extends="model.xml">
?? <service id="pageContents" name="modelService" operation="getFeatures" />
</process>
當過程實例被實例化時，page.xml,model.xml和modelFeatures.xml這三個XML文檔在執(zhí)行之前被創(chuàng)建,如下面列表9所標示的那樣:
列表 9. Model Features的復合流程 <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>
應用XML繼承方法,開發(fā)人員能夠重用在基礎過程中表述的工作流。開發(fā)人員同樣可以提供定義通用流的抽象過程,給其他開發(fā)人員描述特定頁面的過程。
結論用XML-based文檔描述工作流這個概念已經在BPM和工作流產品中實施。不管怎樣,到目前為止,它主要用于高層次業(yè)務描述中。在本文中,我們看到,這個概念同樣適用于web應用程序中的action。
服務協(xié)調框架將直接幫助開發(fā)人員決定哪些流應該用過程XML描述,哪些邏輯應用用service實現(xiàn)。結果是,應用程序會基于SOA設計和開發(fā),重用性會變得越來越好。
關于作者Masayuki Otoshi 是一個家公司的開發(fā)Web應用的高級程序員。他還負責這家公司的應用框架的設計與開發(fā)。
資源---下載本文源碼：
http://www5f.biglobe.ne.jp/~webtest/jsofa/misc/jw-0417-sofa.zip---J-SOFA主頁：
http://www5f.biglobe.ne.jp/~webtest/jsofa/
---Matrix:
Java,開源和中間件社區(qū)---Javaworld:
http://www.Javaworld.com