它只是通过web浏览器进行的基本请求/响应
通信,通常构建在类似Struts或相似的MVC样式web框架中,并与一组核心的传统Java对象(有时与单个机器上运行的表示层和业务逻辑层(而非数据库本身))进行通信。(您可能奇怪此处为什么没有使用术语“数据库”。原因很简单,虽然大多数项目使用数据库(而且还是关系数据库)存储数据,但数据存储通常是原有系统、商业软件程序包或形如CICS大型机、SAP或BizTalk的“中介”技术。使用更一般的术语“资源”有助于强调这样一个看法:后端实现确实与本讨论无关。)烟囱应用程序的另一个优势是它们通常是“独立的”—也就是说不涉及其他应用程序。几乎不需要遵守任何已建立的安全、可靠性或管理标准,这是因为此应用程序所确立的所有内容都将成为标准(至少对此应用程序而言是这样,这正是此范围的关键所在)。开发人员经常利用此事实来构建正好适合于此应用程序的基础架构,从而消除了通常针对企业Java应用程序的指责:它们太复杂了,以至于无法使用和维护。尽管人们希望如此,但J2EE的设计并非是针对烟囱应用程序的—当然,一个基于J2EE的应用程序可以构建此类应用程序(并且有上千个示例可以作为此事实的证据),事实上有点像用牛刀杀鸡。基于J2EE的应用程序实施了一定程度的层划分,但有时这种划分对于解决手头的问题显得有些矫枉过正,如传统的“10用户”烟囱系统。当然,问题是10用户烟囱系统通常有一种另人不悦的趋势,即转变为其他四个版本中的某个版本,这样将使事情变得很糟。就像某位哲学家说的那样“没有哪个人是孤立的”,我们也可以很轻松和准确地说“没有哪个系统是孤立的”。至少在短期内是这样。(当然,如果系统无法完成其预期的目标,那它就无法与任何其他系统集成,并且可能停产,但我们将假设那不是预期的目标。)珠宝我们并不是说这是IT环境的成功和骄傲或五种应用程序样式中“最好”的一个,但珠宝样式的应用程序是结合了多个表示层的应用程序(因此,它的名称--“珠宝”表示有很多面可供查看)。但请注意,给定表示层可能根本不是供用户查看的;公司当前经常探讨的一个层是其基于Web服务的应用程序前端,它并非为人使用而设。尽管如此,该Web服务仍表示一个表示层,这是因为它从根本上执行同一操作:获取输入并从其下面的核心业务逻辑层中提供输出。
由于一度曾存在的某些假设突然间不复存在了,珠宝应用程序对传统编程模型进行了一些有趣的转变。例如,当考虑一个Web服务前端时,突然必须以某种平台和语言无关的方式(对此,XML模式是当前可以选择的工具)定义类型,而理想情况下,“一次且仅此一次”规则(也称作“不重复自身”原则)将允许我们直接通过基于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)的尝试已经取得了多方面的成功,尤其是在跨不同浏览器方面。