从根本上说，面向服务的架构能够使企业内部动态数据服务的创建变得更加方便，同时，还能够使企业开发人员创建影响这些服务的复合应用程序。Web2.0提供了一个丰富的Web体验，用户能够以高效的、充满希望的、有益的方式参与合作。

　　如果我们把这两个现象结合起来，那么，通过企业社团成员之间的互相交流，以及成员与不断变化的企业数据之间的交互，我们就能够实现这一关键的提高效率的新方法。

　　协作型企业相互融合，下一代的Web应用程序也已露端倪，但是，开发团体的推测是，为了实现明显的利益，企业所采用的各种技术之间存在着根本性的差异。标准必须朝哪个方向发展才能够满足SOA与Web2.0概念的结合，为了更好的理解这个问题，我们将致力于检验Java表示技术的状态。

　　Ajax化JavaServer Faces

　　标准奠定了SOA的基本结构，但是，在Web2.0的世界中却不存在着标准。为了支持Web2.0的功能，市场上出现了太多的方法，其中大多数在JavaScript的实现(影响Ajax的技术)上却非常繁杂。在Java EE的规范中，JavaServer Faces提供了表示层，但是，相比起Ajax技术和Web2.0概念的流行，它目前的修订版出现的更早。

　　事实证明，在组件层，JSF中的可扩展组件架构非常适合与Ajax技术协同使用，但是，组件层Ajax技术存在的问题是，它们是存在于狭小的规避JSF生命周期的交互空间内。解决这一问题所需要的是，一种更加全面的方式，以实现在JSF生命周期内的Ajax交互。具体来说，有以下两点需要着重阐述。

　　1.改进的用户交互模型: 在JSF中，目前的用户交互模型是基于表格的，它过于粗略而无法传输丰富的Web2.0特性。组件层的Ajax交互粒度，以及JSF目前依赖的基于表格的子任务模型，这两者之间存在着显著的差异。交互类型应当包含以下几种形式：

　　纯粹的本地客户端JavaScript交互，没有服务器通信、不需要执行JSF生命周期。这种类型的例子可以是，在日期选择组件中通过日历来进行导航。目前，通过组件层JavaScript实现能够支持这个模型。

　　组件层的Ajax交互，不需要执行JSF生命周期。这种类型的例子可以是，基于当前用户在文本框中的输入，从而形成一个列表。这里的关键是，用户与组件的交互仅仅影响到该组件的表示。同样，目前，通过组件层JavaScript实现能够支持这个模型。

　　组件层的提交，引发JSF生命周期的执行。生命周期的执行结果将成为新的表示，该表示可能会影响到页面中的多种组件。这这种类型的例子可以是，在日期选择组件中完成日期的选择，结果是引发显示不同的日期安排信息。目前在JSF中，还无法支持这种形式的交互。

　　2. 增量表示更新: 为了使用Ajaxian 方式(不是页面刷新)实现第三种交互模型，JSF需要一个增量更新机制，仅仅是把页面中应用到的表示层所做的必要修改从一个表现处理传向下一个表现处理。下面这个图示表明了这个概念。它需要一个Ajax桥，在服务器端把表示的改变组合起来，在客户端的DOM把那些变化重组。

　　JSF Push模式

　　Ajaxified JSF实现和多数其它的Ajax方式从遗留的Web应用程序模型中继承了一个共同的特征，该模型是一个客户端发起的交互模型。这意味着，客户端的表示层只需要针对用户与表示层的交互进行相应变化。

　　与使用遗留应用程序相比，使用Ajax技术，这个交互是细粒度的，但是，它仍然是客户发起的。现在，当你检验支持应用程序的SOA数据模型的动态特性、了解众多同步用户采用这一动态数据所进行的协调互操作时，你就能够意识到，在客户端推动动态表示变化的机制是非常重要的，这一点越来越清晰。它是达到Web2.0模型所需要的真正的动态特性的唯一途径。

　　在产业中已经证明，对于JSF规范与一个表示push模型的协作来说，Ajax push技术，也指Comet，是十分必要的。前文已经描述的这个增量更新特性，提供了在实现JSF Push模式时所需要的基于Ajax的更新机制。除此之外，当应用程序逻辑发现出现了一些将会影响客户端表示层状态的变化时，延长JSF的生命周期来允许一个强制的表现处理是很有必要的。下图表明了基本的JSF Push模型。

　　虽然，JSF push模型相对而言实现起来更加容易，但是，生产经验表明，为使得开发人员能够有效继承，仅仅暴露JSF API中底层强制的表示机制是远远不够的。关于基本的push机制，JSF规范很有必要对表现API进行介绍，从而呈现给开发人员一个清晰有效的机制，用于请求强制表示。API尤其需要提供以下几个方面：

　　1.触发的表现:应用程序开发人员应当能够在发出表示处理请求的业务逻辑中定义触发点。

　　2. 群组表现: 一个触发点能够影响一个单一客户端、多个客户端，或者是所有连接到该应用程序上的客户端。因此，为触发表现提供群组管理结构，这是很有必要的。

　　3. 预定的表现:有许多合适的计划机制应当被支持，包括，按需表现、推迟表现，以及内部表现。预定的表现架构应当具备可扩展性，以支持其他用户预先设定的需求。很重要的一点是，触发表现机制应当能够更加有效的传输。由于存在着大量的触发，它们潜在地以各种方式影响着客户端，因此，管理表现的处理这一任务不能仅仅落在开发人员身上。触发表现的实现，必须有效地合并表现处理请求、处理必要的同步，而且，这些操作都是以一种线程有效的方式。

　　多视图支持

　　现存的为JSF定义的阶段和需求范围，根本不足以支持满足Ajax的JSF应用程序——用户能够在同一应用程序上获得多个活动视图。阶段范围能够维护所有视图共同的状态，但是，它不足以处理视图之间不同的状态。由于多个同步请求都必须是活动状态，所以，需求范围也不充分。因此，需要一个新的范围，来管理满足Ajax 的JSF应用程序的会话方面。JBoss的Seam 方案提出了会话范围，它主要提供JSF中所需要的额外范围。除了支持多视图之外，会话范围还能够带来其他优势，例如，在应用程序中，通过会话中对一系列用户交互的明确描述，就能够有效地支持书签和返回按钮特性。

　　长期存在的HTTP请求

　　回到前面所提到的push模型，你可能注意到，机制需要一个特殊的HTTP请求，它能够异步地响应从应用程序中发出的触发表现出理请求。依据更新的频率，这个特殊HTTP请求能够长期存在。由于在响应之前，每一个请求都占用其线程，所以，在处理这个长期存在的请求时，现存的Servlet模型无法很好的响应。因此，为了支持push模型，必须对Servlet模型进行改变，使它能够以线程有效的方式来处理长期存在的请求。再强调一次，有很多生产方案与异步Servlets和HTTP服务器相关，Java EE规范能够在此基础上定义一个解决方案。

　　结论

　　人们仍然有些质疑：SOA与Web2.0世界将会发生抵触，新一代的协作型企业应用程序已露端倪。也存在着这样的质疑，现存的Java EE规范无法完全处理Web2.0提出的请求，以及JSR处理必须开始在直接项中考虑这些请求。然而，产业中的重大进步，已经能够处理出现的请求，并且能够实现扩展现存Java EE基础结构的商业化的可行方案。即将使用JSR 172来生成JSF2.0规范，非常重要的是,包含Ajax特性，以及产业参与者贡献相关技术,来确保能够及时做出基于标准的解决方案。