CSDN博客

img taocsdn

再谈客户端的 Java 技术

发表于2004/7/11 14:45:00  752人阅读

基于服务器的资源
那些必须存放在服务器上的资源会怎样呢?这类基于服务器的资源包括地址验证,运输费用计算,以及信用卡验证等。支持数据以及要求高安全度的处理必须放在服务端,但大部分的验证处理,数据转换以及费用计算过程可以迁移到客户端系统上。支持这一想法的几个 Java 语言特点包括:

  • Java 语言通过 HttpURLConnection 对象来为 HTTP 连接提供内在支持。同时利用 java.net 包的其他部分,为服务端代码与客户端代码之间的通讯提供一种方法,简单有效地生成数据或打包数据。

  • 许多客户端的 Java Applet 代码实际上与那些在服务器上运行的代码是一样的。

现在我们可以将多种任务分配给服务器和客户机,从而减少服务器负载,甚至可能减少网络连接。具体如何分配这些任务将取决于系统的类型以及用户团体,但几乎所有的系统都会因为增加一些客户端处理而受益,例如:

  • Applet 类能够将数据从一系列格式转化到单一的 XML 字符串格式,这使得服务器更容易处理数据。

  • Applet 类可以进行数据压缩,即把那些将要上载到服务器的数据压缩,同时将这些数据分割成较小的数据包,从而进一步提高了可靠性。

  • 当用户填写结帐表单时,Applet 类能够进行地址和运输费用的计算(在更大的基于服务器数据库中这类计算常常需要进行交互)。此方法能够减少最后结算所需要的时间,同时令用户在提交定单之前就能够看到正确的运输费用以及相应税金等信息。

为了发挥这个技术的最大优势,需要一些方法向那些返回指定数据的服务器发送请求。 Java servlet 恰好具有这种能力。许多开发者并未完全意识到 servlet 能够将任何一种数据作为响应并返回,而不仅仅限于 HTML 或是 XML。通过返回一系列连续的对象或一个压缩的数据包,servlet 能够执行例如地址确认或运输费用和税金计算等任务。同时,进行这些计算的客户端代码可以通过后台线程的运行来掩盖用户等待时间。清单 2 中显示了一个servlet,该 servlet 接收 HTTP 的带有 Zip 代码的 GET 请求,并返回运输费用的计算结果。同样出于令清单清晰明了的目的,在这里省略了若干非常重要的实际代码。

注意到我使用 ObjectOutputStream 对象来将整个目标图表写入待返回的响应中。content 类型需要设置成某些合适的值,同时将 content 处理句柄分配到客户端。这种方法能够返回一个 Java 对象,里面包含顾客运输、处理费用以及应缴税金的计算结果。如果这个对象只是与客户端后台线程进行通讯,用户就根本不会意识到他已经和服务器进行了一轮通讯。

节约时间的新技术
上述技术都已实现若干时间了,且大多数正在全世界各种不同的系统上应用着。前面我曾经许诺过要介绍一些新技术,现在是具体阐述它们的时候了。客户端上最有趣的 Java 新技术当属 weblet。IBM alphaWorks 的 DirectDOM 就是该技术的一个具体实现(参看
资料部分)。DirectDOM 允许从 Java 代码中访问整个浏览器 DOM tree (2000年11月13日 W3C 建议为 DOM Level 2)。weblet 没有用户界面,必须通过操纵浏览器中的活动 DOM 文档来完成它的工作。许多原先需要复杂 JavaScript 代码才能实现的技术,通过这种方法都能够实现。必须注意到尽管 DirectDOM 是一项很有吸引力的技术,它仍处在 alpha 阶段,是不完善的,并且需要 Internet Explorer 或 Mozilla (M18) 的最新版本才能够运行。然而,此技术足以使你预测到不远的将来将会如何令人激动。一些可能实现的例子如下:

  • 在充满了大量图形和视觉刺激的结算网页上,加入 weblet。那么在用户处理结算表格的多个步骤时,不需要每步都在表单与网页间切换,也能够与服务器通讯交换数据并完成结算。当结算完毕需要确认时,weblet 会将整个包提交到服务器,服务器就可以按照通常的结算处理步骤进行处理。

  • 一个显示属性消息的网页。weblet 通过令页面空白来标记对应于打印或保存请求的响应,从而防止数据被不加区别地共享。

  • 用户可以向互联网上的应用程序请求获得某些报告。报告的摘要信息会马上传送到,而 weblet 则使用后台线程下载该报告的详细信息。当用户对摘要中某行条目感兴趣时,只要用鼠标点击该条目,weblet 就能够立即响应鼠标动作,在这个条目的下方显示详细信息。这些具体信息是在摘要页面下载后,才被后台线程下载的。但是用户并不会注意到这一点。

