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

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

先说说兼容性问题：大部分开源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不适合做复杂的交互式业务，而适合做数据整合数据展现的功能。

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

研究下pluto

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

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

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

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

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

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

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