portal技术的可研究方面

portal技术的可研究方面 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应用就会轻松很多。 **这两天在Weblogic Portal 8.1上试验了WSRP（中文）的实现，在WLP8.1发行的时候WSRP协议尚未正式发布，因此现在对WSRP的支持是以Support Kit的形式提供的，安装WSRP Support Kit一直到实验完毕整个过程很顺利。两个分别独立的WLP Domain，A Domain可以直接引用B Domain的Portlet，无须开发或者重新启动任何服务。 在EIP（企业信息门户，Enterprise Information Portal）应用中，一个常见的问题就是如何集成已有Web应用。企业往往已经存在许多重要的Web应用，这些已有应用和新建的Portal服务器是分离的，但是作为EIP系统当然希望能够在同一个入口访问所有的应用。 目前解决这种问题的方法一般称之为“Web Clipping”，Kapow公司的RoboSuite就是这个领域的佼佼者，其基本原来是就在Portal服务器实现一个代理，该代理在接受用户请求后按照实现设置的规则访问相应的网站，并将取得的网页返回给用户。 我想到的是WSRP在这个方面应该大有作为： 1、类似Kapow RoboSuite这样的产品可以实现WSRP Producer功能，这样Kapow公司就无须再为各种Portal服务开发特定版本； 2、能否有这样的产品，安装在已有的Web服务器上，从而将该服务器上的应用以WSRP的方式发布出去。这种方法可以很方便的将已有的Web应用自动变成“插件”，在任何支持WSRP的Portal服务器上“即插即用”； 3、我相信接下来会有很多产品（ERP、CRM、OA）本身就提供WSRP的支持。例如Lotus Notes这款流行的OA系统，许多Portal服务器都有针对它的集成手段，可谓各显神通。如果Lotus Notes本身就支持WSRP，那么兼容WSRP的Portal服务器都可以直接集成Lotus Notes。