另一个长些的例子,更清楚地展示了 weblet 如何工作。在 清单 3,发送给客户端的 HTML 页面清单 4,weblet 类的 Java 代码中,可以看到这个例子。尽管它不适合于生产环境也未完善,但依然很有用。这个例子下载一个很长的示范网页,其中含有两个表单和一个 weblet 标记。weblet 用一些介绍性的文本来替代这些表单,或在演示过程中切换这两个表单。

为什么要做这些?
为什么我们会关注客户端的 Java 技术发展呢?为什么不建立那些只为网络上计算机工作的系统,或是瘦客户系统,而在服务器上执行绝大部分的复杂计算工作?简单的说,是因为我们无法提供这样的服务器服务。倘若要在单独一个服务器空间中安装足够的处理程序,来支持大量客户端所请求的巨大处理负载,开销将是极其昂贵的,因此才开发了分布式系统模型 (n-tier 结构)。客户端的 Java 技术允许我们减少大型系统中的操作开销的同时,大幅度提高客户端的参与——减少用户与服务器之间通讯的回合数,提高交互层次,改善数据的确认速度。客户端的 Java 技术还可以帮助我们实现一些服务器难以单独完成的任务,比如基于标记 (token-based) 的数字签名等。即便是单一的开发平台,企业版的 Java 2 也提供了强大的体系结构。可以将客户端 Java 技术与支持 Java 2 平台的服务器相结合,不能充分利用这个优势将非常遗憾。

那些必须存放在服务器上的资源会怎样呢?这类基于服务器的资源包括地址验证,运输费用计算,以及信用卡验证等。支持数据以及要求高安全度的处理必须放在服务端,但大部分的验证处理,数据转换以及费用计算过程可以迁移到客户端系统上。支持这一想法的几个 Java 语言特点包括:

  • Java 语言通过 HttpURLConnection 对象来为 HTTP 连接提供内在支持。同时利用 java.net 包的其他部分,为服务端代码与客户端代码之间的通讯提供一种方法,简单有效地生成数据或打包数据。

  • 许多客户端的 Java Applet 代码实际上与那些在服务器上运行的代码是一样的。

现在我们可以将多种任务分配给服务器和客户机,从而减少服务器负载,甚至可能减少网络连接。具体如何分配这些任务将取决于系统的类型以及用户团体,但几乎所有的系统都会因为增加一些客户端处理而受益,例如:

  • Applet 类能够将数据从一系列格式转化到单一的 XML 字符串格式,这使得服务器更容易处理数据。

  • Applet 类可以进行数据压缩,即把那些将要上载到服务器的数据压缩,同时将这些数据分割成较小的数据包,从而进一步提高了可靠性。

  • 当用户填写结帐表单时,Applet 类能够进行地址和运输费用的计算(在更大的基于服务器数据库中这类计算常常需要进行交互)。此方法能够减少最后结算所需要的时间,同时令用户在提交定单之前就能够看到正确的运输费用以及相应税金等信息。

为了发挥这个技术的最大优势,需要一些方法向那些返回指定数据的服务器发送请求。 Java servlet 恰好具有这种能力。许多开发者并未完全意识到 servlet 能够将任何一种数据作为响应并返回,而不仅仅限于 HTML 或是 XML。通过返回一系列连续的对象或一个压缩的数据包,servlet 能够执行例如地址确认或运输费用和税金计算等任务。同时,进行这些计算的客户端代码可以通过后台线程的运行来掩盖用户等待时间。清单 2 中显示了一个servlet,该 servlet 接收 HTTP 的带有 Zip 代码的 GET 请求,并返回运输费用的计算结果。同样出于令清单清晰明了的目的,在这里省略了若干非常重要的实际代码。

