Java客户端工具选择：HTML？Swing？XML？

整理下面的文章是由于我的以为写的很好，关于java的客户端了解也并非太多。看了下面的文章以为颇有必要贴出来，方便本身之后了解java客户端编程。

Java软件设计师和管理人员常常会面临这样的难题：在开发应用软件的客户端时，应该在Swing、HTML、XML三种技术中选择谁。在这篇文章中，我将把本身在这三种技术方面的经验与广大读者共享，并对在Java应用软件开发中选择哪种技术提出一些标准和技巧。在文章的最后，还会介绍一种整合Java Swing和HTML的新方法。

　　与现有的技术相比，Java有明显的优势，所以它已经在服务器端应用软件的开发中确立了主导地位。然而，因为每个应用程序都有几种形式的用户界面和前端的表达形式，咱们中的许多人都对在客户端采用Java技术有很差的印象，所以在客户端的开发中采用HTML彷佛已经成为惟一的选择了。好比说我，在java客户端这块，我基本是在玩HTML。

　　实际状况是，在客户端应用程序的开发中不止只有HTML一种选择，咱们将在本文讨论基于Java的应用软件开发中三种用户界面的解决方案。我将首先讨论HTML与JSP和servlet联合使用的优势和缺点，而后讨论Java最初的目标之一：经过GUI Applet实现交互式互联网。最后，咱们将讨论XML以及由它所衍生出来的其余技术。

• 　　JSP/Servlets环境下的HTML客户端

　　大多数读者都曾编写过servlet、开发过JSP应用，清楚基于HTML的用户界面的优势和缺点。选择HTML的最大的理由仍然是其普遍的平台适应性，基本HTML的标准性很好，虽然比较枯燥，但它能够很好地完成工做。

　　因为HTTP/HTTPS协议很是简单，可使开发的应用程序很好地适应各类网络配置和防火墻。但这是有代价的，HTML缺少与用户的交互性，并且对用户每一个行为的响应都须要与服务器进行链接。做为一名编程人员，咱们一直在追求简单性，并使开发的软件能够适合全部的浏览器？然而简单性并不老是好的，简单地说，与静态HTML相比，JavaScript能够较好地实现不太复杂的交互性，但对于开发复杂的用户界面而言，它仍是不能胜任的。

　　除非拥有高速的互联网链接，不然你必定有过焦急的等待加载一个网页的经历。尽管瘦客户端提供了一些很好的非交互性的用户界面，但传统的胖客户终端通常状况下都比它们更聪明。例如，Netscape Communicator和MS Outlook等电子邮件的前端就比基于互联网的电子邮件工具具备更好的用户亲和性。

　　用Java开发一个HTML前端应用是一个很好的选择，由于HTML提供了跨平台的内容传输能力。编程人员可使用Java Servlets和JSP开发在任何操做系统平台上运行的服务器端应用程序。同时考虑到众多的Java API和它获得的普遍的服务器开发商的支持，对于开发可伸缩互联网站而言，Java是一种理想的选择。

　　总而言之，配合使用Servlets和JSP的HTML前端开发工具是开发静态界面的很好的方式，但当须要对用户的行为做出快速反应和须要对数据进行高速处理的复杂应用时，这种方式则不大理想。

• 　基于Swing的GUI客户端

　　今天还有多少人在使用Java Applet做为客户端？也许使用基于HTML的UI更安全，但这是最好的选择吗？

　　AT&T的一个业务部门Telecorp PCS曾经开发过一个应用程序，使其商店能够收集但愿购买移动电话的用户的资料，检查其信用卡，而后当即开通移动电话，除了确认用户输入的信息外，应用还必须经过使用排序、选择和其余的标准数据库功能处理提交的报告。此外，当一个新的移动电话开通后，这个应用程序还须要显示一个通知。

　　你能相像用HTML来完成这一切吗？也许可能，但它将很是讨厌，并且速度很慢，须要不间断地使用网络链接。Telecorp PCS决定冒险在交互的Applet中使用Java，那么结果如何呢？彻底成功，这一应用程序在开发时采用了Swing，并布署在采用了Java插件的互联网网站上。经过使用Swing UI类，很简单地完成了应用所要求的功能。

