Portlet 技术发展的思考

Portal这个概念出现很长的时间了，然而Portal应用是直到最近这两三年才蓬勃发展起来，这跟原来缺乏相关的规范有一定的关系。目前关于Portal方面存在两个重要的标准，均是2003年下半年正式通过的，分别为：
1、Java Portlet Specification 1.0 (JSR168), 2003年10月27日
2、Web Services for Remote Portlets 1.0, 2003年9月3日

这两个规范发布之后，得到各个Portal产商的支持，特别是JSR168标准更是得到OpenSource界的大力支持。许多开源项目都声称支持JSR168标准，具体项目列表可以参考：Open Source Portal in Java。

不过在对这些标准学习之后，我认识到除了实现一个支持标准的服务器之外，还有很多空间是值得我们去努力的。如果有人正在进行Portal方面的研究、实现，希望我的想法能够有所帮助。

Java Web Framework -> JSR168
我学习JSR168这个规范后，我就认识到开始一个JSR168 Portlet不会是一件愉快的事情。JSR168 Portlet十分类似于Servlet，现在还有谁愿意只是基于Servlet来开发Web应用呢？更进一步的问题是：开发人员需要直接编写JSR168 Portlet么？答案是不需要！

所谓Portlet本身来说就是一个Web应用，只是运行在Portal才被称为Portlet。业界已经有大量熟练的Java Web应用开发人员，让他们去重新学习一种新的Web应用模式、并且只能运行在在Portal中是不现实的，正确的方式应该是能够把普通的Java Web应用包装成JSR168 Portlet。这样开发人员依然按照原来的模式开发Web应用，只是在部署到Portal之前才包装成JSR168 Portlet。目前许多Java Web应用都是基于某些Web Framework（例如Struts）来实现，因此可以考虑基于这些Web Framework的包装方法。

对于这个包装器，我目前想到需要注意的地方有：
1、URL转换。Web应用中使用普通的URL，然而访问一个Portlet的URL有其特殊的格式，因此需要把指向自身的URL全部转换为Portlet格式。这些URL主要是HTML FORM中的ACTION属性。
2、Session范围。Session在Portlet中分为PORTLET_SCOPE和APPLICATION_SCOPE两种，为了避免冲突缺省情况下应该把Web应用中的Seesion变量都设置为PORTLET_SCOPE。
3、开发人员透明。Web应用是否包装为Portlet对Web应用本身不做更改，这样即使被包装为Portlet后，开发人员仍可当作普通的Web应用继续开发。
4、可选的Portlet特性。使得开发人员能够在Web应用中使用Portlet特性，当Web应用独立部署运行时这些特性自动失效，当部署到Portal中就可以利用到Portlet特性了。

Common Web Application -> WSRP

WSRP规范致力于定义一个面向表示（presentation-oriented）的Web Services协议以及相应的接口集，面向表示的Web Services协议不仅提供商业逻辑还提供界面表示，应用程序可以容易的通过代理工具集成面向表示的Web Services。

在Portal应用中，经常有将现存的某个应用在Portal界面中显示的需求，而且该应用是运行在与Portal服务器不同的机器上的。这种需求在Portal项目中使极为常见的，解决的方法主要有：1、如果应用提供java接口，可以建立JSR168 Portlet使用该接口；2、如果应用存在Web界面，则可通过Web裁减（Web Clipping）技术来集成，Kapow公司是这一技术的领先者；或者通过HTML IFRAME技术作简单的集成。

WSRP规范出现后，我们有了更加方便的新选择，如果应用本身支持WSRP，那么Portal服务器可以直接集成该应用无需额外开发。但是目前支持WSRP的应用还太少，而且期待现存的应用自身增加WSRP支持也是不现实的。例如对一个现存的部署在Apapche Http Server上的PHP应用，用户当然希望无需对该应用进行任何更改就能够支持WSRP。

我曾写过一篇短文“WSRP实践&想法”阐述这方面的想法。我最希望看到这样的WSRP工具出现，安装在Web服务器上后，通过配置就能够将部署在该Web服务器上的应用以WSRP协议发布。

这样的工具主要的是两部分的功能：
1、当然是WSRP协议支持。可以参考已有的开源实现，我想其中的初期的重点是URL Wirting和Stateful Information，即URL的双向转换和状态信息的处理。
2、与现有应用的交互，可以从两个方向来实现：
2.1 利用服务器功能，例如Java Servlet Server提供javax.servlet.RequestDispatcher接口实现来完成对本服务器上的资源调用。这样做的优点的性能高效，缺点是不同的服务器要开发不同的版本；
2.2 采用类似HTTP Porxy的方式实现。优点是适应性强，不必理睬Web应用的具体实现、部署技术，缺点是性能会有影响。

以上就是我的一些想法，希望尽快看到相关的产品出现，这些开发Portal应用就会轻松很多。