Suppose the management of a theatre wish to make program information available on-line using WWW. As well as browsing program information, customers should also be able to make bookings on-line.
Specific requirements might be to allow customers to engage in some kind of conversation with the server in which they select preferences for dates and seats. Furthermore it should be possible to book seats for different events on different dates, making a single payment at the end of the interaction.
This requires the server to store state concerning the customer and to be able to undo any changes should the customer decide to abort the interaction. Furthermore any customer's booking needs to be atomic: either both booking and payment occur or neither do.
Consider how this might be implemented today using WWW technology. The technology to allow customers to browse program information is well understood and works well: it would just be a matter of building an (HTML) document store containing the latest program information.
Allowing customers to make on-line bookings is more difficult: typically it would be done by using CGI programs driving a legacy booking database (we are assuming that most theatres have such a system). These CGI programs would be accessed by using HTML form technology. The architecture of the system is shown in figure 3.
CGI programs would implement operations allowing customers to make interactive seat and performance selections. To make a booking, customers would normally engage in a conversation with the server making multiple method invocations. This means that the CGI programs will have to store temporary state between method invocations; this state must be stored externally because CGI programs are re-forked each time they are invoked.
From an IDL description of the services offered by the CGI programs, the CGI stub compiler described in 1.3 will generate:
The IDL compiler described for the extensible web server proposed in A stub Compiler for HTTP would do a similar job, but lead to a different implementation to the one shown in figure 3. The main difference is that it would generate server stubs for the HTTP server itself. This means that the facilities to make a booking would be provided by extension methods rather than CGI scripts. Any temporary state associated with the customer could be stored inside the HTTP server itself rather than on the local file system.
Client stubs make it easy to write bespoke client applications. So rather than driving the CGI programs or HTTP extension methods using HTML forms, the theatre could provide a client program designed specifically for the purpose. How does the customer obtain this client? It could be done by prior agreement: for example the customer might ftp the viewer (or client program). More attractively, it could be done by making the client an agent which migrates to the customer's machine when it was needed. Thus the only software the customer needs is a browser and a compute engine to support the agent; everything else could be bootstrapped from this. This is already happening in WWW with the Java and Hot Java technology [JAVA 95].
It is probable that any theatre would already have a (legacy) database which stored program information and customer bookings. This database would still be used by booking clerks to record bookings made by other means (e.g. customers calling the box office). Hence the CGI programs or extension HTTP methods need to drive the database: the act of a customer "committing" a booking would involve updating the database.
If the legacy database contained detailed information about programs, it should be possible to apply the techniques of object wrapping described in this paper. Program information could be generated directly from the database itself, rather than storing it as a separate HTML file system.
A facility which may also prove attractive to customers is allowing them to view video clips of the performance, or a preview of the movie, before making a booking. Again this requires customers have the right client to view the video stream. Any agent technology used to solve this problem would need the ability to support (either stored or real time) multimedia streams. Currently it is possible to view video using WWW, but it relies on clients already having the right video viewer (e.g. Quicktime or MPEG players) on their machine.
ANSA home page, Introduction, Comparing CORBA and WWW, Integrating third party information services, A stub Compiler for CGI, A stub Compiler for HTTP, An application scenario, Conclusions, Acknowledgements, References
Nigel Edwards <nje@ansa.co.uk>, Owen Rees <rtor@ansa.co.uk>