JSR168是Java 规范要求（Java Specification Request ，JSR）的缩写，它为创建Portlet建立标准的API。很多重量级的Portal开发商和开源项目组参与了Java标准化组织（Java Community Process）创建JSR168标准的过程，并且很多Portal产品开始支持JSR 168。JSR168在2003年10月正式发布。最主要的Portal开发商已经宣布计划支持JSR 168标准，查看JSR 168站点（http://www.jcp.org/en/jsr/detail?id=168 ）可以得到目前为止JSR 168支持者的完整列表。
Portal-门户
Portal 的组成可以分为三部份 (1) Portal Server (2) Portlet Container (3) Portlet
- Portal Server 的定义是
一个 Portal（门户网站）就是指一个 Web-based 的系统，通常都会提供个性化设置、单一登陆、以及由各种不同来源或不同网站取得各式各样的信息，并且将这些信息放在网页之中组合而成的呈现平台，门户网站会有精巧的个性化设置去提供定制的网页，当不同等级的使用者来浏览该页面将获得不同的信息内容
-
Portlet Container 的定义是
portlet container 是提供 portlets 运行时环境，包含了许多 portlets 并且管理他们的生命周期，并负责持久化portlets 的参数信息，一个 portlet container 接收到来自 portal 的请求后，接着将这个请求传递给存在 container 的 portlet 执行。portlet container 没有义务去组合 portlets 产生的信息內容，这个工作必须由 portal 来处理。portal 和 portlet container 可以放在一起视为同一个系统的组件，或者分开成为两个独立的组件。 -
Portlets
“Portlets是一种Web组件－就像servlets－是专为将合成页面里的内容聚集在一起而设计的。通常请求一个portal页面会引发多个portlets被调用。每个portlet都会生成标记段，并与别的portlets生成的标记段组合在一起嵌入到portal页面的标记内。”（摘自Portlet规范，JSR 168）
一个 Portlet 是以 Java 技术为技术的 Web 组件，由 Portlet Container 所管理，专门处理客户的 request 以及产生各种动态的信息内容。Portlets 为可插式 ( pluggable ) 的客户界面组件，提供呈现层成为一个信息系统。
这些由 portlet 产生的内容也被称为片段 (fragment)，而片段是具有一些规则的Markup( HTML、XHTML、WML )，而且可以和其他的片段组合而成一个复杂的文件。而 Portlet 中的内容正常来说是与其他 Portlet 的内容聚合而成为一个 Portal 网页。而 Portlet 的生命周期是被 Portlet Container 所管理控制的。
Java开源Portlet框架
（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。总体开发难度较大。
(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标准。
