如何分析Seam Remoting API和Ajax4jsf

这篇文章将为大家详细讲解有关如何分析Seam Remoting API和Ajax4jsf，文章内容质量较高，因此小编分享给大家做个参考，希望大家阅读完这篇文章后对相关知识有一定的了解。

时下，大多数 Java 开发人员都很看好 mashup，所以您可能会困惑：Seam 与号称 Web 2.0 的技术，尤其是 Ajax，如何能集成。若能使用 Seam 启动 JSF 中的部分页面更新或者用 Google Map 协助 JSF 应用程序 mashup，那将非常酷，不是么?您不仅能这么做，而且还非常容易。

我将为您展示如何使用 Seam Remoting API和Ajax4jsf 组件来协助基于 JSF 应用程序中的 Ajax 风格的交互。正如您将会看到的，结合 Seam 和 Ajax 的最大好处在于它让您可以享用所有 Web 2.0 的奢侈东西，而同时又不需要陷于使用 JavaScript XMLHttpRequest 对象的痛苦之中。借助 Seam Remoting 和 Ajax4jsf，可以与服务器上的受管 bean 通信，就好像这些 bean 与浏览器同在本地一样。浏览器和服务器状态保持同步，而且永远无需处理促成它们之间通信的低层 API。

我首先会为您展示 Seam 是如何推动 Ajax 编程的基于组件的新方式的。您将学会如何使用 Seam Remoting API 来通过 Ajax 进行 JavaScript 和服务器端对象间的通信。一旦理解了这种面向 Ajax 的新(且简单的)方式，您就可以使用它来增强 Open 18 应用程序，方法如下：
◆在 Open 18 球场目录和 Google Maps 之间创建一个 mashup。
◆使用 Ajax4jsf 合并应用程序的球场目录页和球场细节页。
◆重新访问应用程序的 Spring 集成并让 Spring bean 在 Seam Remoting 的生命周期可用。

Open 18 和 Google Maps 之间的 mashup 让用户可以定位地图中的高尔夫球场目录中的位置。将此球场目录和球场细节页合并起来(并将低层代码 Ajax 化)可以让您显示球场的细节信息而无需加载新页。将 Spring bean 和 Seam Remoting 相集成让您可以捕获 Google Maps 位置标记的重定位并能将相关球场的经度和纬度存储到数据库中。如您所见，结果就是会产生所有高尔夫球员都喜欢使用的 Web 2.0 风格的应用程序，这真是让人印象深刻!

如果您曾经深受涉及到大量 JavaScript 的过于复杂的 Ajax 编程之苦，如果到目前为止，您都由于不想面对其复杂性而一直尽量避免使用 Ajax，那么本文所要教授的内容将会帮助您免除这种担心。在重构应用程序时，您需要进行一些 JavaScript 编码，但与大多数 Ajax 实现不同，JavaScript 并不会占据您代码中的大部分;相反，它只扩展了服务器端的 Java 对象。

通向 Ajax 的不同之路

正如在应用程序中希望避免显式的内存管理一样，您亦不 希望必须要处理低层的 Ajax 请求协议。这么做只会带来更大的麻烦(更确切地说，是更多的麻烦)，比如多浏览器支持、数据封送处理、并发冲突、服务器负载以及定制 servlet 和 servlet 过滤器。其中您想要避免的***的麻烦是无意间公开的无状态的请求-响应范例，但该范例是基于组件的框架，比如 JSF，所想要隐藏的。

JSF 生命周期通过对底层的 servlet 模型屏蔽应用程序代码促进了面向组件的设计。为了保持处理 Ajax 的这种抽象性，您可以将低层的这些琐碎工作交由 Seam Remoting 或 Ajax4jsf 处理。这两个库均可负责通过 Ajax 交互将 JSF 组件熔合到浏览器时所需的管道处理。图 1 显示了实际应用中的 Seam Remoting。当事件触发时，比如用户单击了一个按钮，消息就会异步发送给服务器上的组件。一旦收到响应，它就会用来对此页进行增量更新。用来处理浏览器和服务器端组件间的交互的低层通信协议都藏于 API 之后。

图 1. Seam Remoting 熔合 JSF 组件和浏览器

在图 1 所示的用例中，用户能看到单击按钮后所发生的方法调用的结果。在研究此用例时，有两个要点需要注意：
◆该页永远无法刷新;
◆客户端代码与组件上的方法进行透明通信，而不是显式地构建然后再请求 URL。标准的 HTTP 请求在后台使用，但客户端代码永远无需直接与 HTTP 协议交互。

Seam Remoting和Ajax4jsf

Seam Remoting和Ajax4jsf 是两个独特的库，可分别服务于 JSF 的 “Ajax 化” 的目的。两个库均使用 Ajax 来引入交互模型，其中浏览器和服务器间的通信可以在后台异步发生，并对用户不可见。没有必要为了执行服务器上的方法而浪费用户页面重载的时间。在这些库所发出的 Ajax 请求中由服务器检索到的信息可用来增量地 “实时” 更新页面的状态。两个库均可配备生命周期，此生命周期可以在浏览器需要的时候恢复(restore)组件的状态。这种 Ajax 交互并不是真的请求而是一种 “恢复并执行”。浏览器像是 “敲敲” 服务器的 “肩膀”，请它在服务器端的一个受管 bean 上执行一个方法并返回结果。

虽然这两个库工作起来有些差别，但它们并不是相互排斥的。由于它们都采用的是 JSF 组件模型，所以二者可以很容易地相互结合，这将在本文后面的部分详细介绍。目前，我们只需分别考虑二者各自将 Ajax 风格的交互引入 JSF 应用程序的方式：

Seam Remoting 提供了 JavaScript API，可以使用这些 API 来像访问本地对象一样来访问 JavaScript 中的服务器端组件，以便通过方法调用发送和检索数据。Seam Remoting 使用定制的、非 JSF 生命周期来使该浏览器能够与服务器端的组件通信。只有 Seam 容器和其组件可以在这些请求期间被恢复。透明协议是 Ajax，但您无需费心数据包如何传输的细节。

Ajax4jsf 则通过完全隐藏 JavaScript 的使用让抽象更进了一步。它将所有逻辑都包裹在基本 UI 组件内。Ajax4jsf 通过完整的 JSF 生命周期接受 Ajax 请求。因而，支持 Ajax 的组件可以在不触发浏览器导航事件的前提下执行动作处理程序、升级 JSF 组件树以及重新呈现该页的某些部分。同样地，通信也是通过 Ajax 实现的，但所有这些均在后台发生，页面开发人员不可见。Ajax4jsf 面向组件的方法让 Ajax 功能得以成为 JSF 很自然的一部分，而不是格格不入的外来者。

关于如何分析Seam Remoting API和Ajax4jsf就分享到这里了，希望以上内容可以对大家有一定的帮助，可以学到更多知识。如果觉得文章不错，可以把它分享出去让更多的人看到。