精通J2EE应用程序开发之交叉分析J2EE

　　顺便说的是，打算构建 Web 服务表示 facet 时，值得一提的是，最好使用 JAXB 或 Oracle 的开发人员工具包将系统的模型对象直接提供为 XML 类型，并将整个 Web 服务前端代码生成为大型 WSDL 文档。尽管这起初似乎是某个用户的业务逻辑层的良好验证（毕竟，如果表示层中真的没有什么业务规则，那么采用此方法其实并不困难），但 Web 服务技术套件中的限制很快便使这个期望变得很难实现。

　　例如，考虑基于引用的对象与 XML 的关系：应如何最佳地表示一个在 XML 中值为空的 java.util.Date 引用？尤其是在 .NET 中，Date 根本不是基于引用的对象，而是“值类型”，这意味着它的作用类似于 int 在 Java 中的作用吗？当尝试表示 XML 对象的复杂循环图时，事情将变得非常棘手，这就是为什么原来反对 RPC/编码的服务的原因之一。这是 WS-* 套件背后所要做的所有工作，但即使某个团队决定“走自己的路”并构建他们自己的 XML-over-HTTP 系统，他们也要面对同一核心问题。正在尝试将对象-XML 映射整合到核心产品（如 Oracle Toplink）中，但到目前为止，它们仍处于初始阶段。

　　同时，我们不能忽略那些旨在填补传统的基于浏览器应用程序中的大漏洞以实现“更大的响应性”的新潮表示层方法（“智能”客户端或“富”客户端”）。HTML 尽管有很多优点，但也存在一些根本性的缺点，很容易地就想到了两个：

　　最小公分母角度。HTML 最初用于尽可能晚地推迟表示决策，标准 HTML 中实际上只有非常少的元素保证在任何给定系统上的呈现外观。为页面生成器提供更大控制（如 CSS）的尝试已经取得了多方面的成功，尤其是在跨不同浏览器方面。

　　表示代码必须与内容一起发送。由于浏览器本身不了解应用程序，因此必须在每个网络往返中向服务器发送表示代码和内容。此方法有两个负面影响，一个是带宽较低（每个客户端的消耗越高，同一硬件的客户端数越少），另一个是可用性遭到破坏（如果服务器或介入的任何拓扑出现故障，则应用程序将不存在）。