　　我相信许多开发人员在早期使用Java时，都使用过applet，而且在解决各类浏览器之间的不兼容性、applet下载时间、性能方面花费过大量的时间。对客户端Java最大的批评来自其对象性，但如今状况已经有了很大的改观。Sun已经花费了大量的时间来改进其代码的质量，下面我将向你说明为何基于Swing的UI是值得一试的。

•  　　Swing及其布署模式

　　我无需对Swing的内部架构以及类和界面的设计、设计模板的实现方面有多少新思想多做叙述了。Swing几乎是我见过的最完全的窗体系统，它的容器、组件和UI元素之间的关系很是清晰。Swing的架构是基于Model-View-Controller（MVC）设计模板的，其数据与数据的表达和处理相互独立。

　　大多数的Swing模型都是由各类UI元素共享的。例如，JTable使用和JList、JTree相同的模型集，这就使得学习和使用Swing很是简单,并且Command、Observable和Listener等模板提供了很好的灵活性和良好的面向对象特性。也许Swing架构中惟一的不足之处是全部的事件都被交付到相同的EventDispatch线程中，使整个GUI客户端应用程序只有一个线程。但咱们能够经过使用不一样的线程响应用户的命令而不经过EventDispatch线程来完成全部操做，就能够很简单地克服Swing这一缺点。

　　Sun发布的每一个JDK版本都对Java和Swing的性能都进行了改进。JDK 1.3中与Swing相关的改进表如今性能、内存消耗和一个输入确认框架。性能和内存消耗方面的改进至关可观。咱们公司将客户端的应用程序由JDK 1.2.2升级到1.3后，内存消耗下降了30%，一些应用程序内存占用减小得更多。因为Swing内部的初始化过程被优化了，咱们的客户端应用程序的运行速度和响应速度都更快了。简而言之，对速度影响最大的是加载其余界面组件时自动产生的大量的类，而这一方案中只包含有一个类。另外一个重大的变化是缺省的JVM是HotSpot Client VM，它专门针对GUI绘制和客户端应用程序执行进行了优化，能够经过在命令行方式下运行java命令获得缺省的JVM。
　　
　　输入确认框可使咱们很方便地经过编程实现命令字段或输入确认。在这之前，若是要在处理下一个字段以前，对前一个用户输入进行处理，必须在该部件上添加一个监听程序，每当该部件再也不是焦点后都须要对它进行确认，这种方式很是单调和乏味。使用新的InputVerifier类，能够经过建立InputVerifier子类的一个实例，并将它赋予须要确认的JComponent，就能达到相同的目的。在焦点转换以前，部件将自动地调用verify()方法。

Swing存在的问题在于布署时的速度和兼容性问题。如今，它的一个重大改进解决了这些问题并使Java客户端应用程序从新成为一个可行的选择，CPU的速度在过去2年中翻了一番。在JDK 1.3中，基于Swing的应用程序的运行速度已经很是快了，所须要的内存也至关少。这就使咱们在布署Swing方面还存在着最后一个问题，那就是如何进行布署，在这里，咱们有三种解决方案可供选择。

　　方案一：Java插件

　　基于浏览器的Java中最精彩的特性之一是Java插件。对HTML网页做简单的修改就可以消除对浏览器JVM的依赖，并使咱们能够在Sun的标准JVM中运行Applet。一旦安装了JRE，Applet就被下载到本地磁盘上，并被放置在高速缓冲区中，再打开带Applet的HTML网页的速度就会快许多，缘由是全部的东西都是在本地磁盘上的。为说明其工做原理，咱们首先来看看原来的Applet布署方式，HTML网页是如何使用插件的，咱们假设你已经掌握了HTML和Java Applet的有关知识，并建立了以下的网页：

[TABLE][TR][TD][B]＜HTML＞
＜HEAD＞
＜TITLE＞My traditional applet page＜/TITLE＞
＜/HEAD＞
＜BODY＞
＜APPLET CODE=HelloWorld.class ARCHIVE=HelloWorld.jar＞
Sorry, looks like I bumped into another browser that doesn't support Java applets
＜/APPLET＞
＜/BODY＞ 

