现在让我们想想如何创建一个应用,令其在真实的web环境中运行,它将把java的优势表现得淋漓尽致。这个应用的一部分是在Web服务器上运行的一个Java程序,另一部分则是一个“程序片”或“小应用程序”(applet),从服务器下载至浏览器(即“客户”)。这个程序片从用户那里收集信息,并将其传回Web服务器上运行的应用程序。程序的任务非常简单:程序片会询问用户的E-mail地址,并在验证这个地址合格后(没有包含空格,而且有一个@符号),将该E-mail发送给Web服务器。服务器上运行的程序则会捕获传回的数据,检查一个包含了所有E-mail地址的数据文件。如果那个地址已包含在文件里,则向浏览器反馈一条消息,说明这一情况。该消息由程序片负责显示。若是一个新地址,则将其置入列表,并通知程序片已成功添加了电子函件地址。
若采用传统方式来解决这个问题,我们要创建一个包含了文本字段及一个“提交”(Submit)按钮的html页。用户可在文本字段里键入自己喜欢的任何内容,并毫无阻碍地提交给服务器(在客户端不进行任何检查)。提交数据的同时,Web页也会告诉服务器应对数据采取什么样的操作——知会“通用网关接口”(CGI)程序,收到这些数据后立即运行服务器。这种CGI程序通常是用Perl或C写的(有时也用C++,但要求服务器支持),而且必须能控制一切可能出现的情况。它首先会检查数据,判断是否采用了正确的格式。若答案是否定的,则CGI程序必须创建一个HTML页,对遇到的问题进行描述。这个页会转交给服务器,再由服务器反馈回用户。用户看到出错提示后,必须再试一遍提交,直到通过为止。若数据正确,CGI程序会打开数据文件,要么把电子函件地址加入文件,要么指出该地址已在数据文件里了。无论哪种情况,都必须格式化一个恰当的HTML页,以便服务器返回给用户。
作为Java程序员,上述解决问题的方法显得非常笨拙。而且很自然地,我们希望一切工作都用Java完成。首先,我们会用一个Java程序片负责客户端的数据有效性校验,避免数据在服务器和客户之间传来传去,浪费时间和带宽,同时减轻服务器额外构建HTML页的负担。然后跳过Perl CGI脚本,换成在服务器上运行一个Java应用。事实上,我们在这儿已完全跳过了Web服务器,仅仅需要从程序片到服务器上运行的Java应用之间建立一个连接即可。
正如大家不久就会体验到的那样,尽管看起来非常简单,但实际上有一些意想不到的问题使局面显得稍微有些复杂。用Java 1.1写程序片是最理想的,但实际上却经常行不通。到本书写作的时候,拥有Java 1.1能力的浏览器仍为数不多,而且即使这类浏览器现在非常流行,仍需考虑照顾一下那些升级缓慢的人。所以从安全的角度看,程序片代码最好只用Java 1.0编写。基于这一前提,我们不能用JAR文件来合并(压缩)程序片中的.class文件。所以,我们应尽可能减少.class文件的使用数量,以缩短下载时间。
好了,再来说说我用的Web服务器(写这个示范程序时用的就是它)。它确实支持Java,但仅限于Java 1.0!所以服务器应用也必须用Java 1.0编写。