关于Portal、JSR168的一些想法和疑惑

最近因项目的需要，计划做一个Portal产品。初略地试用了几个Portal产品，看了一堆的关于Portal和JSR168的文章，还不是太明白，但已经有了一些想法和疑惑，恳请熟悉Portal的朋友指点。

首先，我理解Portal产品可以分为两部分。一部分是Web应用，提供了诸如页、布局、主题等功能，能够添加、删除Portlet；另一部分即是Portlet容器，两部分共处于一个Servlet容器中。

而Portlet是一个符合JSR168标准的类，是运行于Portal上的真正代表业务逻辑的部件，负责展现内容、处理请求。

这里有两个疑问：
一是Portal通常是改造了的Servlet容器，例如JetSpeed、LifeRay都对容器作了修改，几个厂商的Portal就更不用说了。为什么Portal不能作为单独的Web应用部署，以便于做到与中间件无关？这个问题可能是因为我还了解得比较浅，没有具体去实现javax.portlet中的接口，希望了解的朋友先指点我一下。

二是根据我目前的了解，Portlet成了最重要的资产，是实现集成的关键，一个Portlet对应着一个业务系统的某部分功能。但现实中这样做似乎不可行，例如Portal要集成财务系统的一个功能，以便于显示当前用户的薪资情况，但薪资的计算有赖于财务系统的数据库和一系列的类，并不容易单独抽取出来形成一个Portlet。

我目前有一个简单的想法：
1、各个系统（假定都是J2EE吧）将需要集成到Portal中的功能做成一个小的JSP页面（不妨称之为伪Portlet），这个小页面和业务系统处于同一个容器，根据不同的用户和请求参数输出不同的HTML片断。
2、一个类似portlet.xml的配置文件将这些JSP页面注册到Portal，Portal根据portlet.xml中提供伪Portlet的列表，用户从中选择并加入到Portal的页中。
3、用户访问Portal时，Portal将用户凭证（假定类似于Kerberos的票据）、用户对Portlet执行的操作等信息作为参数提交给伪Portlet对应的URL，伪Portlet在业务系统内部运行并返回HTML片断。
4、Portal将同一个页上用户定义的所有Portlet的HTML片段一一展现，并实现拖拽、最小化、删除Portlet、添加Portlet等一系列动作。稍微扩展一些也可以实现Edit、Help、Maximize之类的动作。

按照我上面的想法，似乎也可以很好的集成各个业务系统,实现这样一个伪Portlet的成本比从业务系统抽取逻辑实现一个JSR168的Portlet要小得多，用户的使用感受和JSR 168基本一致。但在这个想法中，实际没有Portlet容器的位置，也不需要Portlet规范，还可以集成AJAX，很容易地实现Portlet的单独更新。那么这个想法有没有人尝试过，具体实现会有什么问题、难点或瓶颈？

评论

28 楼 openeyes 2009-07-30  

wyuch 写道

