kapok

作者：陳龍 （dev2dev ID：SCEA）

文章摘要

Weblogic Portal(以下簡稱WLP) 的設(shè)計思想有許多先進之處，而其中最重要的思想都凝聚在充分發(fā)揮XML的作用和面向服務(wù)的架構(gòu)(SOA)上。本文將用藍圖的形式向你展示WLP的整體架構(gòu)，并詳細介紹XOA(XML-Oriented Architecture,我發(fā)明的概念)和SOA。

在分析完WLP的架構(gòu)之后，將向大家介紹一下我用開源項目對這個架構(gòu)的模擬方案，這套方案有利于讀者掌握 WLP，也有利于深入理解Portal的概念，并且可以作為自己Portal產(chǎn)品開發(fā)的參考。需要強調(diào)的是本文不會向你介紹某一個著名的開源項目，如JetSpeed，而是為大家提供一種由多個開源項目組合而成的全套開源解決方案。你可以把這套方案看作是WLP的開源版本，方案本身沒有過多革新之處，僅有一處改進，所以這套方案是The WLP Reloaded，并非The WLP Revolutions。

目錄：

Weblogic Portal 的架構(gòu)分析和我的開源實現(xiàn)方案...

WLP的藍圖...

走進Portal，一切都是XML.

面向服務(wù)的架構(gòu)...

WLP藍圖的開源實現(xiàn)方案...

分塊描述...

總結(jié)...

WLP的藍圖

WLP支持包括設(shè)計，開發(fā)，配置，管理，測時，運行在內(nèi)的整個Portal生命周期。它由三大模塊組成：Weblogic Workshop Portal Extension，Weblogic Portal Admin Console，Weblogic Portal Server，這些模塊的關(guān)系見下圖：

圖1

藍圖可以分為三大區(qū)域：底層基礎(chǔ)結(jié)構(gòu)(灰色區(qū)域)，產(chǎn)品模塊(黃色區(qū)域)，外部應(yīng)用、數(shù)據(jù)、資源(藍色區(qū)域)。需要注意的是Weblogic Portal Admin Console其實是一個Portal應(yīng)用的特例，和你將要開發(fā)的Portal一樣其本身就是一個Portal。

圖形的嵌套說明兩者的包含和被包含關(guān)系。但是如果被包含的子？槿綣脅糠窒月對詬改？櫓猓蛩得髯幽？槭歉改？櫚氖涑鱟榧幣彩竅嗔諂淥？櫚氖淙胱榧?/span>

類似于坐標(biāo)系統(tǒng)，每個單元模塊在結(jié)構(gòu)圖中的相對位置有著不同的含義。自下向上，底層模塊是上層模塊的基礎(chǔ)和平臺，底層模塊為上層模塊提供服務(wù)和組件管理。上層結(jié)構(gòu)代表可視和具體，下層結(jié)構(gòu)代表透明和抽象。自左向右，左側(cè)模塊為右側(cè)模塊提供可用組件，右側(cè)模塊沒有左側(cè)模塊的工作成果就沒有意義，同時也是項目實施的作業(yè)順序。

寬箭頭代表XML數(shù)據(jù)流，細箭頭代表用戶屬性信息。從同中可以看出，XML數(shù)據(jù)是產(chǎn)品模塊間的主要數(shù)據(jù)流形勢，伴隨有少量用戶信息數(shù)據(jù)。所有的組件定義都由XML文檔表示和配置。

在圖中，紅色邊框部分是對WLP單點登錄方案的補充解釋，具體的文字說明請參見《BEA Weblogic Portal項目實施解決方案集》一文的相關(guān)部分。

WLP整體架構(gòu)中蘊藏的兩大設(shè)計理念分別時面向XML的架構(gòu)和面向服務(wù)的架構(gòu)，XOA應(yīng)用于Portal extension中，SOA應(yīng)用于整個Weblogic Platform。正是這兩點保證了WLP具有豐富靈活的界面表現(xiàn)和強大的服務(wù)整合能力。下面兩節(jié)是對這兩點的詳細說明。

走進Portal，一切都是XML

還記得《Thinking in Java》一書中有一節(jié)的標(biāo)題是Everything is an object，那么現(xiàn)在可以說在WLP中一切都是XML，叫Everything is an XML file in the Weblogic Portal World。在我還不太了解WLP的時候認為WLP是基于XML技術(shù)的，但是隨著對WLP的深入理解，一種更深的觸動隨之產(chǎn)生了，原來WLP是面向XML的，它已超越了面向?qū)ο蠛突?/SPAN>XML這兩層含義。在WLP中的Portal組件有Portal，Shell，Look & Feel，Skeleton，Book，Menu，Page，Layout，Portlet，UUP等，這些組件都是Portal的基石，在這里開頭字母大寫說明他們等同于面向?qū)ο笳Z言中的類，當(dāng)Portal設(shè)計完成處于運行階段時(Runtime)，系統(tǒng)會為每個用戶生成這些類的對象。