[/B][/TD][/TR][/TABLE]

　　这种方式的缺点是它依赖浏览器JVM来加载和执行HelloWorld类。考虑到市场上存在有多种浏览器，它们执行Java的方式各不相同，使得Applet的布署成为一件使人恐惧的事。你必须保证在通过测试的JVM中运行Applet。咱们不要求浏览器运行Java，而要求浏览器安装和运行咱们将要在其中运行Applet的JVM。在IE中，咱们能够经过使用＜OBJECT＞标志来完成这一任务，在其余的浏览器中，这一标志可能会有所不一样，例如在Netscape Navigator中是＜EMBED＞。修改后的网页以下所示：

[TABLE][TR][TD][B]＜HTML＞
＜HEAD＞
＜TITLE＞My new applet page＜/TITLE＞
＜/HEAD＞
＜BODY＞
＜OBJECT classid="clsid:8AD9C840-044E-11D1-B3E9-00805F499D93" 
width=100% height=100
codebase="./j2re-1_3_0_02-win.exe#Version=1,3,0,2"＞
＜param name="code" value="HelloWorld.class"＞
＜param name="archive" value="HelloWorld.jar"＞
＜param name="cache_archive" value="HelloWorld.jar"＞
＜param name="cache_option" value="Plugin"＞
＜/OBJECT＞
＜/BODY＞
[/B][/TD][/TR][/TABLE]
上面的网页将使浏览器检查指定ClassID的对象是否已经安装，若是没有安装，则从指定的URL下载JVM，并进行安装。而后浏览器执行插件，并下载和显示Applet。

　　插件带来的好处是它能够支持各类操做平台上的全部浏览器，此外，它还提供了一个有保障的执行环境，插件只须要安装一次，就能够对全部Applet进行缓冲，使再次访问网站时很是容易。这一方法的一个最大不足之处是，在运行Applet以前，必须下载一个大小为5MB的插件，这在低速的互联网链接上尤为使人不能容忍。事实上，若是你的Applet只是一个大小为5KB的网页顶端的一个钟表，为此而下载一个5MB的插件是得不偿失的。


　　方案二：使用Java Web Start

　　布署Java应用软件的另外一种方式是Sun公司的Java Web Start，它在本质上与Java插件类似，只是在第一个步骤上有明显的不一样。Java Web Start要求在每台台式机上进行人工安装，这一点远不如插件的自动安装。Java Web Start的安装至关简单，一旦安装完毕，依赖Java Web Start的应用程序就能够被下载和安装。就象插件同样，应用程序也是经过互联网发行的。


　　根据个人经验，Java插件在安装上与Java Web Start类似，但比Java Web Start的用户亲和性更好，缘由是它要求的管理员或用户干预更少。也有一些公司建立了本身的功能相似的布署工具，这些工具备时候比Java Web Start还好用。例如，Sitraka公司的DeployDirector在性能上优于Java Web Start，而且安装也更简单。


　　总而言之，经过使用Java插件和Java Web Start，基于Swing的应用程序的布署比原来要简单和安全许多，但仍然比点击一个只有JavaScript的HTML网页要复杂得多。并且有些用户可能对在本地机器上安装JVM所须要完成的步骤有被胁迫的感受，或者没有发现Swing所带来的好处，但若是须要一个动态GUI用户界面，使用户享有更多地灵活性，没有一种方法比采用Swing Applet更好了。


　　此外，若是整个开发都是基于Java的，在HTML请求数据和应用程序内部结构之间就无需进行映射。RMI能够提供快速的双向网络调用，它能够回叫客户端应用程序，提醒用户根据服务器的要求更新显示内容。


　　方案3、以纯HTML方式布署Java Swing

