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