 |
 |
On Sun, May 25, 2003 at 01:53:17PM +0100, Robert Sanderson wrote: > On Sun, 25 May 2003, Adam Dickmeiss wrote: > > On Sat, May 24, 2003 at 11:02:10PM -0400, LeVan,Ralph wrote: > > > > I am opposed to multi-database stuff. As I understand it, the content > > > These sound like serious folks with specific requirements and a commitment > > > to serious code. Make them do real z39.50. > > With SRW and HTTP keepalive the mechanics becomes equivalent. > > Could you write up a quick summary of how this works and any > advantages/disadvantages? I think it'd be really useful for the rest of > us, and for any new implementers. I'll try. The Z39.50 model where one session is tied to one user has the drawback that it is difficult to integrate with a Web Server (which has a Z39.50 origin in it). It also represents a problem for the server, since one socket will be open for every user out there. To overcome the problem in building a Web-to-Z gateway it was much easier to assign N sockets for each server where N was a semi-fixed number and all users would share those sockets. A typical number of users would be much higher than N. In this mode all Z39.50 sessions are anonymous but the Z39.50 init user authentication model breaks down. The socket may be shut down at any time by the server - due to timeout/load, etc.. So the Z client has to be prepared to reestablich it again. IIRC Ian Ibbotson used the term "Z39.50 persistent connections". In this mode Z39.50 is used in pretty much the same way as a MySQL connection to a MySQL db (or like most RDB*s I'd reckon). The number of sockets N would typically be equivalent to the number of threads/processes at the DB server. When SRW is based on a HTTP/1.1 implementation, the HTTP operation defaults to keep-alive (even though the client did not specify Keep-Alive). The server will keep the socket alive for some time. Just like Z39.50. The HTTP/1.1 client may stil specify how long it would like to the socket to stay alive. So to summarize the socket is typically tied to a database session rather than a user session. The advantages are: better scalability (number of database sessions can be controlled) better Z39.50/SRW integration better Web server integration The disadvanges are: authentication ala Z39.50 breaks down HTTP/1.1 is more difficult to implement than HTTP/1.0. > > For SRW, we already have the notation of a database and is using > > the HTTP path. That has two drawbacks: > > 1) can only specify one resource. > > 2) is bound to HTTP (SOAP can operate on a varity of protocols) > > The W in SRW is Web (or Web Service), after all, but it is true that SOAP > isn't dependant on HTTP as the protocol. On the other hand, the database > is specified as a URI rather than an HTTP path, I thought ... if I had an > FTP protocol SOAP server, I could have a database at > ftp://srw.o-r-g.org/pub/moo/ > in much the same way as I could have it at > http://srw.o-r-g.org:8080/l5r/ > > (Though that does bring up a question of modeling in Zeerex, I admit) > (SRF: Search/Retrieve over FTP? :)) > > I can see that Matthew's music searching database, which IIRC can't match > quickly enough to be able to respond before an http timeout, would benefit > from SOAP over email. But are there any SOAP libs for protocols other than > HTTP or possibly FTP? Would it actually be useful to to decouple SRW from > http? I don't see the other protocols being used, either with SRW or > really much else. As long as the model is one DB, using the path is OK. A "hot" transport for SOAP is Jabber . Even Jabber has a notion of a resource. See http://www.jabber.org/about/techover.html where I spot the following [node@]domain[/resource] And that looks familiar. -- Adam > Rob > > -- > ,'/:. Rob Sanderson ([log in to unmask]) > ,'-/::::. http://www.o-r-g.org/~azaroth/ > ,'--/::(@)::. Special Collections and Archives, extension 3142 > ,'---/::::::::::. Twin Cathedrals: telnet: liverpool.o-r-g.org 7777 > ____/:::::::::::::. WWW: http://liverpool.o-r-g.org:8000/ > I L L U M I N A T I -- Adam Dickmeiss mailto:[log in to unmask] http://www.indexdata.dk Index Data T: +45 33410100 Mob.: 212 212 66