Question

前面采取的似乎是一种完美的方法。没有 CGI 编程，所以在服务器启动一个 CGI 程序时不会出现延迟。数据报方式似乎能产生非常快的响应。此外，一旦 Java 1.1 得到绝大多数人的采纳，服务器端的那一部分就可完全用 Java 编写（尽管利用标准输入和输出同一个非 Java 程序连接也非常容易）。

但必须注意到一些问题。其中一个特别容易忽略：由于 Java 应用在服务器上是连续运行的，而且会把大多数时间花在 Datagram.receive() 方法的等候上面，这样便为 CPU 带来了额外的开销。至少，我在自己的服务器上便发现了这个问题。另一方面，那个服务器上不会发生其他更多的事情。而且假如我们使用一个任务更为繁重的服务器，启动程序用“nice”（一个 Unix 程序，用于防止进程贪吃 CPU 资源）或其他等价程序即可解决问题。在许多情况下，都有必要留意象这样的一些应用——一个堵塞的 receive() 完全可能造成 CPU 的瘫痪。

第二个问题涉及防火墙。可将防火墙理解成自己的本地网与因特网之间的一道墙（实际是一个专用机器或防火墙软件）。它监视进出因特网的所有通信，确保这些通信不违背预设的规则。

防火墙显得多少有些保守，要求严格遵守所有规则。假如没有遵守，它们会无情地把它们拒之门外。例如，假设我们位于防火墙后面的一个网络中，开始用 Web 浏览器同因特网连接，防火墙要求所有传输都用可以接受的 http 端口同服务器连接，这个端口是 80。现在来了这个 Java 程序片 NameSender，它试图将一个数据报传到端口 8080，这是为了越过“受保护”的端口范围 0-1024 而设置的。防火墙很自然地把它想象成最坏的情况——有人使用病毒或者非法扫描端口——根本不允许传输的继续进行。

只要我们的客户建立的是与因特网的原始连接（比如通过典型的 ISP 接驳 Internet），就不会出现此类防火墙问题。但也可能有一些重要的客户隐藏在防火墙后，他们便不能使用我们设计的程序。

在学过有关 Java 的这么多东西以后，这是一件使人相当沮丧的事情，因为看来必须放弃在服务器上使用 Java，改为学习如何编写 C 或 Perl 脚本程序。但请大家不要绝望。

一个出色方案是由 Sun 公司提出的。如一切按计划进行，Web 服务器最终都装备“小服务程序”或者“服务程序片”（Servlet）。它们负责接收来自客户的请求（经过防火墙允许的 80 端口）。而且不再是启动一个 CGI 程序，它们会启动小服务程序。根据 Sun 的设想，这些小服务程序都是用 Java 编写的，而且只能在服务器上运行。运行这种小程序的服务器会自动启动它们，令其对客户的请求进行处理。这意味着我们的所有程序都可以用 Java 写成（100%纯咖啡）。这显然是一种非常吸引人的想法：一旦习惯了 Java，就不必换用其他语言在服务器上处理客户请求。

由于只能在服务器上控制请求，所以小服务程序 API 没有提供 GUI 功能。这对 NameCollector.java 来说非常适合，它本来就不需要任何图形界面。

在本书写作时，java.sun.com 已提供了一个非常廉价的小服务程序专用服务器。Sun 鼓励其他 Web 服务器开发者为他们的服务器软件产品加入对小服务程序的支持。