在这里只是简单的介绍一些企业应用开发应该采纳和借鉴的一些展现层技术、架构和开发方式，之所以称它们为新，主要是针对技术和趋势而言，其实他们的概念已经不算是太新的了（已经存在一段时间了），正是因为如此，它们更加具有可借鉴的价值。
浏览器胖客户端技术：
无论如何说、无论采用何种技术目前的三层分布式企业级应用也都是网络应用，它在本质上与其他的网络应用是有相似性的，我们可以在它们之间作一个类比。
就在不远的以前，网站的用户界面也是静态的，虽然很多网站提供了服务端动态网页的支持，但是用户看到的却还是一张张静态的网页。用户与网站之间是一个请求
和交互的过程（本质上就是这样，看上去也是这样），用户通过超链接在一个个动态/静态的页面之间浏览。而所有的处理全部是由服务器来进行的。大多数能够即
时响应客户的是Flash或者Applet这种浏览器的插件。当然客户端动态网页的技术当时也已经存在很长时间了，但是并没有得到太多的重视。
但是，近几年来，动态网页无刷新技术逐渐兴起起来，它充分利用了客户端浏览器所具备的计算能力，通过借助于DHTML容器的事件机制和非提交形式HTTP
访问服务器的方法实现了可以在客户端自行处理用户请求的基于浏览器的胖客户端，使得使用界面更加友好和易用，而且还在相当的程度上减轻了服务器处理的负
担。
再拿二层的分布式企业级应用来作纵向比较，虽然抽象出应用服务器这一层对于数据库服务器是一种解脱（也为SOA打下了基础），但是由于当时的网络应用的技
术所限，真正的用户体验是下降了的，胖客户端的安装和升级确实比较麻烦，但是一般说来客户端的安装问题只是部署和维护企业级应用系统的一个很小的问题。但
对于底层的实际用户而言，基于网络HTML技术的客户端界面可能会好看一些，但是效率、操作性、实时反应的能力都是下降了的。对于底层的用户而言，键盘操
作要比鼠标操作工作效率更高。企业级应用的系统是要给企业做的，而企业的主要目标是创造最大利润，在这一点上其实很多三层的企业级应用都是对企业级应用所
要达成的目标的一种背离。但是，这主要是因为当时的技术所限，就算是最能代表当时网络技术的大型商业网站，他们的用户界面也几乎全是静态的HTML网页。
综上所述，可以看出三层分布式的企业级应用系统应该在展现层进行一次革新，应该尽可能的采用浏览器胖客户端的技术，这样一方面可以充分利用客户端的计算能
力和资源，缓解服务端压力，还可以通过快捷键、自定义快捷方式甚至自定义宏的方式提高用户的使用效率和使用体验。
服务端组件化开发技术：
Struts
是一个很好的框架，它的灵活性和稳定性是有目共睹的。但是无论如何它给开发人员带来的工作量和调试起来的难度也是很多的（尤其是在没有充分体现出分层概念
的企业级应用系统中）。其实难度最终是要转化到网络应用的开发上去的。三层的企业级应用系统也是网络应用，而对于网络应用而言，业务开发人员和美工（又叫
WebUI？）人员的分工也是比较头疼的问题。JSP等模板技术于是应运而生，但其实这不过是一种善意的谎言。对于JSP而言业务开发人员还是必须对
HTML有比较深的了解，而且最头疼的是，除非你把它放在Web容器中运行，否则你决不会知道它到底是一个什么样子（除非你把你自己的大脑变成一个Web
容器加上一个浏览器），JSP Tag的出现并不能解决什么问题，从本质上来说它就是JSP概念的一个延展，可以节省代码而已（而且带来更多的复杂度）。
难道真的没有办法了吗？
我们纵向对比一下二层的企业级应用，它开发和维护起来就没有三层那么麻烦。原因何在？组件已经封装了绝大多部分的工作，你所需要的只是应用组件、配置组件、添加事件处理代码而已。
从这个方面上来说，还有什么DHTML更好的用户界面描述语言？设想一下，你可以试图拿Swing（为什么Swing？——平台无关）写一个可以在运行时
动态的改变界面结构、通过样式描述文件动态改变组件样式的程序（这一切可以跟一个或多个很完善的脚本语言无缝集成），它会多复杂？
还记得桌面应用的开发吗？没有一个像样的桌面程序没有自定义组件的，但是它们的自定义组件大多数其实只是基础组件的组合。
同理，也可以对HTML进行如此开发。
下面给出解决的架构。
展现层开发架构：
开发要明确体现出客户端、应用服务器端、数据库服务器端的三层概念。数据库服务端的开发与展现层无关略去不讲。
- 客户端开发：使用JavaScript进行事件处理响应用户的操作，对组件进行相应的操作，如有必要可以采取远程服务器端服务调用（既可以调用自己服务器提供的服务也可以调用其他的公用网络服务，符合SOA的要求）的方式。
- 服
务端开发：展现层组件分为两部分，动态网页组件和JavaScript组件。动态网页组件采用基于组件化的动态网页框架（比如Tapesrty，为什么不
用JSF稍后再讲）。另外服务端开发还有业务逻辑处理服务，其中业务逻辑处理属于业务逻辑层不再多说，而业务逻辑处理服务和服务的远程调用以及相应的安全
处理可以采用Spring + Acegi +
DWR的方式（这样可以既可以实现JavaScript客户端远程调用业务逻辑服务，还可以很容易的实现服务的安全公开化，符合SOA的要求）。
为什么这么看重Tapestry而不用JSF呢？
- JSF
的标准还是跟JSP绑在一块的，虽然有Facelet的存在，但是本身摆脱不了JSP的JSF还是会被JSP所拖累的。我并没有说JSP一无是处，作为模
板技术而言，JSP已经非常成功了，但是对于JavaScript胖客户端开发而言，JSP本身容器相关的特性实在是没什么好处。
- 目前
而言JavaScript是可以进行单元测试的，而Tapestry的Html模板技术使得JavaScript和Html的集成测试达到可能。你可以完
全不管Tapestry而调试JavaScript，调试成功以后再加上Tapestry的组件标签就可以了。你可以为重要的JavaScript（一些
起粘结作用的Script就没有必要测试了）写测试脚本进行测试，而这些全部都是远离Web容器的。
我们的开发人员为什么要远离JavaScript呢？因为它是动态解释语言？Ruby也是。只要测试到位，动态语言也可以实现稳定的系统。
运行的效率低？也许吧，但总高过整个页面刷新，我说的不过分吧。
开发人员对JavaScript认识不够，没有很好的IDE支持？事实上，根本不必让开发人员对它认识“够”，因为他所写的主要是一些GlueCode，
配置一下组件，把组件之间通过事件结合起来。当然，这些有一部分你可以自己发明一些XML来达到，值得吗？我个人认为写动态脚本也好过写XML（别跟我说
你还可以写个DTD）。至于IDE的话，我认为，写JavaScript根本用不着，尤其是在你根本不会写很多的时候。只要有一个浏览器和浏览器支持的
JavaScript调试器足够了。只要组件化做好了，再结合工程模板，那么开发人员就象回到了二层的时代，选择相应的组件，组合然后就是调试了。比两层
有优势的一点是，他不必启动服务器就可以调试客户端。
这一方面的网络应用开发先驱是Google（可惜，他们没用JavaEE技术，呵呵），到现在已经成为一种风潮，对企业级应用开发赶时髦是没有必要的，但
是技术的发展带来了新的可能，不管是在开发方面还是在客户体验和客户效率提高上都会有更好的机会，为什么不把握这个机会呢？
末了，SOA完全可以评为今年的软件开发最流行关键词。呵呵。它的核心概念是什么呢？不要浪费现有的IT资源。
我们现在对于网络和计算机技术的资源开发和应用的大部分都处于浪费状态，有政治原因、有商业原因但是还有技术原因。能够尽可能有效的利用手中现有的资源，对于企业的发展也有相当的积极作用。