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

评论

68 楼 baron 2009-07-31  

wyuch 写道

openeyes 写道

baron 写道

以我做过的Portal项目来说，Portlet基本都是用的IFrame方式，SSO用的是Sun Access Manager，基本流程是这样的：用户通过AM登录，AM在本地将一个随机串作为令牌存入会话Cookie，所有被集成的应用在收到HTTP请求后会从Cookie抓取令牌往AM验证得到用户身份完成授权，整个过程不需要页面跳转。

请问兄台，AM的Cookie在其他应用中怎么访问啊？部署在不同的context path下的应用不能共享cookie的吧？

我理解他的这些被集成的应用都是处于同一个域的，所以可以用Cookie共享的方式集成。
只需把Cookie的path属性设为“/”，即可被不同ContextPath的应用共享。
如果能确保都是同一个域，并且能够接受iframe，那么这也是一种不错的方案。

是的，就是这个意思。你举的OA待办的例子在这里其实Portal只要提供一个简单的链接就可以了，原有的OA公文处理逻辑本身不需要改造，但需要增加一段SSO获取用户身份的代码。

67 楼 baron 2009-07-31  

openeyes 写道

lnaigg 写道

举我们的例子，我们的门户集成OA其实很简单，有“待办公文列表”这个portlet，但“办理该公文”这个功能不做到portlet上，而是带着公文id直接跳转到OA相关功能上。

都说了，portlet不擅长做业务，只擅长做信息集成，那些业务操作还是交给业务系统做。

所以我说JSR286那些交互功能没啥用，JSR168就足够了。

呵呵，你这种方法正是我想要的，关键是，“而是带着公文id直接跳转到OA相关功能上。”就是说已经转到OA这个应用上了，这个时候认证信息怎么带过去呢？比如OA是部署在/oa下的，portal部署在/portal下，那么跳转地址类似
http://servername:port/oa/todo?id=xxxx, 这个时候已经不在/portal下了，portal中的session无法使用
就会出现oa的登陆界面。
  那么，oa如何找到认证信息呢？

放在Session里显然是不合适的，前面已经说了，把用户令牌存在Cookie里，同一个域里的应用都可以共享，作为企业内部应用来说，这样限制没有什么问题。

PS：如果像CAS那样在CAS Server端做SSO的话，跨域的这个限制也是可以去掉的。

66 楼 wyuch 2009-07-31  

感觉不和Portal结合起来，SSO根本没法卖。

65 楼 wyuch 2009-07-31  

openeyes 写道

lnaigg 写道

举我们的例子，我们的门户集成OA其实很简单，有“待办公文列表”这个portlet，但“办理该公文”这个功能不做到portlet上，而是带着公文id直接跳转到OA相关功能上。

都说了，portlet不擅长做业务，只擅长做信息集成，那些业务操作还是交给业务系统做。

所以我说JSR286那些交互功能没啥用，JSR168就足够了。

呵呵，你这种方法正是我想要的，关键是，“而是带着公文id直接跳转到OA相关功能上。”就是说已经转到OA这个应用上了，这个时候认证信息怎么带过去呢？比如OA是部署在/oa下的，portal部署在/portal下，那么跳转地址类似
http://servername:port/oa/todo?id=xxxx, 这个时候已经不在/portal下了，portal中的session无法使用
就会出现oa的登陆界面。
  那么，oa如何找到认证信息呢？

那就是单点登陆的问题了，SSO不仅能够让你在这种Context Path不一致的情况下只登录一次即可让所有应用都获得用户信息，就算是完全不同的IP或者域名也可以的。可以看看一个SSO产品的文档，里面有关于整个用户验证过程的详细说明。

64 楼 openeyes 2009-07-31  

lnaigg 写道

举我们的例子，我们的门户集成OA其实很简单，有“待办公文列表”这个portlet，但“办理该公文”这个功能不做到portlet上，而是带着公文id直接跳转到OA相关功能上。