WLP設(shè)計的精美之處就在于對這些XML的處理。無疑Portal這個類是最重要的，它包含的信息類似Java語言中的Main方法，Portal的生成及界面的展現(xiàn)都從這里開始，它是Portal的Portal（入口的入口）。我們可以把在Portal設(shè)計階段由Workshop生成的這些組件稱為基礎(chǔ)Portal類（Portal Foundation Class）。Workshop起到了面向XML的可視化集成開發(fā)環(huán)境的作用。

基礎(chǔ)Portal類作為Workshop的成果輸出給Weblogic Portal，并且在Weblogic Portal admin Console中可以對它們進行配置和管理。Admin Console把這些基礎(chǔ)類作為Library看待，管理員配置的Portal和Desktop等都是Library中的基礎(chǔ)類的組合或變體。我們可以把在Portal設(shè)計階段由Admin Console生成的這些組件稱為用戶Portal類（Portal Customer Class）。這是的類已經(jīng)不是XML文件形式的了，而是以二維表格的形式存儲在關(guān)系型數(shù)據(jù)庫中，面向XML的思想到此終結(jié)。我個人認為沒有必要這樣做，應(yīng)該沿用XML文件形式。首先，在實際使用當(dāng)中會發(fā)現(xiàn)用戶Portal類其實還是起到組件定義的作用，只是這類組件更接近用戶，攜帶更多的個性化參數(shù)，數(shù)據(jù)量和用戶數(shù)量沒有必然聯(lián)系，不會隨著用戶數(shù)量的增加而增加。其次，如果采用XML文件形式，在界面展現(xiàn)時還可以采用靈活的XSLT方式，而沒必要自己實現(xiàn)另外一套用戶界面機制(netuix)。對這一部分的改進方案在開源替代方案中作進一步說明。

面向服務(wù)的架構(gòu)

除了用XML定義Portal組件體現(xiàn)了WLP面向XML的特性之外，在內(nèi)容和應(yīng)用整合方面WLP也利用了XML。如果僅僅是內(nèi)容的整合，可以利用RSS。如果還需要整合應(yīng)用，就利用WSRP(Web Services for Remote Portlets)。然而在整合這個問題上另外一種情況是不可避免的，那就是如何整合多個Portal成為一個統(tǒng)一Portal架構(gòu)(Unified Portal Architecture)。統(tǒng)一的Portal意味著統(tǒng)一的安全機制，一致的用戶界面等等相關(guān)問題。

為了解決上述問題，BEA在原有Weblogic Platform的基礎(chǔ)上進一步提出SOA驅(qū)動的Portal(SOA driven Portal)概念。BEA最近的一份白皮書中這樣說：“為了創(chuàng)造一個為所有用戶服務(wù)的單一Portal環(huán)境，就必須使用面向服務(wù)的架構(gòu)”。

拿統(tǒng)一的安全機制來說，Security是Weblogic Server為整個Weblogic Platform提供的一個通用服務(wù)，在Weblogic Platform之上開發(fā)的所有應(yīng)用都可以共享這個服務(wù)。由于每個應(yīng)用不必自己實現(xiàn)安全機制，不但節(jié)省了開發(fā)成本還為Portal實現(xiàn)單點登陸提供了可能(如何實現(xiàn)WLP的單點登陸請看《BEA Weblogic Portal項目實施解決方案集》一文的相關(guān)部分)。

SOA正在受到越來越多的軟件企業(yè)和開發(fā)人員的關(guān)注，IBM, Borland, Oracle紛紛公布了自己的SOA計劃，微軟也認為面向服務(wù)的架構(gòu)將超越面向?qū)ο蟮木幊煞椒?/SPAN>(The world of service-oriented architectures (SOA) will eclipse object-oriented programming)。無論MDA,AOP還是SOA都是一種軟件開發(fā)的思維模式，他們都告訴我們一點：不要只考慮對象，而是要把更多的精力用在考慮更宏觀的事物上，如模型，方面，服務(wù)。

WLP藍圖的開源實現(xiàn)方案

基于上述對WLP的分析，尤其是對面向XML和面向服務(wù)的架構(gòu)的剖析，現(xiàn)在給出我的開源項目實現(xiàn)方案。這個開源項目放案的重點還是XOA和SOA。見下圖：

圖2

該圖的結(jié)構(gòu)說明和圖1基本一致，兩幅圖的單元模塊之間存在影射關(guān)系，但是為了表達的更加準(zhǔn)確增加了圖例。另外要注意，相鄰的兩個單元模塊，如果邊界接觸就說明兩者之間的關(guān)系為緊耦合，如果存在間隙則說明是松耦合。緊耦合意味著上層模塊對下層模塊的依賴，下層模塊對上層模塊的不可或缺，松耦合意味著可替換，可不用。

