http://dev2dev.bea.com.cn/bbs/yuanch/ArticleShow.jsp?Id=55
標題：Weblogic Portal 架構分析和我的開源實現方案
[評論]
作者：陳龍 （dev2dev ID：SCEA）
文章摘要
Weblogic Portal(以下簡稱WLP) 的設計思想有許多先進之處，而其中最重要的思想都凝聚在充分發揮XML的作用和面向服務的架構(SOA)上。本文將用藍圖的形式向你展示WLP的整體架構，并詳細介紹XOA(XML-Oriented Architecture,我發明的概念)和SOA。
在分析完WLP的架構之后，將向大家介紹一下我用開源項目對這個架構的模擬方案，這套方案有利于讀者掌握 WLP，也有利于深入理解Portal的概念，并且可以作為自己Portal產品開發的參考。需要強調的是本文不會向你介紹某一個著名的開源項目，如JetSpeed，而是為大家提供一種由多個開源項目組合而成的全套開源解決方案。你可以把這套方案看作是WLP的開源版本，方案本身沒有過多革新之處，僅有一處改進，所以這套方案是The WLP Reloaded，并非The WLP Revolutions。
目錄：
Weblogic Portal 的架構分析和我的開源實現方案...
WLP的藍圖...
走進Portal，一切都是XML.
面向服務的架構...
WLP藍圖的開源實現方案...
分塊描述...
總結...
WLP支持包括設計，開發，配置，管理，測時，運行在內的整個Portal生命周期。它由三大模塊組成：Weblogic Workshop Portal Extension，Weblogic Portal Admin Console，Weblogic Portal Server，這些模塊的關系見下圖：
圖1
藍圖可以分為三大區域：底層基礎結構(灰色區域)，產品模塊(黃色區域)，外部應用、數據、資源(藍色區域)。需要注意的是Weblogic Portal Admin Console其實是一個Portal應用的特例，和你將要開發的Portal一樣其本身就是一個Portal。
圖形的嵌套說明兩者的包含和被包含關系。但是如果被包含的子？槿綣脅糠窒月對詬改？櫓猓蛩得髯幽？槭歉改？櫚氖涑鱟榧幣彩竅嗔諂淥？櫚氖淙胱榧?/span>
類似于坐標系統，每個單元模塊在結構圖中的相對位置有著不同的含義。自下向上，底層模塊是上層模塊的基礎和平臺，底層模塊為上層模塊提供服務和組件管理。上層結構代表可視和具體，下層結構代表透明和抽象。自左向右，左側模塊為右側模塊提供可用組件，右側模塊沒有左側模塊的工作成果就沒有意義，同時也是項目實施的作業順序。
寬箭頭代表XML數據流，細箭頭代表用戶屬性信息。從同中可以看出，XML數據是產品模塊間的主要數據流形勢，伴隨有少量用戶信息數據。所有的組件定義都由XML文檔表示和配置。
在圖中，紅色邊框部分是對WLP單點登錄方案的補充解釋，具體的文字說明請參見《BEA Weblogic Portal項目實施解決方案集》一文的相關部分。
WLP整體架構中蘊藏的兩大設計理念分別時面向XML的架構和面向服務的架構，XOA應用于Portal extension中，SOA應用于整個Weblogic Platform。正是這兩點保證了WLP具有豐富靈活的界面表現和強大的服務整合能力。下面兩節是對這兩點的詳細說明。
還記得《Thinking in Java》一書中有一節的標題是Everything is an object，那么現在可以說在WLP中一切都是XML，叫Everything is an XML file in the Weblogic Portal World。在我還不太了解WLP的時候認為WLP是基于XML技術的，但是隨著對WLP的深入理解，一種更深的觸動隨之產生了，原來WLP是面向XML的，它已超越了面向對象和基于XML這兩層含義。在WLP中的Portal組件有Portal，Shell，Look & Feel，Skeleton，Book，Menu，Page，Layout，Portlet，UUP等，這些組件都是Portal的基石，在這里開頭字母大寫說明他們等同于面向對象語言中的類，當Portal設計完成處于運行階段時(Runtime)，系統會為每個用戶生成這些類的對象。
WLP設計的精美之處就在于對這些XML的處理。無疑Portal這個類是最重要的，它包含的信息類似Java語言中的Main方法，Portal的生成及界面的展現都從這里開始，它是Portal的Portal（入口的入口）。我們可以把在Portal設計階段由Workshop生成的這些組件稱為基礎Portal類（Portal Foundation Class）。Workshop起到了面向XML的可視化集成開發環境的作用。
基礎Portal類作為Workshop的成果輸出給Weblogic Portal，并且在Weblogic Portal admin Console中可以對它們進行配置和管理。Admin Console把這些基礎類作為Library看待，管理員配置的Portal和Desktop等都是Library中的基礎類的組合或變體。我們可以把在Portal設計階段由Admin Console生成的這些組件稱為用戶Portal類（Portal Customer Class）。這是的類已經不是XML文件形式的了，而是以二維表格的形式存儲在關系型數據庫中，面向XML的思想到此終結。我個人認為沒有必要這樣做，應該沿用XML文件形式。首先，在實際使用當中會發現用戶Portal類其實還是起到組件定義的作用，只是這類組件更接近用戶，攜帶更多的個性化參數，數據量和用戶數量沒有必然聯系，不會隨著用戶數量的增加而增加。其次，如果采用XML文件形式，在界面展現時還可以采用靈活的XSLT方式，而沒必要自己實現另外一套用戶界面機制(netuix)。對這一部分的改進方案在開源替代方案中作進一步說明。
除了用XML定義Portal組件體現了WLP面向XML的特性之外，在內容和應用整合方面WLP也利用了XML。如果僅僅是內容的整合，可以利用RSS。如果還需要整合應用，就利用WSRP(Web Services for Remote Portlets)。然而在整合這個問題上另外一種情況是不可避免的，那就是如何整合多個Portal成為一個統一Portal架構(Unified Portal Architecture)。統一的Portal意味著統一的安全機制，一致的用戶界面等等相關問題。
為了解決上述問題，BEA在原有Weblogic Platform的基礎上進一步提出SOA驅動的Portal(SOA driven Portal)概念。BEA最近的一份白皮書中這樣說：“為了創造一個為所有用戶服務的單一Portal環境，就必須使用面向服務的架構”。
拿統一的安全機制來說，Security是Weblogic Server為整個Weblogic Platform提供的一個通用服務，在Weblogic Platform之上開發的所有應用都可以共享這個服務。由于每個應用不必自己實現安全機制，不但節省了開發成本還為Portal實現單點登陸提供了可能(如何實現WLP的單點登陸請看《BEA Weblogic Portal項目實施解決方案集》一文的相關部分)。
SOA正在受到越來越多的軟件企業和開發人員的關注，IBM, Borland, Oracle紛紛公布了自己的SOA計劃，微軟也認為面向服務的架構將超越面向對象的編成方法(The world of service-oriented architectures (SOA) will eclipse object-oriented programming)。無論MDA,AOP還是SOA都是一種軟件開發的思維模式，他們都告訴我們一點：不要只考慮對象，而是要把更多的精力用在考慮更宏觀的事物上，如模型，方面，服務。
基于上述對WLP的分析，尤其是對面向XML和面向服務的架構的剖析，現在給出我的開源項目實現方案。這個開源項目放案的重點還是XOA和SOA。見下圖：
圖2
該圖的結構說明和圖1基本一致，兩幅圖的單元模塊之間存在影射關系，但是為了表達的更加準確增加了圖例。另外要注意，相鄰的兩個單元模塊，如果邊界接觸就說明兩者之間的關系為緊耦合，如果存在間隙則說明是松耦合。緊耦合意味著上層模塊對下層模塊的依賴，下層模塊對上層模塊的不可或缺，松耦合意味著可替換，可不用。
這個開源解的解決方案中的開源項目主要來自兩大開源組織，Apache 和Eclipse。Apache的項目有:Struts, Turbine, Cocoon, Velocity, Pluto。這部分和SOA相關。
Eclipse的項目則主要集中在Eclipse Project和Eclipse Tools Project子項目中關于可視化圖形用戶界面部分。主要有SWT，GEF，EMF，VE。這部分和XOA相關。
* Eclipse部分
Eclipse是IBM發起成立的一個開源組織。在屢次和SUN爭奪Java標準控制權沒有如愿后，不難看出IBM要用Eclipse達到兩個目的，也是兩個標準。其一就是建立軟件集成開發環境的標準，不僅僅是Java的集成開發環境，而且也可以是C++的集成開發環境。用Eclipse作為開發環境的最大特點就是可視化，這一特點得益于Eclipse的優秀的可視化組件技術SWT以及基于SWT之上的其他可視化編輯技術。其二就是面向方面的編成(AOP)標準，這一點不是本文要討論的。由于Eclipse平臺是以IBM捐獻的部分WebSphere Visual Age 系列開發工具的源碼為基礎發展而來的，所以Eclipse繼承了很多Visual Age的優秀思想和成果，如Workbench和Workspace映射等。我之所以要用Eclipse代替Workshop完成Portal的可視化設計任務就是因為Eclipse的這個思想。
圖3 Eclipse的架構
下面分別對各個部分進行簡要說明：
1. SWT
SWT(Standard Widget Toolkit)，是類似AWT/Swing的可視化組件，但是他和AWT/Swing的實現機制不同。Swing是完全是通過模擬不同操作系統上的可視化組件表現風格實現不同的Look & Feel的。而SWT則是先調用本地操作系統的可視化組件，如果本地操作系統沒有這種組件才去模擬，單是無論采取那種方式，SWT給開發人員提供統一的API。SWT這樣做的優點是簡單，小巧，運行速度快，既和操作系統緊密結合又可在不同操作系統只見自由移植。SWT被Java Developer’s Journal評為最佳 Java組件，所以使用SWT不僅能夠開發出正宗的本地Look & Feel，還能學習到其最佳的設計思想。
2. GEF
GEF(Graphical Editing Framework)，可以為一個應用模型創建圖形編輯器。例如有一個設計數字電路的軟件，所有的電路組件和設計方案都以XML格式保存，現在需要一個圖像化的設計器使設計更直觀。用GEF就可以對這個應用模型構建圖形編輯器，如下圖：
圖4 (來源Eclipse.org)
如果應用模型換成Portal，那么同樣可以用GEF做一個類似的圖形編輯器。
3. EMF
EMF(Eclipse Modeling Framework )，可以把模型轉化為Java代碼或者XML文檔，也就是代碼生成。EMF被廣泛的應用在MDA中，作為從UML到代碼只見的轉換工具。在我的方案中EMF負責把可視化的Portal組件模型轉化成為XML文檔。
4. VE
VE(Visual Editor)，是一個基于EMF的圖形用戶界面開發框架，是一個GUI的組裝器。用戶對由VE生成的可視化工具實行可視化操作(拖拽等)時，對應的Workspace中的Java和XML等文檔會發生相應改變，反之亦然。
* Apache部分
Apache是最著名的開源組織，隸屬于Apache軟件基金會(ASF)。Apache中的大部分項目都是開源世界的典范。下面介紹的內容都可以在apache.org上找到更多資料。
1. Struts
Struts作為基于JSP的Web應用框架已被國內不少開發團隊接受。Struts的特點是開發迅速，配置簡單，可以有多個人分別實現不同用例然后再通過配置文件合并這些用例。Struts適合于用例驅動的特點使其成為Admin Console的最佳開發框架。Tomcat的Admin Console就是一個用Struts實現最佳例證。
2. Turbine
同為Web應用開發框架Turbine并沒有Struts那么流行，但這并不說明Turbine沒有Struts那樣成功。同樣體現了MVC思想，但是Turbine和Struts的原理不同。
- 首先，Turbine是基于Servlet的，Struts是基于JSP的。
- 其次，Turbine是面向服務的，Struts是面向用例的。
- 還有，Turbine在Web頁面布局方面更加靈活，Struts則在配置上相對簡單。
綜合這些不同點可以得出這樣一個結論，Turbine更適合于開發軟件產品，而Struts更適合開發軟件項目。在我的方案中使用Turbine作為Portal的開發框架處于如下考慮：
- Turbine的SOA特性。在開發時可以使用Turbine內置的多個服務，比如Security Service，Cache Service等。Turbine現在自帶25種服務，而且這些服務是可插拔，可替換，可配置的。
- Turbine的靈活的界面布局方案。
圖5(來源apache.org)
圖6 Turbine把整個框架分為五個模塊，Action，Layout，Navigation，Screen，Page。除了Action外其他四個模塊和頁面布局息息相關，他們類似于WLP中的Shell，Book，Page，Menu等組件，JetSpeed以Turbine為開發框架就是為了利用這一特點。
- Turbine易于和Velocity，Cocoon結合的特性。其中Velocity是Turbine推薦的模版語言。
3. Cocoon
Cocoon是一個基于XML的內容發布引擎。Cocoon把以XML格式存儲的內容經過XSL解析成各種表現形式，如HTML,WML,PDF等。Cocoon利用管道機制把這個過程分解成離散的步驟，用SAX事件作為這些步驟之間的連接。
Cocoon的另一個特性就是信息的內容和表現分離的理念。把信息的內容存儲在XML中便于交換和處理，把表現存儲于XSL文件中便于設計和更改。內容和表現之間可以按照需要組合，Cocoon負責把他們合成并發布給用戶。
通過在整個Portal范圍使用Cocoon而不是像WLP那樣由netuix實現用戶界面，可以使Portal的面向XML特性更純。實踐也證明Cocoon2完全可以承擔較大吞吐量的界面發布任務。
4. Velocity
Velocity和JSP,ASP,PHP一樣是一種模版語言。但是Velocity只允許用來控制表現不能表達復雜的業務邏輯，所以我管它叫強模版語言。Velocity的另外一個特點就是簡單易學，就拿他的指令來說，總共只有7條。簡單易學的特性就為用戶自己訂制模版提供了先決條件，可以做到用戶自定義的界面個性化，而不是開發人員和管理員為用戶提供的可選擇的有限模版。
5. Pluto
Pluto是Apache Portal項目的子項目，其目標是成為一個符合JSR168標準的Portlet容器的參考實現(Reference Implementation)。就像Tomcat是Servlet容器的參考實現一樣。Pluto也具有面向方面的特性，很容易和已有的服務集成。建議在Portal產品研發早期沒有必要使用Pluto來支持JSR168，這樣會增加開發的難度。何時可以采用Pluto需要根據情況判斷，一般在Portal產品開發的中后期以迭代的方式加入。
學習和使用開源項目無論對于軟件開發人員的自身能力的提高還是軟件項目或產品研發來說都是一種捷徑。但是在這條捷徑上不少人還會存在以下兩點疑惑。首先，對于某一個開源項目來說，是完全照搬還是只利用一部分然后在此基礎上改造，是只借鑒其設計思想然后自己重新開發還是完全使用它的代碼。其次，對于只有多個開源項目結合才能滿足需求的情況，如何使這些開源項目能夠順暢的整合在一起。本文沒有建議使用JetSpeed，而是使用了Turbine +Cocoon +Velocity的組合方案。為什么這樣做，以及如何發揮這種組合的優勢就需要讀者通過實踐自己去尋找答案了。