[另一个重要问题是用户认证，其实使用iframe实现统一的用户认证也不是不可以的，但根据常见的SSO机制（以CAS为例），每个业务系统都集成到CAS中，那么各个iframe里的URL被访问时将会自动重定向到CAS服务器以获取LoginTicket，整个过程不需要程序员控制，即可实现统一认证。但这样的缺点是用户感觉不太友好，页面跳转次数太多了。

如果有能力修改SSO实现，那么在使用iframe的情况下可以由Portal代为申请LoginTicket或者别的什么Ticket，将其作为参数附加到iframe的src属性对应的URL上，这样跳转次数较少。但依然不是特别理想，如果页面iframe较多，用户体验还是不理想。

如果是以Protal作为HttpClient的形式代理用户向其他业务系统访问JSP页面，那么就可以使用CAS中的代理模式（或者类似），直接产生ProxyTicket向其他业务系统请求页面即可。对于用户来说，他只下载了一次HTML，用户体验比iframe要好。

我们知道这种代理访问本身需要的系统资源是很少的，真正的运算在业务系统上，性能上的问题不大，如果SSO和Portal是合二为一或者是同一个容器内的，那么性能就更不成问题了。

你说通过CAS获取LoginTicket,那么获取的凭证怎么带过去？是在url中加一个参数吗？
如果这样的话，portlet页面中的链接(例如有一个最新邮件的列表的portlet,你选中某个邮件点击链接会弹出一个详细内容的页面,这个页面实际上是OA系统的范围了），那么这些链接是否都要加获取LoginTicket的参数呢？

27 楼 openeyes 2009-07-30  

guazi 写道

portal所谓的集成各个系统，进行统一的认证、授权的意思是其他的系统是作为一个一个的portlet模块存在于portal容器中的（当然，portlet是很方便安装与卸载的）。
如果用iframe来搞个伪portlet的话，当然无法使用同一的容器认证。

  你的意思是把其他的系统全部用portlet重新写一遍？
  我们的情况是其他系统都已经在用（可以独立portal运行),portal中只集成了其中一部分功能。这就有个portlet
如何在原有系统认证的问题。
  比如你用usera登录到portal中，其中有个portlet是个人邮件最新邮件（oa系统中），那你怎么用usera在oa
中验证（假定oa中用户、密码和portal一致）？据我现在所知没有别的方法，只有用usera模拟一次oa系统的登录，然后取最新邮件列表。
  这个过程中，portal提供的sso好像一点都没用。不知道是不是我对jetspeed 2.1.3了解不过，想听听高手的说法

谢谢

26 楼 CoxZhang 2009-07-30  

恩，是否可以这样，自己做的portlet只负责呈现数据和传递业务参数，然后实际的业务处理交给业务处理的portlet或servlet？例如，前面的薪水portlet，除了外观参数外，可以让用户减薪水（模拟转账）， 然后由一个负责处理用户薪水的portlet或servlet处理。让业务处理的portlet或SERVLET跟表现的PORTLET分离。
   当然，这还要涉及用户验证等等。
不成熟的想法，请各位先进指正  

25 楼 wyuch 2009-07-30  

openeyes 写道

lnaigg 写道

再说说Portlet：LZ说的伪Portlet，后面有人说的iframe，这些都是属于没有理解portlet思想而产生的思路，是用普通网页开发方式套到Portlet上了。其实portlet开发、部署、卸载、调试都十分方便。真正需要做的是，实现一个功能全面一点的portlet基础框架，能读写数据库、能读到登录用户信息、能与Portal或其他公共应用交换数据，然后是用该框架做实际的业务。

另外，Portal的定位决定了Portlet不适合做复杂的交互式业务，而适合做数据整合数据展现的功能。

我们的portal项目用的jetspeed 2.1.3,也采用iframe的伪portlet来集成，是觉得不太好，但是没有找到好的
方法，楼主能不能详细说说你们的portlet框架？

谢谢

我还刚开始着手做呀，还不是太明白。我说说对于这一类集成的需求我的不太成熟的想法吧：

普通Portlet的HTML片段是在Portal服务器本地产生的，伪Portlet的HTML片段是由远程业务系统产生的。因此对Portal来说，除了在返回HTML片段时需要作为HttpClient向远程业务系统发起HTTP请求以外，在窗口状态、行为、样式、布局、换肤、拖拽等方面来说伪Portlet和Portlet是没有区别的。

这就解决了一iframe形式的Portlet最为重要的问题，那就是样式不易控制，不能换肤，用户体验不好，以及因浏览器对不同URL来源之间互相访问的限制而引起的其他问题。

另一个重要问题是用户认证，其实使用iframe实现统一的用户认证也不是不可以的，但根据常见的SSO机制（以CAS为例），每个业务系统都集成到CAS中，那么各个iframe里的URL被访问时将会自动重定向到CAS服务器以获取LoginTicket，整个过程不需要程序员控制，即可实现统一认证。但这样的缺点是用户感觉不太友好，页面跳转次数太多了。

如果有能力修改SSO实现，那么在使用iframe的情况下可以由Portal代为申请LoginTicket或者别的什么Ticket，将其作为参数附加到iframe的src属性对应的URL上，这样跳转次数较少。但依然不是特别理想，如果页面iframe较多，用户体验还是不理想。

如果是以Protal作为HttpClient的形式代理用户向其他业务系统访问JSP页面，那么就可以使用CAS中的代理模式（或者类似），直接产生ProxyTicket向其他业务系统请求页面即可。对于用户来说，他只下载了一次HTML，用户体验比iframe要好。

我们知道这种代理访问本身需要的系统资源是很少的，真正的运算在业务系统上，性能上的问题不大，如果SSO和Portal是合二为一或者是同一个容器内的，那么性能就更不成问题了。

24 楼 guazi 2009-07-30  

portal所谓的集成各个系统，进行统一的认证、授权的意思是其他的系统是作为一个一个的portlet模块存在于portal容器中的（当然，portlet是很方便安装与卸载的）。
如果用iframe来搞个伪portlet的话，当然无法使用同一的容器认证。

23 楼 openeyes 2009-07-30  

popoer 写道

使用伪portlet最大的问题，我认为是无法使用到portal容器提供的认证、授权等服务，界面样式控制、换肤等功能也需要额外去实现

如果我理解的没错，你这里的认证授权是指对被集成的应用系统而言的吧。
如果真的是指这个我觉得不用iframe的portlet,portal容器提供的认证、授权也没法使用吧？

22 楼 openeyes 2009-07-30  

lnaigg 写道

再说说Portlet：LZ说的伪Portlet，后面有人说的iframe，这些都是属于没有理解portlet思想而产生的思路，是用普通网页开发方式套到Portlet上了。其实portlet开发、部署、卸载、调试都十分方便。真正需要做的是，实现一个功能全面一点的portlet基础框架，能读写数据库、能读到登录用户信息、能与Portal或其他公共应用交换数据，然后是用该框架做实际的业务。

另外，Portal的定位决定了Portlet不适合做复杂的交互式业务，而适合做数据整合数据展现的功能。

我们的portal项目用的jetspeed 2.1.3,也采用iframe的伪portlet来集成，是觉得不太好，但是没有找到好的
方法，楼主能不能详细说说你们的portlet框架？

谢谢

21 楼 wyuch 2009-07-30  

lnaigg 写道

先说说兼容性问题：大部分开源Portal都可以作为一个普通web应用部署，只是因为各个web容器的servlet实现都有所不同，Portal对容器的兼容性也成了很大问题。例如，Jetspeed2移植到weblogic上时就要解决很多问题。所以，想找一个全面兼容各大服务器的Portal很难，起码我没找到。

再说说我所理解的Portal：Portal可以比作一个商场，商场不直接卖东西，只提供一个服务环境、各种基础设施，没招商之前只是一个空壳。Portlet是就是商家，所以“Portlet成了最重要的资产”，这个是很正确的。

其实，不管哪个厂商的Portal，其实都是只做两件事情：页面布局和解析Portlet。其中，解析Portlet这个工作其实是次要的，各个Portal都一样，因为有标准规范（JSR168）。真正考验实力的是页面布局。页面布局分几个部分：页面模版、排版方式、Portlet状态，等。特别是页面模版，各个厂商实现都不同，这是需要细心评估的，因为Portal的二次开发主要是在做页面模版，各种美工。

再说说Portlet：LZ说的伪Portlet，后面有人说的iframe，这些都是属于没有理解portlet思想而产生的思路，是用普通网页开发方式套到Portlet上了。其实portlet开发、部署、卸载、调试都十分方便。真正需要做的是，实现一个功能全面一点的portlet基础框架，能读写数据库、能读到登录用户信息、能与Portal或其他公共应用交换数据，然后是用该框架做实际的业务。

另外，Portal的定位决定了Portlet不适合做复杂的交互式业务，而适合做数据整合数据展现的功能。

我也没有找到兼容性好的Portlet容器。JSR 168好像没有达不到兼容的目的，各个Portal产品本身不兼容就算了，Portlet事实上也很难兼容，很多为LifeRay写的Portlet就难以迁移到别的Portal上。

现在的目标是自己开发一个Portal，页面布局、模板、样式、Portlet状态这些方面感觉都不难解决。

我说的业务系统相关的Portlet，不一定是要做复杂的交互的，比如说前面提到的显示个人薪水情况的Portlet，他只有显示没有交互。但显示薪水可能涉及到财务或者人力资源某个系统的功能，有比较复杂的逻辑来计算薪水。现在开发这个Portlet需要迁移业务系统关于薪资计算的逻辑到Portal上，这些逻辑可能涉及一大堆类，很显然不是好的选择。

当然我们可以用WebService，但对于Portal实施人员来说，在业务系统上部署一个WebService的难度应该要大于一个JSP页面。所以我觉得这种情况下用一个JSP页面作为伪Portlet，由Portal代理用户去访问业务系统上的伪Portlet，可以达到比较满意的效果。

我目前的想法是：还是实现一个遵循JSR168的Portal，然后有一个对这种伪Portlet进行额外支持。

20 楼 wyuch 2009-07-30  

popoer 写道

portlet容器不能独立于servlet单独部署，大概是和各个web容器对web应用程序的部署管理机制有关的，因为portlet部署时也有很多事件要触发，要做实例化初始化这些操作，而不同的servlet容器对web应用部署时的处理机制是不一样的，而portlet容器需要依赖web容器传递的消息，这就导致必须和servlet容器绑定在一起了。。。

我模模糊糊也是这样猜测的

19 楼 wyuch 2009-07-30  

TheMarine 写道

做了liferay2年多,但是没有遇到过lz所需要的场景,开发其实还是很简单的,基本你只要关注业务,其他一概自动化解决.

可能是做的业务方向不一样，我已经遇到了好几个项目要求集成其他系统的功能了。

在LifeRay上开发Portlet应该不算难，主要是要能解决我遇到的这种场景，应该还是比较普遍的吧。

18 楼 Kisses99 2009-07-30  

我觉得portal就是一个facade模式啊

17 楼 wyuch 2009-07-30  

popoer 写道

使用伪portlet最大的问题，我认为是无法使用到portal容器提供的认证、授权等服务，界面样式控制、换肤等功能也需要额外去实现

我也见过用iframe做portlet的，似乎还比较流行，但觉得不优雅，缺陷比较多。我的想法是Portal服务器作为代理去访问各个业务系统上的伪Portlet，而不是以iframe的方式让浏览器直接访问业务系统。直接访问会出现无法认证、授权，也无法进行样式控制。但以代理方式应该都是可以做到的，认证、授权就可以和SSO完美结合，因为伪Portlet和JSR 168中的Porlet一样成为了整个Portal页面HTML中的一小段，因此样式控制、换肤也是可以做到的。

16 楼 asialee 2009-07-30  

wyuch 写道

高手快谈谈看法。上传同事做的一个Portal的界面原型，可以换肤，还是很漂亮的。

你们公司的UI不错，做的东西都挺好看的。

15 楼 nihongye 2009-07-30  

portal的主要问题是决定在什么层次上进行集成。应只对完全隔离的系统做集成。

14 楼 TheMarine 2009-07-30  

做了liferay2年多,但是没有遇到过lz所需要的场景,开发其实还是很简单的,基本你只要关注业务,其他一概自动化解决.

13 楼 guava 2009-07-30  

研究下pluto

12 楼 lnaigg 2009-07-30  

再说一下，其实Pluto是一个很好的东西，因为它是一个纯粹的Portlet容器，没有布局。所以如果哪个公司或个人有魄力有能力，完全可以用Pluto作为Portlet容器核心，再自己开发一套布局功能出来，这就是一个完整的Portal产品了。

11 楼 lnaigg 2009-07-30  

先说说兼容性问题：大部分开源Portal都可以作为一个普通web应用部署，只是因为各个web容器的servlet实现都有所不同，Portal对容器的兼容性也成了很大问题。例如，Jetspeed2移植到weblogic上时就要解决很多问题。所以，想找一个全面兼容各大服务器的Portal很难，起码我没找到。

再说说我所理解的Portal：Portal可以比作一个商场，商场不直接卖东西，只提供一个服务环境、各种基础设施，没招商之前只是一个空壳。Portlet是就是商家，所以“Portlet成了最重要的资产”，这个是很正确的。

其实，不管哪个厂商的Portal，其实都是只做两件事情：页面布局和解析Portlet。其中，解析Portlet这个工作其实是次要的，各个Portal都一样，因为有标准规范（JSR168）。真正考验实力的是页面布局。页面布局分几个部分：页面模版、排版方式、Portlet状态，等。特别是页面模版，各个厂商实现都不同，这是需要细心评估的，因为Portal的二次开发主要是在做页面模版，各种美工。

再说说Portlet：LZ说的伪Portlet，后面有人说的iframe，这些都是属于没有理解portlet思想而产生的思路，是用普通网页开发方式套到Portlet上了。其实portlet开发、部署、卸载、调试都十分方便。真正需要做的是，实现一个功能全面一点的portlet基础框架，能读写数据库、能读到登录用户信息、能与Portal或其他公共应用交换数据，然后是用该框架做实际的业务。

另外，Portal的定位决定了Portlet不适合做复杂的交互式业务，而适合做数据整合数据展现的功能。

10 楼 whaosoft 2009-07-29  

Portlet太牛了好像一般公司弄不了 哎 可惜啊

9 楼 popoer 2009-07-29  

portlet容器不能独立于servlet单独部署，大概是和各个web容器对web应用程序的部署管理机制有关的，因为portlet部署时也有很多事件要触发，要做实例化初始化这些操作，而不同的servlet容器对web应用部署时的处理机制是不一样的，而portlet容器需要依赖web容器传递的消息，这就导致必须和servlet容器绑定在一起了。。。