From CORBA to Command and Control Web Services

I was inspired to write a paper on "web services" back in 1999, when people in the banking community had heard of XML but had no idea what they could do with it. My inspiration had been the IATA protocol which I had seen used to automate the aircraft industry and heard rumours that the US Navys' supply line was also managed by these straightforward ascii messages which began with ZCZC and ended with NNNN.

I had just spent a couple of years boning up on CORBA - reading several books, trying to get a copy of Iona's Orbix product so that I could teach myself a new set of skills which would keep me fed for the foreseeable future. I liked the idea of CORBA - in particular the trader service - whereby you could look up a "service" and invoke dynamically. However, when I finally moved to a bank which could afford the technology - it was clear that all was not well. I had expected some form of centrally managed infrastructure and a set of services which I could use/add to. I wholly expected to find analytics (maths libraries) and a range of business "services" - instead I found a ORB on every desk. This meant that any solution developed would, in essence be, be standalone - thereby defeating any advantage of ORB technology. True to form, I discovered that it was indeed the developers who had mandated ORB technology, for the same reasons I had - career sustainment.

But this is not the real reason why ORB technology failed - the principle two were unreliability and complexity. You see the thing most banks don't tell you is that they use an awful lot of perl to "munge" data - perl is fast, quick to develop, easy to understand. ORB's on the other hand were developed by a small (in open source terms) team -who had a limited bandwidth - not quick enough to test the solution or fix the bugs quickly. To use an ORB for a solution costs money in licences, support and requires clever (i.e. expensive) programmers to implement. Once engineered, it was by no means performant - needing big metal to run - but the worst of all was the bugs - it just wasn't reliable enough for serious production use. Combine this with a long fix lifecycle and you'll understand why very few ORB solutions are to be found in any organisation.

So web services to the rescue - well - not quite yet - not that there's anything wrong with the techology - especially the security aspects. It has been possible to tunnel web services over ssh for a long time - combine this with X.509 certs and you have authenticated end points. No, the problem with implementing web services is mindset - people just don't understand the issues. Two of the most common complaints are security (see above) and verbosity (payloads increase by 30% - gasp!) This misses the point. The protagonists seem to want to design a web service that is meant to handle a substantial amount of data and be invoked repetitively. In the real world, web services should be used for command and control. The analogy of the data feed (i.e. comma seperated file sent somewhere for processing) still exists - only this way you have a way of programmatically orchestrating the solution inter enterprise - and that's what web services are all about.

References

[1] The Role of XML in Enabling Business Solutions Built from Collaborative Web-Based Services. Burnett, Papiani, Dec 1999

http://www.enhyper.com/content/iee_16_Dec_99_1.htm