這個開源解的解決方案中的開源項目主要來自兩大開源組織，Apache 和Eclipse。Apache的項目有:Struts, Turbine, Cocoon, Velocity, Pluto。這部分和SOA相關(guān)。

Eclipse的項目則主要集中在Eclipse Project和Eclipse Tools Project子項目中關(guān)于可視化圖形用戶界面部分。主要有SWT，GEF，EMF，VE。這部分和XOA相關(guān)。

分塊描述

* Eclipse部分

Eclipse是IBM發(fā)起成立的一個開源組織。在屢次和SUN爭奪Java標(biāo)準(zhǔn)控制權(quán)沒有如愿后，不難看出IBM要用Eclipse達到兩個目的，也是兩個標(biāo)準(zhǔn)。其一就是建立軟件集成開發(fā)環(huán)境的標(biāo)準(zhǔn)，不僅僅是Java的集成開發(fā)環(huán)境，而且也可以是C++的集成開發(fā)環(huán)境。用Eclipse作為開發(fā)環(huán)境的最大特點就是可視化，這一特點得益于Eclipse的優(yōu)秀的可視化組件技術(shù)SWT以及基于SWT之上的其他可視化編輯技術(shù)。其二就是面向方面的編成(AOP)標(biāo)準(zhǔn)，這一點不是本文要討論的。由于Eclipse平臺是以IBM捐獻的部分WebSphere Visual Age 系列開發(fā)工具的源碼為基礎(chǔ)發(fā)展而來的，所以Eclipse繼承了很多Visual Age的優(yōu)秀思想和成果，如Workbench和Workspace映射等。我之所以要用Eclipse代替Workshop完成Portal的可視化設(shè)計任務(wù)就是因為Eclipse的這個思想。

圖3 Eclipse的架構(gòu)

下面分別對各個部分進行簡要說明：

1.         SWT

SWT(Standard Widget Toolkit)，是類似AWT/Swing的可視化組件，但是他和AWT/Swing的實現(xiàn)機制不同。Swing是完全是通過模擬不同操作系統(tǒng)上的可視化組件表現(xiàn)風(fēng)格實現(xiàn)不同的Look & Feel的。而SWT則是先調(diào)用本地操作系統(tǒng)的可視化組件，如果本地操作系統(tǒng)沒有這種組件才去模擬，單是無論采取那種方式，SWT給開發(fā)人員提供統(tǒng)一的API。SWT這樣做的優(yōu)點是簡單，小巧，運行速度快，既和操作系統(tǒng)緊密結(jié)合又可在不同操作系統(tǒng)只見自由移植。SWT被Java Developer’s Journal評為最佳 Java組件，所以使用SWT不僅能夠開發(fā)出正宗的本地Look & Feel，還能學(xué)習(xí)到其最佳的設(shè)計思想。

2.         GEF

GEF(Graphical Editing Framework)，可以為一個應(yīng)用模型創(chuàng)建圖形編輯器。例如有一個設(shè)計數(shù)字電路的軟件，所有的電路組件和設(shè)計方案都以XML格式保存，現(xiàn)在需要一個圖像化的設(shè)計器使設(shè)計更直觀。用GEF就可以對這個應(yīng)用模型構(gòu)建圖形編輯器，如下圖：

圖4 (來源Eclipse.org)

如果應(yīng)用模型換成Portal，那么同樣可以用GEF做一個類似的圖形編輯器。

3.         EMF

EMF(Eclipse Modeling Framework )，可以把模型轉(zhuǎn)化為Java代碼或者XML文檔，也就是代碼生成。EMF被廣泛的應(yīng)用在MDA中，作為從UML到代碼只見的轉(zhuǎn)換工具。在我的方案中EMF負責(zé)把可視化的Portal組件模型轉(zhuǎn)化成為XML文檔。

4.         VE

VE(Visual Editor)，是一個基于EMF的圖形用戶界面開發(fā)框架，是一個GUI的組裝器。用戶對由VE生成的可視化工具實行可視化操作(拖拽等)時，對應(yīng)的Workspace中的Java和XML等文檔會發(fā)生相應(yīng)改變，反之亦然。

* Apache部分

Apache是最著名的開源組織，隸屬于Apache軟件基金會(ASF)。Apache中的大部分項目都是開源世界的典范。下面介紹的內(nèi)容都可以在apache.org上找到更多資料。

1.         Struts

Struts作為基于JSP的Web應(yīng)用框架已被國內(nèi)不少開發(fā)團隊接受。Struts的特點是開發(fā)迅速，配置簡單，可以有多個人分別實現(xiàn)不同用例然后再通過配置文件合并這些用例。Struts適合于用例驅(qū)動的特點使其成為Admin Console的最佳開發(fā)框架。Tomcat的Admin Console就是一個用Struts實現(xiàn)最佳例證。