　　尽管HTML和Swing在开发客户端应用软件方面各有利弊，但很明显的是，理想的解决方案应该是两者都支持。然而，因为这二种技术在本质上具备较大的区别，在一个应用程序中只能采用两者之一。尽管大多数用户都会喜欢基于Swing的快速交互客户端应用程序，但下载并在客户端系统上安装JRE并不是老是一个很好的选择。有时候，安全和防火墙方面的限制使得RMI很难在网络上运行。在这种状况下，咱们须要的是一种能够在全部系统上运行的交互式客户端应用程序，即便咱们可以使用的客户端应用程序只有浏览器。CreamTec公司的WebCream能够充当Swing-HTML之间的桥梁。

　　WebCream是一种Java工具，它能够为基于GUI的Java应用程序和Applet提供自动的互联网访问，可使咱们利用AWT和Swing实现GUI前端应用程序，同时，能够自动地使HTML访问该应用程序。在必定程度上，能够把WebCream看做是动态的Java-to-HTML转换工具，它能够即时地把Java中的框架和对话转换为HTML。而后，将Webpage行为模仿为GUI事件，以保持应用程序原有的逻辑。WebCream不要求对现有的表格和业务逻辑进行修改，也无需学习任何新的API，它旨在发行现有的应用程序和applets。WebCream只是设置互联网服务器和描述应用程序属性文件的工具，它的标准版具备所有的功能，并且是免费的。WebCream还无需在客户端的机器上进行安装，甚至无需浏览器支持Java，由于浏览器接收到的所有都是HTML代码。


　　据所我知，只有WebCream才具备这样的功能，没有其余的工具能够提供类似的解决方案。但也有一些产品采用不一样的方法使本来不是为互联网设计的应用程序具备互联网访问功能。Windows 2000中有一种内置的终端服务器（Terminal Server）服务，可使用户只要在本地系统登陆就能够经过远程方式访问服务器。象Citrix系统公司的MetaFrame那样，终端服务器向远程终端发送一个视频流，并为在服务器上运行的应用程序模仿用户的行为。它在高速网络上能够很好地运行，在低速网络上的表现则不尽人意。它在Java应用程序方面还有问题，由于它们不使用本机的绘制和滚动例程。终端服务器的可伸缩性还不太强，缘由是每一个用户都在运行它的一个拷贝。由WebCream转换过的应用程序在形式上与在本地系统上运行的应用程序有所不一样，但它的性能更好，由于只有用户在提交一个页面时，才会与服务器进行链接。全部由具备WebCream功能的应用程序服务的用户能够共享一个JVM，所以也能够大大下降资源的消耗。

　　Swing-HTML转换方式并不适合全部的用户，WebCream在必定程度上容许经过HTML访问前端应用而提升基于Swing的前端应用程序的价值。有95%的应用程序能够无缝地转换成HTML，另有5%的程序则须要改变数据的表达和处理方式。

• 基于XML/XSLT的客户端应用程序

      在这里，咱们假定你已经对XML有了基本的理解，我将重点讨论其前端应用程序的开发。与XML相关的用户界面开发的一个主要特征是内容和表达方法之间互不干涉。简单地说，就是数据被保存为XML文档，而再也不负责数据的使用和显示，根据决定数据格式和在网页上输出方式的样式表（XSLT）在HTML、WML、XHTML和其余表达形式中选择一种数据表达形式。经过使各层之间保持相对的独立，让每一个层处理各自的任务，这种方法的优势是很是明显的。


　　尽管XML提供了很好的数据发布模式，能够生成不一样的表达模式，它仍然不能解决全部的问题。XML值得称道的是让开发人员专一于数据的处理，而让设计人员和艺术家来处理数据的表达形式。应用程序则把生成的XML文件保存在内存或存储在磁盘上，为获得指定的表达类型，例如HTML，能够经过适当的XSLT类型表对内容进行转换，该类型表能够将XML文档转换为HTML文档。类型表与判断文档中的内容应当如何分布在网页上的模板相似。它还能够转换数据，执行传统的命令和循环来处理数据，进行决策，所以它也可能变得很是复杂。


　　类型表的优势之一是，若是要从一部移动电话上访问同一个应用程序，所须要做的所有工做就是再建立一个新的WML类型表。从理论上说，这个应用程序的全部其余部分都无需做任何改变，这使得服务器端的编程工做变得很是高效。采用XML实现一个前端应用程序将使一些任务变得简单，由于显示的数据和处理这些数据的代码都无需改变。开发应用程序各部分的开发小组能够独立工做，从而加快开发进程。