注意到我使用 ObjectOutputStream 对象来将整个目标图表写入待返回的响应中。content 类型需要设置成某些合适的值,同时将 content 处理句柄分配到客户端。这种方法能够返回一个 Java 对象,里面包含顾客运输、处理费用以及应缴税金的计算结果。如果这个对象只是与客户端后台线程进行通讯,用户就根本不会意识到他已经和服务器进行了一轮通讯。

节约时间的新技术
上述技术都已实现若干时间了,且大多数正在全世界各种不同的系统上应用着。前面我曾经许诺过要介绍一些新技术,现在是具体阐述它们的时候了。客户端上最有趣的 Java 新技术当属 weblet。IBM alphaWorks 的 DirectDOM 就是该技术的一个具体实现(参看
资料部分)。DirectDOM 允许从 Java 代码中访问整个浏览器 DOM tree (2000年11月13日 W3C 建议为 DOM Level 2)。weblet 没有用户界面,必须通过操纵浏览器中的活动 DOM 文档来完成它的工作。许多原先需要复杂 JavaScript 代码才能实现的技术,通过这种方法都能够实现。必须注意到尽管 DirectDOM 是一项很有吸引力的技术,它仍处在 alpha 阶段,是不完善的,并且需要 Internet Explorer 或 Mozilla (M18) 的最新版本才能够运行。然而,此技术足以使你预测到不远的将来将会如何令人激动。一些可能实现的例子如下:

  • 在充满了大量图形和视觉刺激的结算网页上,加入 weblet。那么在用户处理结算表格的多个步骤时,不需要每步都在表单与网页间切换,也能够与服务器通讯交换数据并完成结算。当结算完毕需要确认时,weblet 会将整个包提交到服务器,服务器就可以按照通常的结算处理步骤进行处理。

  • 一个显示属性消息的网页。weblet 通过令页面空白来标记对应于打印或保存请求的响应,从而防止数据被不加区别地共享。

  • 用户可以向互联网上的应用程序请求获得某些报告。报告的摘要信息会马上传送到,而 weblet 则使用后台线程下载该报告的详细信息。当用户对摘要中某行条目感兴趣时,只要用鼠标点击该条目,weblet 就能够立即响应鼠标动作,在这个条目的下方显示详细信息。这些具体信息是在摘要页面下载后,才被后台线程下载的。但是用户并不会注意到这一点。

另一个长些的例子,更清楚地展示了 weblet 如何工作。在 清单 3,发送给客户端的 HTML 页面清单 4,weblet 类的 Java 代码中,可以看到这个例子。尽管它不适合于生产环境也未完善,但依然很有用。这个例子下载一个很长的示范网页,其中含有两个表单和一个 weblet 标记。weblet 用一些介绍性的文本来替代这些表单,或在演示过程中切换这两个表单。

为什么要做这些?
为什么我们会关注客户端的 Java 技术发展呢?为什么不建立那些只为网络上计算机工作的系统,或是瘦客户系统,而在服务器上执行绝大部分的复杂计算工作?简单的说,是因为我们无法提供这样的服务器服务。倘若要在单独一个服务器空间中安装足够的处理程序,来支持大量客户端所请求的巨大处理负载,开销将是极其昂贵的,因此才开发了分布式系统模型 (n-tier 结构)。客户端的 Java 技术允许我们减少大型系统中的操作开销的同时,大幅度提高客户端的参与——减少用户与服务器之间通讯的回合数,提高交互层次,改善数据的确认速度。客户端的 Java 技术还可以帮助我们实现一些服务器难以单独完成的任务,比如基于标记 (token-based) 的数字签名等。即便是单一的开发平台,企业版的 Java 2 也提供了强大的体系结构。可以将客户端 Java 技术与支持 Java 2 平台的服务器相结合,不能充分利用这个优势将非常遗憾。

0 0

相关博文

我的热门文章

img
取 消
img