2.         Turbine

同為Web應(yīng)用開發(fā)框架Turbine并沒有Struts那么流行，但這并不說明Turbine沒有Struts那樣成功。同樣體現(xiàn)了MVC思想，但是Turbine和Struts的原理不同。

• 首先，Turbine是基于Servlet的，Struts是基于JSP的。
• 其次，Turbine是面向服務(wù)的，Struts是面向用例的。
• 還有，Turbine在Web頁面布局方面更加靈活，Struts則在配置上相對簡單。

綜合這些不同點可以得出這樣一個結(jié)論，Turbine更適合于開發(fā)軟件產(chǎn)品，而Struts更適合開發(fā)軟件項目。在我的方案中使用Turbine作為Portal的開發(fā)框架處于如下考慮：

• Turbine的SOA特性。在開發(fā)時可以使用Turbine內(nèi)置的多個服務(wù)，比如Security Service，Cache Service等。Turbine現(xiàn)在自帶25種服務(wù)，而且這些服務(wù)是可插拔，可替換，可配置的。
• Turbine的靈活的界面布局方案。
  
  圖5(來源apache.org)
  
  
  圖6 Turbine把整個框架分為五個模塊，Action，Layout，Navigation，Screen，Page。除了Action外其他四個模塊和頁面布局息息相關(guān)，他們類似于WLP中的Shell，Book，Page，Menu等組件，JetSpeed以Turbine為開發(fā)框架就是為了利用這一特點。
• Turbine易于和Velocity，Cocoon結(jié)合的特性。其中Velocity是Turbine推薦的模版語言。

3.         Cocoon

Cocoon是一個基于XML的內(nèi)容發(fā)布引擎。Cocoon把以XML格式存儲的內(nèi)容經(jīng)過XSL解析成各種表現(xiàn)形式，如HTML,WML,PDF等。Cocoon利用管道機制把這個過程分解成離散的步驟，用SAX事件作為這些步驟之間的連接。

Cocoon的另一個特性就是信息的內(nèi)容和表現(xiàn)分離的理念。把信息的內(nèi)容存儲在XML中便于交換和處理，把表現(xiàn)存儲于XSL文件中便于設(shè)計和更改。內(nèi)容和表現(xiàn)之間可以按照需要組合，Cocoon負責(zé)把他們合成并發(fā)布給用戶。

通過在整個Portal范圍使用Cocoon而不是像WLP那樣由netuix實現(xiàn)用戶界面，可以使Portal的面向XML特性更純。實踐也證明Cocoon2完全可以承擔(dān)較大吞吐量的界面發(fā)布任務(wù)。

4.         Velocity

Velocity和JSP,ASP,PHP一樣是一種模版語言。但是Velocity只允許用來控制表現(xiàn)不能表達復(fù)雜的業(yè)務(wù)邏輯，所以我管它叫強模版語言。Velocity的另外一個特點就是簡單易學(xué)，就拿他的指令來說，總共只有7條。簡單易學(xué)的特性就為用戶自己訂制模版提供了先決條件，可以做到用戶自定義的界面?zhèn)€性化，而不是開發(fā)人員和管理員為用戶提供的可選擇的有限模版。

5.         Pluto

Pluto是Apache Portal項目的子項目，其目標(biāo)是成為一個符合JSR168標(biāo)準(zhǔn)的Portlet容器的參考實現(xiàn)(Reference Implementation)。就像Tomcat是Servlet容器的參考實現(xiàn)一樣。Pluto也具有面向方面的特性，很容易和已有的服務(wù)集成。建議在Portal產(chǎn)品研發(fā)早期沒有必要使用Pluto來支持JSR168，這樣會增加開發(fā)的難度。何時可以采用Pluto需要根據(jù)情況判斷，一般在Portal產(chǎn)品開發(fā)的中后期以迭代的方式加入。

總結(jié)

學(xué)習(xí)和使用開源項目無論對于軟件開發(fā)人員的自身能力的提高還是軟件項目或產(chǎn)品研發(fā)來說都是一種捷徑。但是在這條捷徑上不少人還會存在以下兩點疑惑。首先，對于某一個開源項目來說，是完全照搬還是只利用一部分然后在此基礎(chǔ)上改造，是只借鑒其設(shè)計思想然后自己重新開發(fā)還是完全使用它的代碼。其次，對于只有多個開源項目結(jié)合才能滿足需求的情況，如何使這些開源項目能夠順暢的整合在一起。本文沒有建議使用JetSpeed，而是使用了Turbine +Cocoon +Velocity的組合方案。為什么這樣做，以及如何發(fā)揮這種組合的優(yōu)勢就需要讀者通過實踐自己去尋找答案了。