　　在一個已經使用Weblogic Integration和Workshop開發出多個應用程序的環境中您可能希望考慮一種支持以下功能的方法

　　組件重用

　　將多個應用程序共同部署到同一個WebLogic域上

　　本文關注單個Workshop/Weblogic Integration應用程序——即一個部署單元（一個ear）——的應用程序架構要記住多個應用程序可以部署到單個Weblogic Integration域上所提出的應用程序架構支持

　　代碼的重用維護和擴展

　　團隊工作

　　根據子元素的可變性在一個應用程序內對項目進行重新組織使其從一個應用程序變為多個應用程

　　稍後您將看到在一個應用程序內組織Workshop項目將對性能調優造成直接影響

　　我將分部分介紹

　　應用程序各層以及將代碼織入各層中的方法

　　在一個簡單示例中應用這些方法

　　對性能調優和部署的影響

第部分應用程序各層以及將代碼織入各層中的方法

　　在定義應用程序構件塊時一種好的方法是使用邏輯層這些邏輯層隨後可能被擴展為SOA層

　　對於復雜的應用程序我們通常定義個層如下圖所示層與層之間可能包含一個由消息總線（如AquaLogic Service Bus）組成的中介體在本文中我們將不討論中介體因為我們主要關注的是單個應用程序單個ear中的架構要記住隨後該應用程序在開發過程中將被拆分為多個應用程序每個應用程序都被公開為web服務成為一個SOA構件塊之後可以使用一個中間層進行服務與服務之間的整合而系統與系統之間的整合基本上使用Weblogic Integration來完成

　　這些層是SOA相關的它們在單個ear文件中也有意義類似地當在企業范圍內應用SOA時在單個應用程序中考慮無疑是提供構件塊的最簡單的方式

　　應用程序各層以及將代碼織入各層中的方法

　　復合層(Composite layer)向企業合作伙伴和外部客戶提供對服務的訪問提供必要的轉換過濾等該層可以聚合來自編排層的業務服務以提供對添加約束過濾和安全性等服務的外部訪問該層將用於編排層中的標准XML模型轉換為適用於外部業務合作伙伴的簡化模型該層向外部客戶端公開Web服務該層可能包含作為信息組合的頁面流頁面流可作為面向業務合作伙伴的Web Interface提供或者使用Weblogic Portal和WSRP將其公開為Web服務

　　編排層(Orchestration layer)該層包含了Weblogic Integration業務流程業務流程使用標准的XML數據格式該層用於編排許多後端系統在該層中使用標准的模型提供了該層與上下層之間的無關性在對一個後端系統進行更改以針對不同的業務合作伙伴提供適當的服務時這就提供了很大的靈活性和無關性

　　連通性層(Connectivity layer)該層提供到後端系統的訪問它提供從數據的後端表示法到用於編排層中的標准數據格式之間的相互轉換

　　在編排層中使用標准數據模型是一種好方法它提供了應用程序代碼與該應用程序所連接的其他系統之間的無關性標准的模型可能由XML模式中所表示的UML域模型組成流程之間這種XML數據的傳輸應該通過粗粒度消息（定義在UML域模型中由一組對象組成的消息）來完成XML中所表示的與DTO (data transfer object)模式相關的相同理念應該是一個好的起點

　　使用多個層並不意味著每次都必須通過各個層例如從表示層進入連通性層而不經過編排層的任何組件應該根據對公開於各個層的服務的重用需求對此進行考慮

　　在每一層中代碼和Workshop項目的邏輯編排應該仔細考慮以便提供更多的靈活性

　　那麼如何在一個Workshop應用程序中定義項目呢？

　　一個Workshop應用程序由多個不同類型的項目組成項目的類型可以是主要包含Weblogic Integration流程的流程項目主要包含java頁面流的Web項目用於需要在不同的項目之間共享的控件的控件項目等

　　那麼是否應該每個邏輯層定義一個項目呢？或者是在一個邏輯層中定義多個項目？

　　我的答案是根據具體條件在每個層上定義多個項目對於Workshop項目以下方法可幫助您做出決策

　　Bottomup（自底向上）

　　這是一種由來自後端系統的啟動窗體(starting form)組成的方法對於每個後端都應該定義一個或多個Workshop項目隨後（第部分對性能調優和部署的影響）我們將介紹定義多個項目的優點這些項目根據需要可以是控件項目或流程項目如果後端將使用一個Weblogic Integration事件生成器調用您的應用程序您可能就要考慮為該後端定義一個流程項目您可能還希望在該層定義應用XQuery轉換的流程一個好的實踐是不要在連通性層的Workshop項目中使用有狀態的流程

　　然後向上在編排層添加流程以編排不同的後端

