编辑“Portal”（章节）

==Portal面临的挑战==
[[AJAX]]技术的出现使portal技术面临着巨大的挑战：和AJAX技术的旨趣类似，portal技术也希望Web页面变的更像传统好用的[[C/S]]模式应用界面。通过在server端进行一些独特的处理技术，portal页面看起来像一个个小窗口，每一个小窗口相互独立，也可以彼此合作。

在server端每一个小窗口由一个portlet提供，通过复杂的聚合技术把portlet输出的内容聚合成一个完整的portal页面。显然，聚合技术是portal的核心技术。然而聚合带来的问题是：一个 portlet的刷新请求需要整个页面所有的portlet都进行刷新；而大部分portlet的状态其实并没有发生改变。这使得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的模块异步请求, 独立刷新. 显然更好,更彻底.