> Good article from Wilbert, I'm glad someone has asked Erik
> these questions!
>
> Adopting ZOOM where SRW can't be implemented should have been
> fine instead of developing "SQI". If all they wanted was an
> abstract API, then even the OKI DR might have worked OK. Oh
> well, it keeps folk busy, I suppose.
Or they could have adopted CQL from SRW, even if they had decided on
using different wrappers for the communications.
That said, SRW could fairly easily be bound to SOAP over SMTP which
would allow asynchronous communications. We haven't included such a
binding in the spec.s because no-one has been asking for one - whilst
supported, asynchronous operations are not that common in Z39.50
implementations.
A more appropriate mechanism might be to make use of standards such as
WS-Notification, WS-Events, etc. This is part of the reason we haven't
considered asynchronous communication (apart from lack of people
shouting for each) - the WebService standards in this space haven't
really solidified.
To be honest, I'm not convinced that a client using multiple threads but
a synchronous communications model wouldn't fit the requirements (and
handling asynchronous communications properly requires multiple threads
anyway).
> As for service discovery, isn't that what UDDI is for? :-)
We already have two competing standards for this already - UDDI and
ebXML Registries. We certainly do not need a third!
Matthew Dovey
Oxford University
|