都说了，portlet不擅长做业务，只擅长做信息集成，那些业务操作还是交给业务系统做。

所以我说JSR286那些交互功能没啥用，JSR168就足够了。

呵呵，你这种方法正是我想要的，关键是，“而是带着公文id直接跳转到OA相关功能上。”就是说已经转到OA这个应用上了，这个时候认证信息怎么带过去呢？比如OA是部署在/oa下的，portal部署在/portal下，那么跳转地址类似
http://servername:port/oa/todo?id=xxxx, 这个时候已经不在/portal下了，portal中的session无法使用
就会出现oa的登陆界面。
  那么，oa如何找到认证信息呢？

63 楼 wyuch 2009-07-31  

leadyu 写道

从单个项目来说，LZ这种伪portlet当然没问题，即简单又实用。但是从产品角度，就不是这么考虑了吧。

规范的高度更高不是解决具体项目的集成问题，假设大家的应用都按规范来建设，那么想想，业务系统的集成会是什么情况，而且也不仅限于web吧，这种伪portlet能支持其他客户端接入方式吗？

呵呵，这个还只是个设想。现在暂时的想法是在JSR168的基础上支持这种需求，这种需求是我们目前迫切需要解决的。然后学习lnaigg的方法，实现一个功能完善的Portlet访问数据源的框架。

感谢大家，让我对JSR168的认识前进了一大步。

62 楼 leadyu 2009-07-31  

从单个项目来说，LZ这种伪portlet当然没问题，即简单又实用。但是从产品角度，就不是这么考虑了吧。

规范的高度更高不是解决具体项目的集成问题，假设大家的应用都按规范来建设，那么想想，业务系统的集成会是什么情况，而且也不仅限于web吧，这种伪portlet能支持其他客户端接入方式吗？

61 楼 wyuch 2009-07-31  

lnaigg 写道

举我们的例子，我们的门户集成OA其实很简单，有“待办公文列表”这个portlet，但“办理该公文”这个功能不做到portlet上，而是带着公文id直接跳转到OA相关功能上。

都说了，portlet不擅长做业务，只擅长做信息集成，那些业务操作还是交给业务系统做。

所以我说JSR286那些交互功能没啥用，JSR168就足够了。

还是我举的关于显示个人薪水的例子比较恰当，即薪水的计算本身是需要引用业务系统的业务逻辑的，可能涉及到一大堆包，在Portlet里实现同样的业务逻辑很显然是不合适的。这里本身也不涉及到业务操作，我也赞同Portal不适合做集成业务操作的观点，但显示本身也有可能牵扯到业务逻辑。

另一方面，按照我的思路，只需把业务系统的显示薪水的页面裁减即可，如果是公文列表的例子，那么我只需把OA中显示公文列表的页面裁减即可，这个过程通常比开发一个Portlet，在这个Portlet中去读数据库然后按照业务系统的要求形成页面版段甚至按照业务系统的逻辑开发重复的逻辑要有一些优势。

60 楼 lnaigg 2009-07-31  

举我们的例子，我们的门户集成OA其实很简单，有“待办公文列表”这个portlet，但“办理该公文”这个功能不做到portlet上，而是带着公文id直接跳转到OA相关功能上。

都说了，portlet不擅长做业务，只擅长做信息集成，那些业务操作还是交给业务系统做。

所以我说JSR286那些交互功能没啥用，JSR168就足够了。

59 楼 wyuch 2009-07-31  

看来看去JSR168确实没有考虑到这种需求，对于处于这种需求帮助不大，需要Portal厂商自己扩展。

58 楼 wyuch 2009-07-31  

lnaigg 写道

Portal集成，我是最推荐数据库层面上的集成的，就是做一套能读取数据源的portlet框架，然后实现各种数据集成业务需求。
这种方式不是最先进，但实施最快最方便，实施速度快、效果好、难度低。

