关于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的单独更新。那么这个想法有没有人尝试过，具体实现会有什么问题、难点或瓶颈？

评论

48 楼 openeyes 2009-07-31  

lnaigg 写道

看来真得露两手了，门户集成我总结了几种方式：iframe、proxy、xml+xsl、数据集成、业务集成

iframe - 最土的方式，也是用得最多的方式，不说了。

proxy - 就是上面说的httpclient，读取远程页面资源写到portlet上。但这种方式问题是无法获取用户信息，一般的cas在iframe上跑得很好，在proxy机制上就失效了。原理自己研究。

xml+xsl - proxy的高级用法。可以在服务器端合成，也可以在客户端合成，xml可以是本地应用，也可以是远程应用（远程要用proxy）。客户端合成可以走cas单点登录，服务器端不行。原理同上。

数据集成 - 在JSR168标准下建立一套Portlet框架，可以读取各种数据源，获取信息。做到这个层次就不错了。

业务集成 - 比数据集成高层次，建立一套框架获取业务信息，Portlet与业务功能的交互方式可以是WebService或其他。要做到这个层次，需要业务应用的设计达到了足够高的水平，业务交互机制足够完善（如SOA）。

lnaigg兄多露两手吧 能不能就每种方式画个图啊？另外能不能就跨context的认证提供一个建议阿？

47 楼 arkxu 2009-07-31  

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不适合做复杂的交互式业务，而适合做数据整合数据展现的功能。

呵呵。前半部分完全正确。后半部分不太准确。

页面布局这样的事情是UI的工作，应该是portal产品里最简单没有技术含量的事情。对于portal产品，每家都是遵循jsr168却都有自己的扩展，jsr168的实现方式和这些扩展才是portal的核心。

另外，portlet的接口绝大多数定义了一些和portal集成和数据交换等表现层的东西。和业务逻辑毫无关系。多数的产品都是可以包装成portlet, 部署到portal里。比如struts, 和spring mvc就原生支持portlet dispacher. 还有很多的generic 分发器可以用来做这个包装。portlet 的后台可以很复杂比如工作流引擎像intalio bpms, 比如KM管理如alfresco，甚至是一个拥有全球多个数据中心的超级搜索引擎如google 。当然也可以很简单的显示一个日历

46 楼 arkxu 2009-07-31  

楼主的问题不太看的懂。觉得楼主最好多看看企业里使用portal的人，他们的系统是什么样子的。

对于技术问题。主要的实现就是一个所谓的portletcontainer， 依据jsr168. 当然168有很多的限制还有待268的改进。所以基本上每个公司都基于168有自己的扩展来满足那些还不被支持的标准。比如portlet和portlet之间的通信，portlet和portal之间的通信。

要学习jsr168或者268的实现，建议你看一下 pluto 的源代码，只是一个最最简单最最纯粹的portlet container。这个算是必经之路。

45 楼 popoer 2009-07-30  

lnaigg 写道

看来真得露两手了，门户集成我总结了几种方式：iframe、proxy、xml+xsl、数据集成、业务集成

iframe - 最土的方式，也是用得最多的方式，不说了。

proxy - 就是上面说的httpclient，读取远程页面资源写到portlet上。但这种方式问题是无法获取用户信息，一般的cas在iframe上跑得很好，在proxy机制上就失效了。原理自己研究。

xml+xsl - proxy的高级用法。可以在服务器端合成，也可以在客户端合成，xml可以是本地应用，也可以是远程应用（远程要用proxy）。客户端合成可以走cas单点登录，服务器端不行。原理同上。

数据集成 - 在JSR168标准下建立一套Portlet框架，可以读取各种数据源，获取信息。做到这个层次就不错了。

业务集成 - 比数据集成高层次，建立一套框架获取业务信息，Portlet与业务功能的交互方式可以是WebService或其他。要做到这个层次，需要业务应用的设计达到了足够高的水平，业务交互机制足够完善（如SOA）。

楼上的强！

我认为这几种也都可以归结为proxy模式的不同实现，实际都是开发一个通用的框架或者potlet来整合应用，应用不需要真正按照jsr规范去开发portlet了，而是按照你定义的简化版规范来提供数据，根据对数据规范的要求不同，应用系统改造的成本也有所差别。

整合的方式，还忘了一种，就是利用jsonp，纯脚本方式的，不给portal server增加任何负担，也是值得尝试的。

另外，igoogle的widget也是值得研究的。

我认为在portal项目中，整合、认证这些一般都还是比较好解决的，最麻烦的还是权限问题，搞不好一个权限分配问题会需要到N多个系统进行授权，这个也是最难统一整合到一起的。

44 楼 wyuch 2009-07-30  

popoer 写道

Iframe确实很土也有很多问题，但实际做项目的时候，你会发现确实是个好东西。

我们实际的做法是，可以完全控制、能够复用的部件，用标准portlet开发实现。

对于项目中特定的整合需求，尽量用iframe实现，这个对被整合系统方面的技术要求是最低的。

有些时候，也用了楼主提到的httpclient代理的方式，这个也是个好东东，可以克服iframe的种种弊端。