　　然而，我曾经在基于XML的前端应用程序开发中吃过苦头，它的二个最主要的缺点是缺少帮助生成XML以及类型表开发方面的工具和处理速度，第一个因素对那些使用DreamWeaver和FrontPage等可视化HTML开发工具建立HTML网页的开发人员的影响更大。就我本人而言，我仍是喜欢使用DreamWeaver，但我实在不能从在文本编辑器中编写HTML代码中获得什么乐趣。毕竟，如今已是21世纪了，咱们来看一个将XML文档转换为HTML的很是简单的XSLT类型表：


＜?xml version="1.0"?＞
＜xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"＞


＜xsl:template match="page"＞
＜html＞


＜head＞
＜title＞＜xsl:value-of select="title"/＞＜/title＞
＜/head＞


＜body＞
＜xsl:apply-templates/＞
＜/body＞
＜/html＞
＜/xsl:template＞


＜xsl:template match="title"＞
＜h1＞＜xsl:apply-templates/＞＜/h1＞
＜/xsl:template＞


＜/xsl:stylesheet＞


　　若是所选的XSL类型表适当的话，上面的代码会生成以下所示的HTML代码：


＜html＞
＜head＞
＜title＞My first page＜/title＞
＜/head＞


＜body＞
＜h1＞Hello, world＜/h1＞
＜/body＞
＜/html＞
 
　　咱们会发现，上面的代码与咱们用HTML开发工具获得的代码不大相同。不幸地是，咱们必须用手工的方式对它进行编辑，在一个能够生成HTML文档的工具中对它进行处理后，而后在浏览器中打开生成的文档。若是仅仅是为了美观而改变字体的大小，那么就无需这么做了。


　　第二个问题是在运行时完成全部的任务须要许多时间。若是数据格式不是XML，还须要生成XML文档，在类型表对XML进行转换处理后，才能生成HTML代码。与在Servlet或JSP应用程序中向内存缓存中写文件相比，速度和简洁性实在不是基于XML的前端应用程序的优势。


　　总而言之，若是须要动态地生成不一样版面和窗体的表达形式时，就须要使用XML。若是表达形式须要常常变化或须要很是灵活，就应该让设计人员从新设计新的类型表。须要记信的是，设计人员只要掌握XML和XSLT就万事大吉了。


　　另外一个须要使用基于XML的UI的场合是你须要处理的资料是XML文档，而不是Java对象或关系数据库。XML是一种在将来很有前途的新技术，然而，目前使用JSP开发前端应用不是比较方便的，尤为是HTML是惟一一种前端开发工具时更是如此。使用JavaBeans和JSP标识库等一些著名的设计模式则可以使数据的内容和表达形式很好的分离。随着自动对XML/XSLT进行编辑的工具的出现，这些技术在使用方面将更加简单方便。

• 　　结论

　　具体到你本身的Java应用程序，这三种前端技术各有利弊，任何一种技术都不能在全部方面超过其余二种。针对具体的应用程序，咱们必须对需求、用户的指望进行详细分析，对这三种技术进行评估。下面是一些基本的准则： 　　使用HTML/JSP： 　　　━━适合于由大量图形和美术做品组成的静态内容。 　　　━━前端应用程序的界面面向使用全部平台的用户。 　　　━━用户所使用的互联网链接较慢。 　　　━━但愿快速地构建功能比较单一的应用程序。 　　使用Java Swing： 　　　━━适合建立具备内置、与界面相关的逻辑的GUI。 　　　━━能够减轻网络流量，提供尽量的即时响应。 　　　━━若是用户对界面的质量和功能有较高的指望。 　　　━━若是UI的功能比其美感更重要时。  　　使用XML/XSLT 　　　━━须要支持许多不一样的并且常常变化的窗体。 　　　━━数据是XML格式。  　　　━━须要个性化。  　　　━━计划提供无线访问等不一样的访问方式。