7th December 2000
``Your scientists were so preoccupied with what they could do, that they didn't stop to think about whether they should do it.''
-- Ian Malcolm (played by Jeff Goldblum) in Jurassic Park
Moves are afoot in the ZIG to re-implement Z39.50 using SOAP as the transport layer instead of BER-encoded ASN.1. This is a stupid idea. George Bernard Shaw once said of SOAP, It's reminiscent of a dog walking on its hind legs. The amazing thing is not that it's done well, but that it's possible at all. (Actually, he said it about women preaching, but that's beside the point.)
SOAP is profoundly unsuitable as a substrate for Z39.50 for any number of reasons:
The whole edifice of SOAP resembles one of those Turing-Machine-Implemented-In-vi-macros exercises which impresses everyone who sees it, but makes no sense technically. It's like building an armchair out of meringue. You can do it, but why would you want to? It's hard not to suspect that SOAP was thought up late one Friday night after a few too many beers.
Even if Z39.50 were a brand new standard, and we were choosing the appropriate substrate, ASN.1/BER would be preferable to SOAP, for all these reasons and more. Given that we live in a world where we all maintain existing, stable BER-based Z39.50 applications, the very idea of ripping out that substrate and retro-fitting a new, inferior one is ludicrous. In return for our work, we would be left with a significantly less capable system.
BER is routinely castigated as an ``old'' standard. It is described as follows (in the introduction to the Z39.50 as an XML Protocol session at the December 2000 ZIG):
[ASN.1] is growing old, becoming outdated, and may soon no longer be supported.
These are not sensible criticisms. For ``old'', we may as well read ``mature''. Certainly the ASN.1/BER combination has attained a level of completeness, combat-tested in real applications, which SOAP and other such vaprous concoctions don't come close to.
Criticising ASN.1 for being ``old'' is like criticising the use of wood in building furniture. Wood has been used for hundreds of years, ergo it is old and ``outdated''. Wooden chairs and tables must be thrown out and replaced with modern, plastic ones. No matter if the plastic is untested, fragile and ugly: it's modern. What else is there to want?
Even if the ZIG were to decide that SOAP was a good way to go, what would be the result? No-one is going to rush to be the first to implement a client that can't talk to any existing servers; no-one is going to rush to be the first to implement a server that no existing clients can talk to. In practice, the existing ASN.1/BER servers and clients will live on. So the best case outcome for the current discussions is that nothing happens. Why are we even wasting our time talking about this?
We need to step back and look at what problem we're actually trying to solve. So far as I can understand it, the issue that's motivating the current Z39.50-over-SOAP initiative is the lack of new programmer take-up of Z39.50. The change of substrate is proposed as a means of lowering the barrier to entry to Z39.50 development.
Are there any other ways to lower that barrier without doing violence to the capabilities of the standard? (Of course I'm going to say yes, otherwise this would be a very short section!)
Today's application programmers just don't care about network substrate. When Java programmers send information across HTTP connections, they do it by constructing a new HTTPconnection object and invoking the sendData method on it. The details of the bytes that are sent over the connection are the business of nobody but the provider of the library that contains the HTTPconnection class.
Analogously, they will not care whether their Z39.50 connections are implemented using ASN.1/BER, SOAP, or carrier-pigeons with differently coloured leg-rings. All they care about is forging connections and invoking methods on them. Changing the underlying transport in an attempt to make Z39.50 appeal to these people is simply addressing the wrong problem.
What programmers need is a stable API to Z39.50. In order to lower the barrier to entry, we need to meet that need in three ways.
Because of current industry buzz, and also to avoid falling into the trap of merely duplicating the service definition from the standard, the abstract API should be couched in terms of objects representing connections, search results, records, etc. It is important that this API be ratified by the ZIG and therefore given some sort of official status.
Bindings to the various languages should be ``obvious'': in the case of non-object languages such as C, the object orientation needs to be ``faked'' but this isn't difficult. Again, individual bindings should be ratified by the ZIG.
Once again, the ZIG should nominate and ratify one reference implementation for each language binding. Reference implementations should be made freely available; it would help if the Z39.50 Maintenance Agency or some other body were able to provide some funding to assist development of these implementations
In a world where Z39.50 applications can be easily built using well-defined APIs, what role remains to be played by the project to replace the current Z39.50 networking substrate?
One possible answer would be for implementors who want to make Z39.50-over-SOAP client possible to provide gateways which bridge between the postulated SOAP-based version of the protocol and the existing SOAP-based version.
But that is for researchers to do; for people who have to build real applications to get real work done, Z39.50 over ASN.1/BER is still the way to go.