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的组合方案。为什么这样做，以及如何发挥这种组合的优势就需要读者通过实践自己去寻找答案了。