最好的好处就是不需要第三方系统做接口，只需要几个表结构。什么iframe、proxy、xml、json、webservice什么的方式，统统都需要第三方系统做个东西你才能用的上。但实际实施中哪有遗留系统肯帮你做这玩意。

我们做的系统绝大部分信息都可以从数据库中得到，所以数据库集成能完成95%以上的需求，除非要集成远程应用和封闭应用。

前面有人说跨context的认证，这个本来JSR168就是支持的，怎么把用户信息从portal传到portlet上，看看portlet接口就有了。
其实这用户认证就是个坎，你只要让portlet拿到用户登录信息，接下来用户相关的所有信息都可以在数据库中拿到。

我觉得这也是一种很好的方法，实际中应该也会经常用到。我觉得大部分远端系统中的东西其实都只要显示出来就可以了，所以都可以以读数据库的方式直接集成。但确实也有相当一部分像OpenEyes提到的需求，这部分需求非常实际，也是很重要的需要解决的需求。

57 楼 openeyes 2009-07-31  

lnaigg 写道

Portal集成，我是最推荐数据库层面上的集成的，就是做一套能读取数据源的portlet框架，然后实现各种数据集成业务需求。
这种方式不是最先进，但实施最快最方便，实施速度快、效果好、难度低。

最好的好处就是不需要第三方系统做接口，只需要几个表结构。什么iframe、proxy、xml、json、webservice什么的方式，统统都需要第三方系统做个东西你才能用的上。但实际实施中哪有遗留系统肯帮你做这玩意。

我们做的系统绝大部分信息都可以从数据库中得到，所以数据库集成能完成95%以上的需求，除非要集成远程应用和封闭应用。

前面有人说跨context的认证，这个本来JSR168就是支持的，怎么把用户信息从portal传到portlet上，看看portlet接口就有了。
其实这用户认证就是个坎，你只要让portlet拿到用户登录信息，接下来用户相关的所有信息都可以在数据库中拿到。

基于数据库集成的话有个大问题，就是我没法重用原来应用系统的中处理逻辑。比如上面我提到的Portal[待办公文列表->选择某个待办公文]->OA[办理该公文]，其中{办理该公文}在原先的OA中已经开发了，我们不可能在Portal中重新来一遍吧

56 楼 lnaigg 2009-07-31  

Portal集成，我是最推荐数据库层面上的集成的，就是做一套能读取数据源的portlet框架，然后实现各种数据集成业务需求。
这种方式不是最先进，但实施最快最方便，实施速度快、效果好、难度低。

最好的好处就是不需要第三方系统做接口，只需要几个表结构。什么iframe、proxy、xml、json、webservice什么的方式，统统都需要第三方系统做个东西你才能用的上。但实际实施中哪有遗留系统肯帮你做这玩意。

我们做的系统绝大部分信息都可以从数据库中得到，所以数据库集成能完成95%以上的需求，除非要集成远程应用和封闭应用。

前面有人说跨context的认证，这个本来JSR168就是支持的，怎么把用户信息从portal传到portlet上，看看portlet接口就有了。
其实这用户认证就是个坎，你只要让portlet拿到用户登录信息，接下来用户相关的所有信息都可以在数据库中拿到。

55 楼 wyuch 2009-07-31  

openeyes 写道

arkxu 写道

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

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

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

  我们的需求如下：
      现有OA,PA,IRB,....多个系统已经在用，其中OA是domino开发, PA, IRB都是j2ee应用
      现在要上一个门户，将OA中的待办文件、最新邮件等，IRB中最新资源列表集成到portal中，
   要求选中portal中的某个待办文件可以进入待办文件的办理流程（这个流程是在OA中的)， 点击
   某个资源则可以查看该资源的详细内容。
      PA则只要在Portal中放置一个链接,点击链接可以直接登录PA就可以了。
  问题是基于工作量的原因，我们现在不想在Portal中重新开发待办文件的处理流程，只需要点击能跳到OA应用中去处理就可以了，也不想在Portal中实现详细资源查看这个功能，这中要求用什么方式集成比较好?(我们现在用iframe)

  谢谢
  

