Message-Id: <199602141131.FAA11881@library.wustl.edu> Date: Wed, 14 Feb 1996 11:14:19 +0100 From: Alan Jackson <mailto:alan_j@SUPVAX.SLS.CO.UK> Subject: Re: Z39.50 and the World Wide Web (fwd) To: Multiple recipients of list WEBCAT-L <mailto:WEBCAT-L@WUVMD.WUSTL.EDU>
Eliot Christian outlined his vision:>I don't have complete answer, but I have been asking around in the Z39.50
>community to get a sense of the visions people have for using Java in
>connection with Z39.50 protocol support at the client end. (My apologies
>that this is redundant for some of you who have been contributing your
>thoughts already.) The attached paper is my sense of what's ripe for
>implementation right now.
There appears to be one important feature of Z39.50 that isn't addressed by your model. It's a feature that many on this list are having difficulty with, judging by recent postings. I refer to the 'statefulness' of a Z39.50 session used in conjunction with the 'stateless' HTTP protocol.
If you remember, the main Z39.50 services are INIT, SEARCH, PRESENT, DISPLAY and TERMINATE. Once an INIT has been sent to the target a session is opened until a TERMINATE is sent to close it down. A Z39.50 session 'remembers' the context of searches executed with SEARCH allowing selected records from sets to be recovered with PRESENT (result sets are stored in memory).
It might seem that the only way to use Z39.50 with HTTP, in which all session context is lost when data has been sent back to the client, is always to execute the sequence INIT-SEARCH-PRESENT-DISPLAY-TERMINATE. Going back for 'the next n records of the last set' is then hopelessly inefficient. The best compromise is to ask the target to deliver all the records (or all up to a maximum number), store the records on the Web server and browse them with a client-driven, result set display viewer. Ok for small records perhaps, not so good for large ones. There are other drawbacks to the scheme, not least being the repeated overhead of initialising a large search engine. The drawbacks are, of course, the reason for Z39.50 in the first place!
So using Z39.50 statelessly is akin to walking in front of a horse-less carriage with a red flag! How can we get round the problem? I can't quite see how the Java scheme described can handle stateful Z39.50 sessions. described. There is a way using good ol' CGI's. Maybe it can be adapted for Java?
When a user requests connection to a Z39.50 target a sub-process is started and INIT sent. The CGI carries back to the client a unique id (including d'base id, user id and IP address). The process remains open, waiting for a TERMINATE. Subsequent CGI scripts executing for the user all carry the information required to connect to the user's own session (via hidden form variables).
Now there's a mechanism for calling Z39.50 services 'properly' (eg using only PRESENT to recover the next n records of the last search). This scheme works fine, providing you remember that a session time out is required to cope with the (common) situation where a user moves on without explicitly ending the search session.
Alan Jackson, Tailored Information, http://www.datatext.co.uk/ti/