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

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

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

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

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

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

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

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

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

感谢大家，让我对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产品的文档，里面有关于整个用户验证过程的详细说明。

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

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

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

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

再问一个问题，CAS这种方式如果多个应用间用户名不同怎么办？典型的就是Portal和下面的某个应用用户名不一致需要影射的