将允许我们直接通过基于HTML的表示层用来与业务逻辑层
通信的同一类型构建此类型。这就是某些JAX*
规范的用武之地--例如,JavaAPIforXMLBinding有助于定义一个以非常模糊的方式进行“对象到XML以及XML到对象”转换的标准方法,而JavaAPIforXMLRPC(JAX-RPC)定义一种使用WSDL、SOAP和XML构建可互操作的请求-响应远程通信层的方法。尽管任何事物都不能阻止开发人员从其最爱的轻型容器中使JAX*规范,而J2EE1.4规范直接将JAXRPC和JAXB整合到它的总体技术套件中,从而使您可以将EJB无状态会话bean提供为WSL1.1/SOAP1.1RPC/encodedWeb服务。(请注意,根据WS-InteroperabilityBasicProfile规范,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映射整合到核心产品(如OracleToplink)中,但到目前为止,它们仍处于初始阶段。
同时,我们不能忽略那些旨在填补传统的基于浏览器应用程序中的大漏洞以实现“更大的响应性”的新潮表示层方法(“智能”客户端或“富”客户端”)。
HTML尽管有很多优点,但也存在一些根本性的缺点,很容易地就想到了两个:
最小公分母角度。HTML最初用于尽可能晚地推迟表示决策,标准HTML中实际上只有非常少的元素保证在任何给定系统上的呈现外观。为页面生成器提供更大控制(如CSS)的尝试已经取得了多方面的成功,尤其是在跨不同浏览器方面。
表示代码必须与内容一起发送。由于浏览器本身不了解应用程序,因此必须在每个
网络往返中向服务器发送表示代码和内容。此方法有两个