Introducing z2uddi, the Z39.50-to-UDDI gateway

When I was putting together my free software page a few weeks ago, I realised that one of the free packages I’d built for a customer (the U.S. Geological Survey) had never actually been released to the world, despite its GPL licence terms.  That was a silly oversight.  I’ve now been able to confirm with my immediate customer that there is no reason not to proceed, so I have released z2uddi to the world, as the Perl module Net::Z3950::UDDI.

UDDI is a fearsomely complex SOAP-based web service for resource discovery.  If you’ve ever needed to use it, you may have found it … awkward.  z2uddi makes it possible to access UDDI services via the ANSI/NISO Z93.50 protocol (widely used in libraries), and also by the much simpler HTTP GET-based web-service SRU.  The latter is so simple that you can easily make a simple SRU client using only an HTML form, so in many cases it will provide a much more accessible way of getting information out of UDDI.

More pointless whining, such as you have come to expect from this blog

I was originally going to just quote a sentence or two from the documentation of the newly released module as a taster.  But having re-read those sentences, from the page on the UDDI::HalfDecent module that comes as part of the package, I now realise that I like the whole section enough to reproduce it here.  So here it is — enjoy!

I have tried to use and love UDDI::Lite, honestly I have. I have tried to use the underlying SOAP::Lite, which package UDDI::Lite is part of, and ploughed countless futile man-hours into the effort. There is no doubt that that suite of modules is a tour de force of intellectual effort, startling in its strange, crystalline beauty and innovative to a degree one hardly thought possible. All of this is, however, marred by the one tiny flaw that it doesn’t work. And worse, it doesn’t diagnose its failures: error-handling callbacks don’t get invoked, global error-indication objects don’t get set, and SOAP faults perfectly visible in the protocol XML go unreported.

So the obvious thing to do is go into that code and fix it, right? Except you can’t because the code is so obviously a work of genius that no mortal being can understand it. (I am not just being feeble here: this is the overwhelming feeling of the broader community). The SOAP::Lite code, including UDDI::Lite, is a fantastic illustration of Kernighan and Pike’s observation: “Everyone knows that debugging is twice as hard at writing a program in the first place. So if you’re as clever as you can be be when you write it, how will you ever debug it?” (from The Elements of Programming Style, 1978 – very nearly thirty years old as I write this, but as fresh and relevant as ever. And very funny, which is not something you can say about most programming books.)

So the SOAP::Lite package is a write-off, and my attempts to interact with its community underline that: the email address of the package maintainer no longer works, and the mailing list consists entirely of forlorn souls such as myself asking “has anyone got x to work?” and never receiving replies.

And the only other UDDI package on CPAN is one just called UDDI, the most recent release of which is 0.03 from the year 2000, and which fails its test-suite.

So that leaves only one option, which is to start from the ground up and roll my own. At least that way I’ll be able to debug it.

The number one design principle with this module (and anyone who’s used SOAP::Lite will understand why I make a big deal of this) is that all errors are reported immediately, through the throwing of a Exception::Class::UDDI object. If something goes wrong, you will know it; and you will know it immediately; and you will know what went wrong. Just imagine!

On the downside, this module has no pretention to the flexibility and generality that SOAP::Lite and UDDI::Lite would offer, if only they worked. Those modules set out to encompass RPC-style and document-style SOAP, XML-RPC, UDDI versions 1, 2 and 3 (although not really 3) and of course a hundred different ways of expressing everything. This module will offer only those facilities required to access actual UDDI servers – and, more precisely, those facilities needed by z2uddi.

I wrote that in 2007.  The UDDI module has not moved since then; there have been releases of SOAP::Lite since, which may or may not have improved matters, but since there have only been two articles posted on the SOAP::Lite website in that time, neither of them in the last two years, my guess is that the project remains moribund.

How did this happen?

I don’t really understand how UDDI vanished from the map so completely and so quickly when it had the backing of all the industry giants — IBM, Microsoft, SAP and so on.  After being hyped up by all these big hitters, it just just fell off the radar (and indeed IBM, Microsoft, and SAP all announced they were closing their public UDDI nodes in January 2006).

But more  broadly, whatever happened to SOAP?  Wasn’t it going to save the world or something?  I don’t know if it’s still a big deal in the Enterprise world, but in libraries, which is where I mostly work, no-one talks about it any more.  When it does get mentioned, people tend to cough and look embarrassed and change the subject, as though an elderly and much loved but slightly confused relative has just made an amazingly crass statement about immigration.

But a few years ago, everyone loved SOAP.  (Er, except me.  I always said it was dumb.)  The fall from grace has been … not sudden, exactly, or people would have noticed.  But inexorable.  Yes — it just slowly but surely became a non-person.  As shown by the complete lack of interest in the Perl world in building a usable module to implement it (and I remind you that CPAN has, at the time of writing, over 20,000 distributions available for download).

Oh, well.  Suits me.  I hate it anyway.  Maybe REST has killed it.  SOAP may have stood for Simple Object Access Protocol, but I think there is something pleasantly symbolic of its vague there-are-lots-of-ways-to-do-it-ness that no-one ever really knew whether that was meant to mean a simple protocol for object access, a protocol for simple access to objects, or protocol for access to simple objects.  Everything about it was/is confused and confusing, and I won’t be mourning it.

Well, I’m not entirely sure how this happened, but it seems that a perfectly harmless software release announcement has mutated into a vicious attack on a pair of specifications that were already quietly getting on with dying and didn’t need any help from me.  Oh well — so it goes.

Tune in text time for: whatever happens to occur to me at the time.  Maybe something about Buffy, maybe something about how stupid library standards also are.  Who can tell?

4 responses to “Introducing z2uddi, the Z39.50-to-UDDI gateway

  1. Dennis Schafroth

    but prob. just a type ;-)

  2. I remember attending a seminar at University about UDDI when I was still an undergraduate. Nobody understood what they wanted with all the T-models and stuff, and I had the feeling the lecturer either didn’t understand it as well, or at least completely failed to explain it.

    At the time, being an undergrad, I didn’t have the courage to denounce the whole thing as the over engineered bizarre non-solution to a trivial problem it is.

    This is a recurring pattern I guess. If you just overcomplicate a thing enough, it makes you look smart and intimidates people from criticising it, because they don’t understand it. Which of course is a bad thing in the grand scheme of things, but might be a successful individual strategy.

    When reading scientific papers or similar, I often find myself having a hard time cutting through all the formalizations, just to find out the thing is trivial in the end…

  3. Martin,

    I like your phrase “over-engineered bizarre non-solution to a trivial problem” so much that I am elevating it to an official Reinvigorated Programmer acronym, OEBNSTOTP. It may not roll off the tongue, but it certainly rolls off the mind.

  4. Having just had to re-create an existing soap service in a different language, I totally agree that it’s too difficult and too confusing to work with. The less SOAP I have to work with, the better.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s