VIRTUAL PROGRAMMING LAB FOR ON-LINE DISTANCE LEARNING （下）

The CSA can be designed as a proxy object to a normal Web browser. To configure the Web browser to enable the WebVL, the user simply configures his/her browser to use locally executed CSA daemon by setting the proxy server as 127.0.1 or localhost. The CSA acts as a mediator between the Web browser‘s normal Http request/reply and WebVL services on the network. This approach requires no re-invent of a new Web browser. Various task-scheduling techniques with load sharing can be used by the CSA to dispatch the student‘s request to a suitable site in the WebVL environment for connection. There are several solutions to the problem of providing transparent access to scalable services provided by a group of servers and sharing the load between the different servers. Examples are DNS Aliasing, HTTP redirect, Magic Routers, fail-safe TCP and Active Networks [Ami98, Car99, Yos97].
The interaction between the student and the software is largely supported by Web server and client extensions. Information and feedback can be facilitated by HTML push/pull mechanisms and techniques for local processing of small, embedded applications such as Java Applet. On the other hand, techniques based on the use of forms within HTML documents to let clients initiate and interact with server-side applications enable us to create appropriate tools that can interface Web browsers to software applications. For example, using the forms facility and CGI scripts (Common Gateway Interface), we can build CSA on the Lab servers which provide runtime services to WebVL related requests/replies. The CGI script in Java is called Java servlets, which are Java programs that run in a Java-enabled web server in response to an HTTP request. The web server runs the servlet, and the servlet outputs an HTML page that the server returns to the client [Cam99]. Depending on the lab software to be accessed, the functions of the CGI/Java servlet programs can be as simple as invoking a local command line or shell script program, or as complex as interfacing a sophisticated, interactive software.
A given lab software can be accessed from a command embedded in an HTML document. From the student‘s point of view, he / she simply follows a link that can cause a WWW server to execute a program or a shell script, which, in turn, can spawn a process/thread that will handle the interactions with the distinct student. The server-side agent, implemented as a cgi-bin or Java servlet program, runs during the whole session and is responsible of interfacing the student with the local software program. It obtains the student provided information, such as program commands, code, parameters, etc, from the fill-out forms, processes it if necessary, and then passes it to the software in the required format. For example, the student can submit Java code for execution in a text area within an HTML form; the server side agent would save the code to disk, attempt to compile the code and, if compilation was successful, run the executable file on some test data. When the output is produced by the software, the server-side agent sends the output to the student, most probably as HTML documents that are dynamically generated. These HTML documents may be just simple text files, or contains fields that have to be filled by the student and then transmitted back to the software program, or links to actual sites of the software vendors. It can also contain embedded links that lead to other executable programs. Figure 6 illustrates the above interaction scheme in WebVL. Note that CGI scripts don‘t have to be invoked by forms; they can be invoked directly by a web browser.
By utilizing the information expression that Web browsers and the CSTP support, various forms of multimedia data as output from the software can be saved and communicated about over the Web [Nei96]. For accessing lab help facilities such as programming manuals and help files, due to the ease of interfacing with external viewers in WWW browsers, different types of documents can be viewed by using the viewing programs associated to the various types. This has the advantage of extensibility: new types can be defined with appropriate viewers if necessary. Thus, when the student requests to read help files or programming manuals in the software packages, the WWW browsers will retrieve the documents and launch the corresponding viewer for the display.

Figure 6: Interaction of components in WebVL
For implementing the CSTP, we propose to use HTTP as the baseline protocol by extending relevant HTTP headers and the support for the transfer of WebVL specific headers, control information, and data formats. Potentially we can develop a new specification of XML-based [Kha97, Lau99] CSTP transfer syntax. This approach has the advantage of being conforming to standards and portable to various platforms.
We are also considering the use of mobile agents in the development of WebVL. A mobile agent is a computer program that can autonomously migrate between network sites, i.e., it can execute at a host for a while, halts execution, dispatches itself (together with its data and execution state) to another host, and resumes execution there - all under its own control [Lan99]. It has been found that mobile agent is especially suitable for structuring and coordinating distributed applications running in a wide-area environment like the Internet [Que99]. In our case, for example, mobile agents can be employed to locate the requested software for programming exercises, to collect load information at individual Web servers, and/or to automatically and transparently determine for the client the “best” server to execute a specified task [Cha00]. Mobile agents can also be sent by either the client or the server to perform local interactions or display information at the peer site.