　　Topdown（自頂向下）

　　企業所需的啟動窗體定義了用於表示企業和標准的XML模型的流程該模型隨後可被用於編排層您可能希望以UML為起點將域模型實體轉換為XML類型將實體組合轉換為XML元素（文檔）在該層定義將被用作流程的參數的文檔時要特別小心

　　將流程拆分為主流程中的子流程來表示業務只有節點具有業務涵義所有的細節都應該被抽取到子流程如果可以的話應該使用無狀態的子流程如果可以的話惟一的有狀態流程應該是最頂級的流程從一開始就要考慮對有狀態流程進行版本控制

　　從業務分析的角度將相關的流程聚合到不同的Workshop項目中以每個項目容納一個技術可重用方面的方式將所有技術可重用的流程放入特定的Workshop項目中

　　然後向下在連通性層添加控件或流程項目以提供從標准模型到相關的後端模型的轉換

　　Meetinthemiddle（在中間會合）

　　這是兩種方法的結合這種方法很難應用因為它要取決於您對相關系統的了解這種了解不只是業務方面的還包括技術方面的我認為最好是有一個或一組可以將應用的業務方面和技術方面結合起來的架構師您可能希望專注於該應用程序中的一個選定的部分覆蓋一個重要的用例並在開發過程中定義第一次迭代

　　我們來考慮一個典型的例子

　　兩個後端系統一個用於CRM一個用於記帳

　　兩組處理業務邏輯的可重用流程

　　一組表示業務流程或其一部分的長期活動的流程

　　一組處理錯誤的流程這組流程是我們要處理的技術方面之一

　　如第一部分中所說我們將使用由一個部署單元組成的單個Workshop應用程序作為起點並記得隨後可從不同的應用程序重用對後端系統的訪問如果在所有的應用程序內部都公開標准的XML模型那麼就很容易在不同的應用程序中重用對後端系統的訪問在流程之間傳遞的參數應該從設計角度和技術角度認真考慮後者將在本系列的第部分中進行討論

　　取決於後端系統的版本對後端系統的訪問可以有不同的生命周期並且可以在開發過程的後期單獨進行維護和部署此後應用程序的這些部分可以在不同的Workshop應用程序中重新組織並公開為服務如果這些服務由流程組成那麼可以通過webservices控件或流程控件/服務調度程序控件對其進行訪問對這些服務的訪問應該根據重用需求和重用來源進行考慮在部署在同一個Weblogic域上的應用程序之間如果考慮性能因素那麼就可能使用流程控件而不是服務調度程序控件我們將在本系列第部分中介紹性能問題

　　現在我們回到定義應用程序的項目上我們將從後端系統開始考慮為第一個後端定義兩個Workshop項目

　　[MyApplication][CRMServices]Processes和

　　[MyApplication][CRMServices]Controls

　　並為第二個後端定義一個項目

　　[MyApplication][BillingServices]Controls

　　注意

　　包含在方括號[]中的名稱是變量

　　對項目以及包含一組項目的Workshop應用程序的命名應該認真考慮所有項目名稱都應該以應用程序名稱([MyApplication])為前綴在本系列的第部分我們還將講到這一方面

　　在定義項目時我們假設CRM後端需要調用我們的應用程序這通常是通過Weblogic Integration事件生成器實現的這種情況下就必須有一個流程項目可能還需要應用XQuery轉換以便將編排層中所使用的標准XML模型轉換為後端XML格式或將後端XML模型轉換為標准模型在這種情況下可能需要一個流程項目考慮只在流程項目中使用數據轉換控制(dtf)

　　Weblogic Integration事件生成器需要使用一個消息調度程序渠道來發送從後端接收到的消息

　　對不同後端的訪問是在不同的Workshop項目中完成的這是有意為之的在第部分中我們將看到這將對性能調優造成直接的影響我們不希望來自後端的事件引發線程饑餓或可能的死鎖

　　在編排層我們可以考慮定義個項目

　　[MyApplication][MyModule]Processes

　　[MyApplication]ErrorManagerProcesses

　　在表示層我們可以考慮定義兩個web應用程序其中一個用於與應用程序相關的管理性任務

　　[MyApplication][MyModule]Web

　　除了這些項目外我們還可以定義一個用於可重用控制的項目和一個用於java類的項目

　　[MyApplication][MyCommonModule]Controls

　　[MyApplication][MyCommonModule]Java

　　下圖描述了所有這些

　　最佳實踐是在開始開發之前畫一張應用程序及其不同模塊或Workshop項目的圖這項任務應該由軟件架構師來完成並維護需要考慮與開發重用和性能調優相關的組織需求

　　圖中所使用的圖形表示法

