AJAX 及使用 E4X 编写 Web 服务脚本，第 2 部分：用 E4X 创建新的 Web 服务

核心提示： 这个模型依赖于可以完整解析和管理整个 SOAPEnvelope 的编码器，而更一般的情况是，AJAX 及使用 E4X 编写 Web 服务脚本，第 2 部分：用 E4X 创建新的 Web 服务(2)，我们希望使用一种稍微不同的模型，就是把对 SOAPEnvelope 的处理一分为二，我们这里所采用

这个模型依赖于可以完整解析和管理整个 SOAPEnvelope 的编码器。而更一般的情况是，我们希望使用一种稍微不同的模型，就是把对 SOAPEnvelope 的处理一分为二。在该模型中，一系列的“headler”用于处理 SOAP 消息头部，而“业务逻辑”处理消息主体。两种模型都有自身的优缺点，由于在 E4X 中拥有强大而易用的 XML 处理能力，因此我们可以轻松地使用这两种模型。

只含有消息体的签名看起来很类似：

function　service（soapBody）　{　
　　//　do　things　
　　return　newSoapBody;　
}　

我们将如何部署符合这个模型的服务？为了实现这一目的，我们在这篇文章中的例子里 提供了一种“宿主”技术——Apache Axis 提供者。提供者是这样一种方式：Axis 允许可插拔地插入新的服务提供者程序，而 E4X 提供者允许用户使用 E4X 脚本实现服务。

事实上，我们还有另外两种选择没有提到。第一种是在 J2EE 应用服务器中将 Rhino 和 E4X 插入到使用 JAX-RPC 和企业 Web 服务（EWS，也称作 JSR109）技术中。然而，这实际上有一定的困难，因为这些标准对于请求者与提供者采用标准的方法去访问整个 SOAP 包时并不容易。

总的来说，一个 Web 服务的容器（正如 Axis 或者一个实现 EWS 的 J2EE 服务器）为我们做了两件事。首先，这些容器具有工具与运行时环境支持使得在网络中传递的 XML 消息被映射成运行时系统中程序员所使用的对象。其次，他们通常为附加的 Web 服务标准提供支持，比如 Web 服务寻址（WS-Addressing）、Web 服务安全（WS-Security）和在消息中加入新的报头并且转换的 WS 事务（WS-Transactions），比如通过加密 XML 消息。我们这里所采用的方法将去除了在第一个方面的需要，因为这时我们已经将 XML 作为一个直接使用的本机对象，而不用再次的映射操作。