呵呵，arkxu没有遇到openeyes这样的需求，这样的需求是我目前的项目必须要做到的。

Pluto看过，准备深入研究一下。看到它里面有一个很好的TestSuite，可以迁移过来测试Portal对JSR168规范的支持是否到位。

54 楼 wyuch 2009-07-31  

openeyes 写道

baron 写道

以我做过的Portal项目来说，Portlet基本都是用的IFrame方式，SSO用的是Sun Access Manager，基本流程是这样的：用户通过AM登录，AM在本地将一个随机串作为令牌存入会话Cookie，所有被集成的应用在收到HTTP请求后会从Cookie抓取令牌往AM验证得到用户身份完成授权，整个过程不需要页面跳转。

请问兄台，AM的Cookie在其他应用中怎么访问啊？部署在不同的context path下的应用不能共享cookie的吧？

我理解他的这些被集成的应用都是处于同一个域的，所以可以用Cookie共享的方式集成。
只需把Cookie的path属性设为“/”，即可被不同ContextPath的应用共享。
如果能确保都是同一个域，并且能够接受iframe，那么这也是一种不错的方案。

53 楼 openeyes 2009-07-31  

baron 写道

以我做过的Portal项目来说，Portlet基本都是用的IFrame方式，SSO用的是Sun Access Manager，基本流程是这样的：用户通过AM登录，AM在本地将一个随机串作为令牌存入会话Cookie，所有被集成的应用在收到HTTP请求后会从Cookie抓取令牌往AM验证得到用户身份完成授权，整个过程不需要页面跳转。

请问兄台，AM的Cookie在其他应用中怎么访问啊？部署在不同的context path下的应用不能共享cookie的吧？

52 楼 openeyes 2009-07-31  

arkxu 写道

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

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

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

  我们的需求如下：
      现有OA,PA,IRB,....多个系统已经在用，其中OA是domino开发, PA, IRB都是j2ee应用
      现在要上一个门户，将OA中的待办文件、最新邮件等，IRB中最新资源列表集成到portal中，
   要求选中portal中的某个待办文件可以进入待办文件的办理流程（这个流程是在OA中的)， 点击
   某个资源则可以查看该资源的详细内容。
      PA则只要在Portal中放置一个链接,点击链接可以直接登录PA就可以了。
  问题是基于工作量的原因，我们现在不想在Portal中重新开发待办文件的处理流程，只需要点击能跳到OA应用中去处理就可以了，也不想在Portal中实现详细资源查看这个功能，这中要求用什么方式集成比较好?(我们现在用iframe)

  谢谢
  

51 楼 baron 2009-07-31  

wyuch 写道

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

以我做过的Portal项目来说，Portlet基本都是用的IFrame方式，SSO用的是Sun Access Manager，基本流程是这样的：用户通过AM登录，AM在本地将一个随机串作为令牌存入会话Cookie，所有被集成的应用在收到HTTP请求后会从Cookie抓取令牌往AM验证得到用户身份完成授权，整个过程不需要页面跳转。

50 楼 giginet 2009-07-31  

君不见当初portal才推出的时候，那可是举着系统整合的大旗啊。但现在应用起来，反而觉得不如一般的系统来的方便，毕竟当时还没ajax的概念。虽然思想很好，所有产品都以portlet的形式模块化了，对于公司销售倒是很不错，hoho。

49 楼 giginet 2009-07-31  

Portal其实最大的应该是整合集成（portal的本意），而在其基础上开发应用反而应该是少数才对。
但整合起来，其实，很难。。。。尤其是已经用了很多年的老系统，每个系统都是不同的用户管理和权限控制，没有达到统一认证的前提下，一般都是伪认证。如果有注册码，那基本就死掉了。这种方法虽然可以解决认证的问题，但弊端也是显而易见的。