客户端的Java同样精彩

核心提示：谈起java，人们一般总是关注着在服务器端应用的种种技术，客户端的Java同样精彩，确实，在这里Java拥有其它技术所不可比拟的优势，而剩下的工作都由软件来帮你完成，WebCream的标准版提供全部的功能，然而任何一个应用程序总要有一个用户界面或其它前端表现形式，大概有不少人听说过那句隐喻“Java棺材上最后的那个钉子

　　谈起java，人们一般总是关注着在服务器端应用的种种技术，确实，在这里Java拥有其它技术所不可比拟的优势。然而任何一个应用程序总要有一个用户界面或其它前端表现形式，大概有不少人听说过那句隐喻“Java棺材上最后的那个钉子”——它暗示的是：在前端使用除了基于Html之外的技术都无异于自掘坟墓，然而事实却并不是这样！下面将介绍除了老式的HTML客户端外，开发用户界面的三种主要方案。
　　
　　一.使用jsp和servlet的HTML客户端
　　你也许已经写过不少servlet和JSP，而且也听说过不少对基于HTML的客户端的拥护和反对意见。选择这种技术的最大好处就是它对于平台的广泛适应性——基本的HTML已经被很好地标准化了，而且由于HTTP和HTTPS协议的简单性，你还可以很轻松地为各种不同的防火墙和网络编程。但任何事物都有两面性，HTML的缺点是与用户的互动性不足，而且针对用户动作的即时响应不够快。尽管有javascript的存在，但它只是一个为HTML页面添加简单逻辑的语言，当需要开发一种能够让用户感到仿佛具有智能般的复杂用户界面时，它就无能为力了。
　　
　　总之，一个使用servlet和JSP的HTML客户端在处理静态内容时无疑是非常方便的，但当你希望能为用户的动作提供更快速响应并能够处理比较复杂的逻辑时，这样的瘦客户端就很难有什么良好表现了。
　　
　　二.基于xml和XSLT的客户端
　　用XML所做的客户端有一个非常显著的特色，这就是内容与表现的清楚分离，这显然对于让它们独立地完成自己的任务大有好处。然而这个方案并不是万灵药，在开发基于XML的客户端时，开发者会碰到了两处重大困难，一是开发工具的缺乏，二是代码执行速度过于缓慢。
　　
　　第一个困难对现在已经非常熟悉了可视化HTML开发工具的人们来说真是非常棘手，很多人在使用此类工具时会不时地直接浏览并编辑部分代码，但决不会直接拿一个文本编辑器去直接写全部代码，然而现在确实还没有一款能够让人满足的可视化XML开发工具，大量的XML开发工作都需要手动完成。
　　
　　造成第二个困难的原因是：XML的处理过程中有很多步骤是在运行时完成的，而且像目前应用于servlet或JSP的优化缓存读写技术在这里都没有。
　　
　　三.基于Swing的图形用户界面客户端
　　Swing的内部结构的优雅和它的类、界面的设计中的周密考虑都是值得称道的，它很好地界定了容器、组件以及用户元素之间的关系，并且它的基本架构基于MVC(Model-View-Controller)设计模式，使得它可以把数据表现和数据操作相互分离。
　　
　　随着每个新版JDK的发布，Swing类的性能都在不断改善。在JDK1.3中，Swing类的执行效率、内存占用和输入确认框架的完备性都有了很大的提高。尤其是效率和内存占用上的改善简直让人惊异。
　　
　　自始至终总是伴随着Swing的最常见的两个麻烦是速度和部署时的兼容性问题，而这两个弱点在今天已经被比较好地克服了。CPU的速度在过去几年中几乎提高了一倍，而且伴随着1.3版JDK的推出，Swing类对象的内存占用大大降低了，这些因素使得用Swing类的应用程序的执行速度已经完全可以接受了。下面就让我们来看看最后一个实质性的障碍——部署问题。要解决这个问题，通常有下面三种方案可供选择。
　　
　　Java插件
　　Sun的Java插件有一个非常显著的优点：只要对你的HTML网页做简单的修改，就可以消除对特定浏览器的Java虚拟机的依靠，并使你的applet运行于Sun的标准虚拟机中。
　　Java Web Start
　　使用Sun的Java Web Start是一种比较新的部署Java应用程序的方法。本质上它与Java插件类似。但在使用时的第一个步骤上有显著的不同，当在桌面系统中使用时，Java Web Start需要一个手动的安装过程，这显然比由浏览器自动进行的插件安装过程要麻烦得多。Java Web Start提供Java运行环境，并且设定的过程并不复杂，这个过程完成后，需要依靠Web Start的应用程序就可以被下载和安装了，这些程序各自独立地运行于Java Web Start应用程序治理器中，而这个治理器看起来非常像Windows3.1的任务治理器。
　　将Swing部署为纯HTML
　　HTML前端和Swing客户端都有自己的优缺点，将二者结合起来似乎能提供最好的解决方案，然而这二者之间的差异实在是太大了，看起来似乎只能应用其中一种。尽管多数的用户可能更偏爱基于Swing的客户端，但有时候漫长的下载时间似乎也是很让人难以忍受的，而且有时候由于安全和防火墙的限制，通过网络进行远程方法调用是很困难的。这种情况下，我们所能依靠的客户端环境只有浏览器，但我们仍然希望能让自己的互动客户端在任何系统上都跑得起来，这时我们就需要一个第三方的工具来起到沟通Swing和HTML的桥梁的作用，下面介绍一个此类工具中的典型产品WebCream。
　　
　　WebCream可以让你执行使用了AWT和Swing的图形客户端，从某种意义上讲，你可以把这个软件理解为一个动态的Java到HTML的转换器，它使得Java的框架窗体与对话框等等图形界面元素在只有HTML解释器的环境中也可以被显示和响应。它通过将网页动作仿真为图形用户界面事件，从而使其完全保留了应用程序原本的内部逻辑。WebCream不要求对现有表单和商业逻辑做任何修改，也不需要你学习任何新的API，因为它本来就是为了使用已有的应用程序和applet而设计的，你所要做的只是对一些属性进行设定，而剩下的工作都由软件来帮你完成。WebCream的标准版提供全部的功能，而且也是免费的。