总体的感受是，做portal项目时，思路不能太技术化，能最快解决问题的技术就是好技术，呵呵~

我觉得你确实是实际做了Portal项目的人，很有道理。

43 楼 wyuch 2009-07-30  

lnaigg 写道

看来真得露两手了，门户集成我总结了几种方式：iframe、proxy、xml+xsl、数据集成、业务集成

iframe - 最土的方式，也是用得最多的方式，不说了。

proxy - 就是上面说的httpclient，读取远程页面资源写到portlet上。但这种方式问题是无法获取用户信息，一般的cas在iframe上跑得很好，在proxy机制上就失效了。原理自己研究。

xml+xsl - proxy的高级用法。可以在服务器端合成，也可以在客户端合成，xml可以是本地应用，也可以是远程应用（远程要用proxy）。客户端合成可以走cas单点登录，服务器端不行。原理同上。

数据集成 - 在JSR168标准下建立一套Portlet框架，可以读取各种数据源，获取信息。做到这个层次就不错了。

业务集成 - 比数据集成高层次，建立一套框架获取业务信息，Portlet与业务功能的交互方式可以是WebService或其他。要做到这个层次，需要业务应用的设计达到了足够高的水平，业务交互机制足够完善（如SOA）。

哈哈，露两手不错。

我上面说了CAS怎么解决代理模式下的用户认证问题的。实际上CAS的PGT、PT就是应对这种要求的。

42 楼 lnaigg 2009-07-30  

看来真得露两手了，门户集成我总结了几种方式：iframe、proxy、xml+xsl、数据集成、业务集成

iframe - 最土的方式，也是用得最多的方式，不说了。

proxy - 就是上面说的httpclient，读取远程页面资源写到portlet上。但这种方式问题是无法获取用户信息，一般的cas在iframe上跑得很好，在proxy机制上就失效了。原理自己研究。

xml+xsl - proxy的高级用法。可以在服务器端合成，也可以在客户端合成，xml可以是本地应用，也可以是远程应用（远程要用proxy）。客户端合成可以走cas单点登录，服务器端不行。原理同上。

数据集成 - 在JSR168标准下建立一套Portlet框架，可以读取各种数据源，获取信息。做到这个层次就不错了。

业务集成 - 比数据集成高层次，建立一套框架获取业务信息，Portlet与业务功能的交互方式可以是WebService或其他。要做到这个层次，需要业务应用的设计达到了足够高的水平，业务交互机制足够完善（如SOA）。

41 楼 popoer 2009-07-30  

Iframe确实很土也有很多问题，但实际做项目的时候，你会发现确实是个好东西。

我们实际的做法是，可以完全控制、能够复用的部件，用标准portlet开发实现。

对于项目中特定的整合需求，尽量用iframe实现，这个对被整合系统方面的技术要求是最低的。

有些时候，也用了楼主提到的httpclient代理的方式，这个也是个好东东，可以克服iframe的种种弊端。

总体的感受是，做portal项目时，思路不能太技术化，能最快解决问题的技术就是好技术，呵呵~

40 楼 abeet 2009-07-30  

asialee 写道

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

我什分同意你的看法。

39 楼 wyuch 2009-07-30  

foxxiao 写道

你所说的伪portal，在session的解决上 会是个 很大的问题！！

另外，还有一些权限认证的东西  ，这个可能 需要自己在重新定义

应该不会是一个很大的问题，用apache的httpclient就可以。用户在某个伪Portlet上验证通过后的响应中会包含Cookie（我们不妨假定所有会话都基于Cookie），该Cookie中会有SessionID，则Portal后续的对此伪Portlet的所有请求，都只需将包含SessionID的Cookie带回去，即可实现用户到某个伪Portlet的Session。原理和普通的Session没有区别，只是普通Session由浏览器自动发送Cookie，而Portal代理访问伪Portlet时需要写程序手工管理Cookie的回发，还需要建立Cookie与用户的关联。

38 楼 wyuch 2009-07-30  

openeyes 写道

我承认iframe不好，但目前还没有找到更好的方式。举个例子，我portal用的是jetspeed,context path是
/jetspeed, 然后我有个应用是oa, context path是/oa, 在portal中我有个portlet是最新邮件列表，这个
portlet是在oa这个web app中的, 所有我在portal页面上要点击查看某个邮件详细信息的话，链接是/oa/email/email?id=198, 这个时候就会出现oa的登录框，这个怎么解决？

谢谢

我上边已经说了这个问题的，如果引入了SSO，你点/oa/email/email?id=198直接就进入了OA的相应页面，不会出现登录框的。建议你装个CAS试试，了解一下它的机制。

在iframe下：

wyuch 写道

只需在第一次展现iframe中的内容时通过URL带去LoginTicket（即<iframe src="URL">中的URL部分），这时业务系统已经鉴别过这个LoginTicket并为用户建立起Session了，以后的访问（比如你点击某个邮件）就不需要再带LoginTicket了呀。

在代理访问的情况下：

wyuch 写道

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

37 楼 openeyes 2009-07-30  

lnaigg 写道

