HTML、Swing还是XML，Java客户端工具选择？

2019-11-18 13:56:52

字体：大中小

来源：转载

供稿：网友

　　作者：jeru
email: jeru@163.net

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

　　与现有的技术相比，Java有明显的优点，因此它已经在服务器端应用软件的开发中确立了主导地位。然而，由于每一个应用程序都有几种形式的用户界面和前端的表达形式，我们中的许多人都对在客户端采用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。我们可以通过http://192.9.48.9/PRodUCts/plugin/1.3/demos/applets/GraphLayout/example1.html中的例子来学习其工作原理。关于Java插件更具体的资料请参阅Sun公司的网站。

　　插件带来的好处是它可以支持各种操作平台上的所有浏览器，此外，它还提供了一个有保障的执行环境，插件只需要安装一次，就可以对所有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可以提供快速的双向网络调用，它可以回叫客户端应用程序，提醒用户根据服务器的要求更新显示内容。

　　方案三、以纯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，因此也可以大大降低资源的消耗。

　　为了演示WebCream的工作原理，下面的2个图显示了使用WebCream时，一个样例GUI应用程序在HTML前端应用程序中是如何运行的。图1是一个正在运行的GUI应用程序（源代码），图2是WebCream治理着同一个应用程序，窗口表示浏览器中的网页。

　　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格式。

　　　━━需要个性化。

　　　━━计划提供无线访问等不同的访问方式。

上一篇：J／Direct引出纯Java问题

下一篇：DOM文档操作和XML文件互相转换的java实现