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

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

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

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

  谢谢
  

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

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

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

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

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

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

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

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

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

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

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