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

尽管任何事物都不能阻止开发人员从其最爱的轻型容器中使 JAX* 规范，而 J2EE 1.4 规范直接将 JAXRPC 和 JAXB 整合到它的总体技术套件中，从而使您可以将 EJB 无状态会话 bean 提供为 WSL 1.1/SOAP 1.1 RPC/encoded Web 服务。（请注意，根据 WS-Interoperability Basic Profile 规范，RPC/编码的服务正式不支持文档/文字服务；人们普遍期望此差别在 JAX* 和 J2EE 规范的下个版本中得到解决，具体的实现应大概在开发人员实际指出RPC/编码的服务和文档/文字服务之间的差别时推出。）此外，商业应用服务器供应商正竭尽全力确保其产品不仅完全与 J2EE 标准兼容，而且还与 Web 服务标准兼容。显而易见，这种情况下用“兼容且具竞争力”来形容供应商的动机（包括 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）的尝试已经取得了多方面的成功，尤其是在跨不同浏览器方面。

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

为实现此目的，企业应用程序供应商正积极考虑将表示层代码置于最终用户的机器中，以便完全或部分消除 HTML 的两个主要缺点。这创造了一些有趣的部署暗示，但许多商店正寻求同时创建瘦客户端和富客户端表示层—富客户端用于公司防火墙的内部，而瘦客户端用于公司的外部（再次证明您不能太富或太瘦）。此方法招致了必须处理两个不同框架的麻烦，但至少我们愿意拥有一种将数据从用户输入传递到后端

凌众科技专业提供服务器租用、服务器托管、企业邮局、虚拟主机等服务，公司网站：http://www.lingzhong.cn 为了给广大客户了解更多的技术信息，本技术文章收集来源于网络,凌众科技尊重文章作者的版权，如果有涉及你的版权有必要删除你的文章，请和我们联系。以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢!