几种开源Portal的简单介绍分析
几种开源Portal的简单介绍分析
一、
网上关于几个开源
portal
框架的一些评测
1
、评测的一些标准
每个开源框架都有其优点和缺点，如果没有一套全面的标准来评价，很难说清楚哪个框架更好。其实从做项目的观点出发，没有最好的技术，只有最适合的技术。但我们一般都会在选择某项技术的时候，尽可能的追求功能完善，易于开发和扩展，文档全面等等。下面是一些相关的标准：
1)
遵循
JSR168
规范
这是这些标准中最重要的一个要求，对规范支持得好，意味着做到很好的重用和别的
Portal
产品的交互等。
2)
便于安装
包括数据库的配置以及在
web
应用服务器中的发布等。
3)
文档
是否有详细的安装文档，开发文档和用户手册等。
4)
在线支持
包括开发社区，
Wiki
，邮件列表等，当使用
Portal
产品遇到问题时是否能快捷的寻找到解决问题的方法。
5) Potal
管理
包括管理节目是否友好，方便，易于添加用户管理，角色管理，分类管理，布局，皮肤管理，增加和删除
portlets
等等。
6) portlet
资源库
一般
portal
框架都能附带的发布一些可被重用的
portlets
。例如邮件
portlet
，日程表
portlet
，搜索
portlet
等等。这里我们主要的评价标准是这些
portlets
是否能被很好的复用。
7)
性能
包括
portal
框架的启动时间，
portlet
的装载时间，数据库的访问时间等等。
8)
安全
很多
portal
框架都有默认的安全机制，但默认的认证和授权机制远远不能满足某些大项目的要求。在这里，主要考虑
portal
框架是否能够很好的和
JAAS
，
SSO
，
SSL
等安全技术整合以及整合的难易程度等。
9)
技术
不同的
portal
框架基于不同的技术开发，同时可能要求
portlet
开发人员也使用同样的技术，例如
Struts
，
JSF
，
Spring
，
Hibernate
，
Tiles
，
EJB
以及
Web services
等技术。
10) Portal
特性
通常情况下
Portal
框架除了作为一个
portal/portlet
容器外，还附带一些很有用的特性，例如内容管理系统（
CMS
），工作流（
Workflow
），管理工具，监控工具等。
11)
服务器兼容性
此标准主要检验
portal
框架是否能够很好的运行在大部分的服务器中，包括
Tomcat
，
JBoss
，
Weblogic
，
Websphere
等主力的服务器。
12)
对
The Web Services for Remote Portlets(WSRP)
规范的支持。
2
、被评测的框架：
Sakai 1.5
（广泛的用于
Virtual Research Environment(VRE)
领域）
uPortal
（广泛的用于
Academic Institutes work
领域）
GridSphere
（第一个支持
JSR168
规范的开源
portal
框架）
eXo
平台（当前非常流行）
Liferay
（当前非常流行，良好的用户界面以及丰富的内建
portlets
）
StringBeans
（非常易用）
下面将基于上面的评价标准，仔细的给每个开源
Portal
框架打分，
1~5
分，其中
5
分是满分，最后统计总分，见表：
|
标准
|
Portal
框架
|
|||||
|
|
Sakai
1.5
|
uPortal
|
GridSphere
|
eXo
平台
|
Liferay
|
StringBeans
|
|
遵循
JSR168
规范
|
0
|
5
|
5
|
5
|
5
|
5
|
|
便于安装
|
3
|
5
|
5
|
5
|
5
|
5
|
|
文档
|
2
|
2
|
4
|
3
|
3
|
5
|
|
在线支持
|
3
|
3
|
4
|
4
|
3
|
5
|
|
Potal
管理
|
3
|
5
|
4
|
5
|
4
|
5
|
|
自定义
|
4
|
3
|
4
|
3
|
5
|
4
|
|
portlet
资源库
|
4
|
3
|
4
|
3
|
5
|
3
|
|
性能
|
2
|
4
|
3
|
4
|
3
|
3
|
|
安全
|
3
|
4
|
3
|
4
|
4
|
4
|
|
技术
|
3
|
3
|
4
|
5
|
4
|
3
|
|
Portal
特性
|
2
|
2
|
3
|
5
|
4
|
2
|
|
服务器兼容性
|
3
|
3
|
3
|
4
|
5
|
3
|
|
WSRP
标准
|
0
|
3
|
0
|
3
|
3
|
0
|
|
合计
|
35
|
49
|
51
|
57
|
58
|
51
|
二、
Pluto
，
Liferay
，
eXo,Jetspeed
四种开源
Portal
的介绍和分析，有助于对具体项目选择合适的开发平台。
（
1
）
Pluto
2003 年 10 月 JSR168 规范 1.0 正式公布后， Jakarta Apache 就开始实施 Pluto 计划（冥王星计划），最终开发出该规范的一个参考实现（ Reference Implementation ），即 Pluto 。 Pluto 的 1.0.1 -rc2 版与 2004 年 12 月发布。
Pluto 实现基于 JSR168 的一个 Portlet Container ，相当于为开发者提供了一个运行 portlets 的工作平台。 Pluto 本身也提供了一个简单的 Portal 模块，该模块仅仅是为了满足 Portlet 容器和 JSR 168 的需要而写的，因而显得非常简单，提供的实用的 Portlet 也非常少。从某种意义上说 Pluto 更像是一个 Portlet Container ，作为一个实用的 Portal 开发框架尚需要更强大的支持。但新版本的 Pluto 仍没有推出。对于 Pluto 的应用开发， Apache 更推荐使用 Jetspeed 项目框架。
尽管 Pluto 作为一个完整的 Portal 应用还非常欠缺。但不少有影响力的 Portal 项目使用 Pluto 作为 Portlet Container 。这些项目包括： Jetspeed 、 Cocoon uPortal 、 Jahia 等。由此可见 Pluto 的重要性。从开发者和学习者的角度看， Pluto 的意义还在于为开发者和学习者提供了一个深入了解 Portlet Container 的简洁的参考实例。
（ 2 ） Liferay
Liferay （支持 JSR168 ）代表了完整的 J2EE 应用 ，最高版本是 2005 年 1 月推出的 Professional 3.2.0 。它的主要优点有：
（ 1 ）使用第三放的开源项目，如 Hibernate 等。特别是前台界面部分使用了 Struts 技术；
（ 2 ）支持包括中文在内的多种语言；
（ 3 ）支持较多的先进技术，如 Web Services 、 EJB, JMS, SOAP, XML 等；
Liferay 的缺点是它缺乏一个简单清晰可拓展的架构设计，整个架构比较复杂且庞大； Struts1.1 本身并不支持 JSR168 ，所以 Liferay 在实现诸如上下文共享等问题上显得十分笨重且没有从根本上解决这些问题； portlet 设计也显得比较凌乱。此外，如果你的门户系统准备应用于商业用途，你需要购买 License 。基于它进行二次开发比较困难。
（ 3 ） eXo
eXo( 支持 JSR168) 基于 JSF 的 Portal 实现。最新版本是 2004 年 10 月发布的 1.0RC1 版。
主要优点包括：
（ 1 ） 由 AOP （ AspectJ ）实现的内容管理系统，极大提高了内容管理性能；
（ 2 ） 基于 Pico Container 的 Portlet Container ， Pico 是一个著名的 IoC3 轻量级容器。同时也实现了上下文共享，二次开发的流程比较清晰；
（ 3 ） 使用 Struts 框架技术；
（ 4 ） 提供工作流技术服务（ Workflow service ）。
（ 5 ） 提供了很多交流工具，通过 XML 可以为结构化的信息轻易地创建视图；
由上可见 eXo 采用了诸多先进技术，但存在不少缺点。主要缺点：由于 Portal Server 本身的数据是使用 xmldb 来进行处理，保存到数据库的数据都是乱码而且它所有默认的平台字符集都是 ISO-8859_1 。缺乏中文的充分支持，对于中文门户的开发并没有优势；由于 JSF 是重量级的表现层框架，使得 exo 的二次开发工作量比较大；对于商业 Portal 应用开发需要购买 License 。总体开发难度较大。
2003 年 10 月 JSR168 规范 1.0 正式公布后， Jakarta Apache 就开始实施 Pluto 计划（冥王星计划），最终开发出该规范的一个参考实现（ Reference Implementation ），即 Pluto 。 Pluto 的 1.0.1 -rc2 版与 2004 年 12 月发布。
Pluto 实现基于 JSR168 的一个 Portlet Container ，相当于为开发者提供了一个运行 portlets 的工作平台。 Pluto 本身也提供了一个简单的 Portal 模块，该模块仅仅是为了满足 Portlet 容器和 JSR 168 的需要而写的，因而显得非常简单，提供的实用的 Portlet 也非常少。从某种意义上说 Pluto 更像是一个 Portlet Container ，作为一个实用的 Portal 开发框架尚需要更强大的支持。但新版本的 Pluto 仍没有推出。对于 Pluto 的应用开发， Apache 更推荐使用 Jetspeed 项目框架。
尽管 Pluto 作为一个完整的 Portal 应用还非常欠缺。但不少有影响力的 Portal 项目使用 Pluto 作为 Portlet Container 。这些项目包括： Jetspeed 、 Cocoon uPortal 、 Jahia 等。由此可见 Pluto 的重要性。从开发者和学习者的角度看， Pluto 的意义还在于为开发者和学习者提供了一个深入了解 Portlet Container 的简洁的参考实例。
（ 2 ） Liferay
Liferay （支持 JSR168 ）代表了完整的 J2EE 应用 ，最高版本是 2005 年 1 月推出的 Professional 3.2.0 。它的主要优点有：
（ 1 ）使用第三放的开源项目，如 Hibernate 等。特别是前台界面部分使用了 Struts 技术；
（ 2 ）支持包括中文在内的多种语言；
（ 3 ）支持较多的先进技术，如 Web Services 、 EJB, JMS, SOAP, XML 等；
Liferay 的缺点是它缺乏一个简单清晰可拓展的架构设计，整个架构比较复杂且庞大； Struts1.1 本身并不支持 JSR168 ，所以 Liferay 在实现诸如上下文共享等问题上显得十分笨重且没有从根本上解决这些问题； portlet 设计也显得比较凌乱。此外，如果你的门户系统准备应用于商业用途，你需要购买 License 。基于它进行二次开发比较困难。
（ 3 ） eXo
eXo( 支持 JSR168) 基于 JSF 的 Portal 实现。最新版本是 2004 年 10 月发布的 1.0RC1 版。
主要优点包括：
（ 1 ） 由 AOP （ AspectJ ）实现的内容管理系统，极大提高了内容管理性能；
（ 2 ） 基于 Pico Container 的 Portlet Container ， Pico 是一个著名的 IoC3 轻量级容器。同时也实现了上下文共享，二次开发的流程比较清晰；
（ 3 ） 使用 Struts 框架技术；
（ 4 ） 提供工作流技术服务（ Workflow service ）。
（ 5 ） 提供了很多交流工具，通过 XML 可以为结构化的信息轻易地创建视图；
由上可见 eXo 采用了诸多先进技术，但存在不少缺点。主要缺点：由于 Portal Server 本身的数据是使用 xmldb 来进行处理，保存到数据库的数据都是乱码而且它所有默认的平台字符集都是 ISO-8859_1 。缺乏中文的充分支持，对于中文门户的开发并没有优势；由于 JSF 是重量级的表现层框架，使得 exo 的二次开发工作量比较大；对于商业 Portal 应用开发需要购买 License 。总体开发难度较大。
(4) Liferay
与
exo
比较：
liferay
的表现层是基于
Struts
，而
exo
是基于
jsf
。
struts1.1
并不能真正支持
jsr168
，虽然
liferay
对此进行了一些改造，但是实际上并不能真正支持
jsr168
规范（如上下文的共享，在
liferay
里的机制很复杂，而且也很牵强，并不能从根本上实现上下文共享和
wsrp
规范），而
jsf
本是就是支持
jsr168
规范的框架，实现了应用之间的上下文共享，所以没有这方面的问题。此外
liferay
的架构比较混乱，基于它进行二次开发很困难（我以前做过
liferay
的二次开发工作，对于在这方面有问题的朋友可以和我聊聊）。
exo
由于采用了
picoContainer
，也实现了上下文共享，所以二次开发的流程很清晰。不过由于
jsf
是重量级的表现层框架，使得
exo
的二次开发工作量比较大。
exo
的中文问题没有解决，主要原因有两个：
Portal Server
本身的数据是使用
xmldb
来进行处理，保存到数据库的数据都是乱码；它所有默认的平台字符集都是
ISO-8859_1
。你可以把区域的选项设成是
sp
（西班牙？？）等区域，
cn
是不可用的，这样平台的字符集就是
utf-8
了。
exo
目标设计很大，其中使用
PicoContainer
管理其
Service
，值得借鉴。使用
PicoContainer
的一个麻烦处是系统启动时将配置文件的
service
都载入，
exo
采取的是捆绑
JBoss
的
war
部署包，也就是说，
war
包一旦在
JBoss
部署，将启动
PicoCOntainer
的初始化配置，个人觉得这样兼容性不够。
(5) JetSpeed
JetSpeed 是 Apache 组织的开源 Portal 项目。 Jetspeed 目前有两个版本可供选择 1.X 和 2.0 版本。 Jetspeed1.X 出现得比较早，但第一个较为成熟的版本发布是 1.4 。此后 1.X 不断推出新版本。但 Jetspeed1.X 都不支持 JSR168 。当 JSR168 在 2003 年发布后， Apche 开始开发 Jetspeed2 ，提供对 JSR168 的全面支持。
下表是 Jetspeed 重要版本的发布日期：
Jetspeed 的重要版本 发布日期
Jetspeed-1.4b2 2002 年 12 月
Jetspeed-1.5 2004 年 4 月
Jetspeed-2.0-M1 2004 年 12 月
Jetspeed-2.0-M2 2005 年 4 月
Jetspeed1.X 基于 Turbine 框架开发，它提供了丰富的 Portal 技术功能。主要优点有： XML 文件注册 Portlet ，便于管理；图形化的部署和卸载；对中文的良好支持等。值得注意的是 IBM 早期的 WebSphere Portal Server 就是在 JetSpeed1.X 上进行二次开发的。 Jetspeed2.0 在 1.X 基础上进行了较大的改动，功能更加丰富，完全遵循 JSR 标准。
配置方法，不同的版本的配置可能有变化，如不成功，可以自行察看文档。
Pulto 在 Tomcat 下的安装配置方法：
（ 1 ） 从 http://portals.apache.org/pluto/mirrors.cgi 下载最新的二进制版本安装文件
（ 2 ） 执行 %pluto%/bin/install ，将它安装到 Tomcat 目录下即可
（ 3 ） 在浏览器中输入： http://localhost:8080/pluto/portal ，运行 Pluto
Liferay Professional 在 Tomcat 下的安装配置方法：
（ 1 ） 从 http://www.liferay.com/downloads/index.jsp 下载 Liferay Professional 安装文件；
（ 2 ） 解压 ZIP 包到某个目录下
（ 3 ） 若下载 Tomcat 版本的 Liferay 安装文件，则不需再装 Tomcat ，直接启动 bin 目录下的 startup.bat 文件。
（ 4 ） 在浏览器中输入 http://localhost/ 运行 Liferay Professional 。
eXo Platform 在 Tomcat 下的安装配置方法：
（ 1 ） 从 http://www.exoplatform.com/portal/faces/public/exo 下载 eXo Platform 的安装包。
（ 2 ） 解压 ZIP 包到某个目录下
（ 3 ） 若下载 Tomcat 版本的 eXo 安装文件，则不需再装 Tomcat ，直接启动 bin 目录下的 startup.bat 文件。
（ 4 ） 在浏览器中输入 http://localhost/ 运行 eXo Platform.
Jetspeed2 在 Tomcat 下的安装配置方法：
（ 1 ） 从 http://www.apache.org/dist/portals/jetspeed-2/ 下载 Jetspeed2 M1 或 M2 版本安装包。
（ 2 ） 若是安装包中已经捆绑 Tomcat ，解压即可。若安装包不含 Tomcat ，先安装 Tomcat ，然后将安装包解压到 Tomcat 目录，并覆盖相关文件即可。
（ 3 ） 安装要注意的问题有： Jetspeed2M1 版本由于 Bug 无法安装 Tomcat5.5 上（此 BUG 见 http://issues.apache.org/jira/browse/JS2-187 ）； Jetspeed2 必须安装在 Tomcat5.0.28 以上版本上，否则低版本由于 JAAS 问题无法登陆；
（ 4 ） 启动 jetspeed-database 目录下的 start-database.bat ，启动数据库；
（ 5 ） 启动 Tomcat ；
（ 6 ） 在浏览器中输入 http://localhost:8080/jetspeed/portal 运行 Jetspeed ；