前面有很多人在讨论iframe做portlet。那的确是最土最低层次的实现方式，看起来简单，如果整个portal都是iframe，可以想象那是多么痛苦的事情。首先，IE对iframe有bug，加载页面时iframe太多页面就会假死。然后，整个门户页面就是一个个洞一个个滚动条。然后，皮肤样式这些，在iframe中都无法控制了。然后，布局无法细化了。然后，如果iframe所在服务器挂了就是一个个错误框。

portlet业务方面，portlet要跟portal交互的只有用户登录信息（也就是个用户ID），通过jaas可以把登录信息传到portlet上。至于portlet实现的业务，那是各个portlet自己控制的，跟portal可以没有一毛钱关系。

portlet兼容性方面，只要你严格按照JSR168规范来做，不针对Portal产品扩展，几乎不会有对Portal兼容性问题。portle真正兼容性问题在于各个厂商对servlet的实现各有不同引起的问题，如portlet对taglib的解析在各服务器上不一样，同样jstl、jsf这些都有问题。

所以，我总结了portlet用Velocity/Freemarker做页面是最好的，别用什么jsp、jstl、jsf等跟servlet打交道的东西。



Portal是一个很实用的产品，实施的时候立竿见影，客户马上可以看到效果，所以很多公司都开始搞了。大家努力吧。

我承认iframe不好，但目前还没有找到更好的方式。举个例子，我portal用的是jetspeed,context path是
/jetspeed, 然后我有个应用是oa, context path是/oa, 在portal中我有个portlet是最新邮件列表，这个
portlet是在oa这个web app中的, 所有我在portal页面上要点击查看某个邮件详细信息的话，链接是/oa/email/email?id=198, 这个时候就会出现oa的登录框，这个怎么解决？

谢谢

36 楼 lnaigg 2009-07-30  

前面有很多人在讨论iframe做portlet。那的确是最土最低层次的实现方式，看起来简单，如果整个portal都是iframe，可以想象那是多么痛苦的事情。首先，IE对iframe有bug，加载页面时iframe太多页面就会假死。然后，整个门户页面就是一个个洞一个个滚动条。然后，皮肤样式这些，在iframe中都无法控制了。然后，布局无法细化了。然后，如果iframe所在服务器挂了就是一个个错误框。

portlet业务方面，portlet要跟portal交互的只有用户登录信息（也就是个用户ID），通过jaas可以把登录信息传到portlet上。至于portlet实现的业务，那是各个portlet自己控制的，跟portal可以没有一毛钱关系。

portlet兼容性方面，只要你严格按照JSR168规范来做，不针对Portal产品扩展，几乎不会有对Portal兼容性问题。portle真正兼容性问题在于各个厂商对servlet的实现各有不同引起的问题，如portlet对taglib的解析在各服务器上不一样，同样jstl、jsf这些都有问题。

所以，我总结了portlet用Velocity/Freemarker做页面是最好的，别用什么jsp、jstl、jsf等跟servlet打交道的东西。



Portal是一个很实用的产品，实施的时候立竿见影，客户马上可以看到效果，所以很多公司都开始搞了。大家努力吧。

35 楼 foxxiao 2009-07-30  

你所说的伪portal，在session的解决上 会是个 很大的问题！！

另外，还有一些权限认证的东西  ，这个可能 需要自己在重新定义

34 楼 wyuch 2009-07-30  

foxxiao 写道

wyuch 写道

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

这个是portl页面吗？这个明明是个html页面。。。。。

大哥，我说了我还没有开始做呀，这只是个界面原型

33 楼 foxxiao 2009-07-30  

wyuch 写道

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

这个是portl页面吗？这个明明是个html页面。。。。。

32 楼 foxxiao 2009-07-30  

我当时也研究过portal一段时间，
我觉得portal技术思想很好，但是要实际实现N复杂！！！英文和中文文档也少的可怜。

另外，我当时研究的就是Jetspeed2，我只能说这个东西 还很不完善，很原始。

31 楼 wyuch 2009-07-30  

CoxZhang 写道

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

我的想法大体和你一致。不过我想不需要为每一个业务系统的JSP页面都建立一个对应的符合JSR168的Portlet，因为这些Portlet实际上不起作用，只是一个中间代理的角色，所以我想在JSR168的基础上额外支持这种需求，通过在Portal里进行简单配置即可直接使用业务系统上的JSP（当然是组织得比较良好的，起码不能带<html>标签，只能是一个片段）,其他的界面样式、布局、拖拽、用户认证都由Portal来自动管理。

30 楼 wyuch 2009-07-30  

openeyes 写道

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的参数呢？

只需在第一次展现iframe中的内容时通过URL带去LoginTicket（即<iframe src="URL">中的URL部分），这时业务系统已经鉴别过这个LoginTicket并为用户建立起Session了，以后的访问（比如你点击某个邮件）就不需要再带LoginTicket了呀。

不过iframe始终不是个好的方案。

29 楼 wyuch 2009-07-30  

openeyes 写道

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了解不过，想听听高手的说法

谢谢

如果使用CAS，它有代理模式，可以通过ProxyTicket的方式去OA系统取HTML。凡SSO应该都支持代理模式吧，这种模式本来最常用的地方就是Portal。