Portal面临的挑战

AJAX技术的出现使portal技术面临着巨大的挑战：

和AJAX技术的旨趣类似，portal技术也希望Web页面变的更像传统好用的C/S模式应用界面。通过在server端进行一些独特的处理技术，portal页面看起来像一个个小窗口，每一个小窗口相互独立，也可以彼此合作。在server端每一个小窗口由一个portlet提供，通过复杂的聚合技术把portlet输出的内容聚合成一个完整的portal页面。显然，聚合技术是portal的核心技术。然而聚合带来的问题是：一个portlet的刷新请求需要整个页面所有的portlet都进行刷新；而大部分portlet的状态其实并没有发生改变。这使得portal的性能受到很大的质疑。

AJAX带来一种新的思想：可以在浏览器端完成聚合操作。可以看看Netvibes (www.netvibes.com)和GOOGLE IG(www.google.com/ig)的效果。这种技术的要点是：server端比portal简单的多，仅负责维护若干类似portlet的Web module以及用户选择的页面设置信息。把页面上Module聚合的工作用数千行java script写到页面里，在运行时由客户端浏览器来完成。

这种效果比传统的portal要好的多，带来一种 Module独立刷新的效果。我看到很多人在讨论portal技术与AJAX的结合，但是AJAX实际上已经让整个portal技术的存在带来挑战。

挑战之一是实施成本问题,主流的商业Portal服务器一般都是很贵的,项目预算当在7-8位数(硬件,软件,业务系统开发和培训服务), 一般的项目不敢问津. 开源产品,(包括Liferay, Pluto, JBoss Portal),需要二次开发的成本很高,而且缺少很多高级功能(典型如Inter-Portlet Communication,以及 WSRP支持),导致总体的成本仍然很高. 相比之下,采用AJAX方案就便宜的多,需要的仅仅是一个普通的Web Server. 只需要有人在IOC容器基础上做一个AJAX客户端聚合的Framework. (这会是一个商机?)

挑战之二是性能问题. Portal在Servlet之前作了一个统一的聚合器, 聚合器在一个浏览器请求之前需要页面上的所有portlet的render request返回, 而Portlet的处理时间是参差不齐的.这样,即使在WebSphere Portal 6推出并行render之后, 页面也要等待处理最慢的portlet返回之后再返回. 曾经有人提出使用IFrame的解决方案,就是把处理慢的portlet 放到一个IFrame里,这样可以让Portal页面先带着大多数Portlet返回. 但是AJAX可以作到每一个类似portlet的模块异步请求, 独立刷新. 显然更好,更彻底.

05年时我们曾经的一个idea是,把每一个portlet封装为一个web service服务点, (WSRP已经可以作到这一点), 然后改进聚合器,让聚合器首先把页面的框架和js返回,然后每一个portlet通过AJAX请求异步拿到自己的内容. 这里涉及到一个关键问题是URL改写.

 现在我发现其实这种框架完全没有必要仅仅套在portal上, portal为了进行页面聚合而对JSP上的所有内部URL作了死规定,让外界无法对单独的portlet进行请求;而现在世道又反了,那何必再用Portal呢,JSP/Servlet都是可以独立接受请求的东西. 只需要有一个比较好的AJAX框架,再加上一个好用的Web 模块管理server,就完全可以制作出一个和portal技术相当,而性能又优于portal的技术来.(缺点可能是对移动设备的支持比不上portal,因为移动设备的浏览器对XMLHTTP是不支持的.)

也许AJAX将是Portal的终结者.