　　注意如圖中所示我們可以在流程項目中定義控件和定制控件如果這些控件只由一個應用程序的一個項目使用那麼這是很實用的只有用於同一個應用程序或不同應用程序的不同Workshop項目的公共控件需要在控件項目中定義例如流程控件可能被用於從同一個Weblogic域中包含該流程的項目/應用程序之外的另一個項目或應用程序調用流程因此這些控件應該放入一個控件項目以便可以在不同的Workshop項目中重用如果需要在不同的Workshop應用程序中使用這些控件可以考慮將其放入一個公共目錄中並通過引用或作為庫將控件項目導入到不同的應用程序控件項目將在應用程序的APPINF/lib目錄下生成一個jar文件

第部分對性能調優和部署的影響

性能調優

　　根據層選擇多個項目之後正如本blog第部分所述業務模塊或後端將為應用程序性能調優提供更多機會如果來自後端的事件很多為了防止默認隊列中的所有線程都用於處理這些事件出現線程饑餓的情況這就相當有用對於Files Event Generators我們肯定能夠使用針對文件事件生成器中的輪詢文件的讀取限制進行一些調整但是這可能還不夠因此為屬於同一項目的所有流程指派一個專用的線程隊列可能是一種更好的方法

　　對於異步調用的流程或者對於具有緩沖方法調用的控件AsyncDispatcher隊列將用於調用一個Message Driven Bean而這個Message Driven Bean將使用在Workshop項目的WEBINF/wlwconfigxml文件中指定的執行隊列這種設置將在底層EJB的DD中生成正確的指派元素

　　<wlwconfig xmlns=> <asyncdispatchpolicy>applicationprojectExecuteQueueName</asyncdispatchpolicy> </wlwconfig>

　　對於同步調用例如由一個外部http Web Service調用啟動的同步調用需要在WEBINF/webxml中指定線程隊列

　　應該使用Weblogic Server管理控制台創建相關的執行隊列如果這些隊列不存在於服務器上那麼將使用默認的隊列

　　可以在wlwconfigxml Configuration File中找到更多信息

　　要了解Workshop的內在本質可以參考這篇文章l

項目和應用程序命名

　　在一個Weblogic域中Workshop項目名稱必須是獨一無二的一個Weblogic域可以作為組成Workshop項目的許多Workshop應用程序的宿主為了避免上下文沖突使用應用程序名稱作為所有項目的前綴是一個不錯的選擇

　　[WorkshopProjectName] = [ApplicationName][ModuleName]

　　使用Web Service Control或Service Broker Control來訪問項目上下文或流程是通過使用（默認）包含項目名稱的URL來實現的例如我們將會有

　　//server:port/[WorkshopProjectName]/com/mycompany/mymodule//ClientOrderjpd

　　Workshop項目內部使用的JMS隊列也是從Workshop項目名稱導出的一個叫做WorkshopProjectName 的項目將需要兩個隊列

　　[WorkshopProjectName]ProcessesqueueAsyncDispatcher

　　[WorkshopProjectName]ProcessesqueueAsyncDispatcher_erreur

從開始就考慮控制有狀態流程的版本

　　在 Versioning JPD On Running Instances中可以找到有用的相關支持模式

調用流程及相關考慮

　　當在同一個域中從一個流程調用另一個流程時根據設計抉擇可以選擇使用Process Control或Message Broker如果它們位於同一個Weblogic Integration域中這將對不同項目或不同應用程序中的流程有效從另一個Weblogic域調用流程可以使用Service Broker ControlWeb Service Control或JpdProxy來完成後者可以在任意java客戶端中使用

　　可以把Process Controls 復制到 ControlsProject從而在不同項目或不同應用程序中的流程之間共享它們

　　使用Process Control時如果子流程是同步的它將與調用者在同一個線程中執行在同一個Weblogic Integration域中使用Service Broker Control而不是Process Control這將使用在被調用的流程一方的另一個線程因為它將通過基於HTTP的 SOAP協議被調用這對於性能來說不是最優的

　　借助復雜的Java類型跨應用程序邊界使用Process Control進行同步調用時需要進行特殊的考慮應該把java類添加到應用服務器的系統classpath中以避免classcast異常有關classcast異常的信息請參考#文檔

　　注意在jpd中創建的XmlBeans文檔是以特殊方式進行處理的這由XmlBean的Factory完成而它將根據其執行的上下文來創建bean當在流程的上下文中調用XmlBean的Factory時它將創建一個類型為combeawlivariablesProcessXML的代理對象允許在應用服務器系統classpath中沒有XmlObjects類的情況下借助XmlObjects跨應用程序邊界使用Process Control進行同步調用

From:http://tw.wingwit.com/Article/program/Java/hx/201311/25661.html