Merchant Bankers finally get the Internet and FIX?

From second Tanenbaum elephant hump comes the story about how emerging markets are booming because of gasp! - the application of internet technology to investment banking. It's rather ironic that the technology was there in 1970 - trouble was - the business just wasn't listening - messaging is as old as the hills - FIX is messaging in verbose clothing (XML) - suitable for the trading of web "services" by the externalisation of business processes as I observed in my 1999 paper on "The Role of XML in Enabling Business Solutions Built from Collaborative Web-Based Services". This was further extended in the blog article here.

XML versus ASN.1

I don't know how widely the ASN.1 Packed Encoding Rules (PER) are used but here's an example of how much more verbose XML can be than PER.

Here's a simple ASN.1 definition:

FooBaz {1 2 0 0 6 3} DEFINITIONS ::=
 BEGIN
    T1 ::= INTEGER (25..30)

    Test1 ::=
       SEQUENCE {
          first  T1,
          second T1
       }
  
    Test2 ::=
       SEQUENCE {
          first2  [0] T1 OPTIONAL,
          second2 [1] T1 OPTIONAL
       }
  
    Integer11 ::= INTEGER (0..32000)    
  
    Test3 ::=
       SEQUENCE {
          first  T1,
          second T1,
          third Integer11,
          fourth Integer11
       }
 END

Here's an encoding using XML:

<Test3>
   <first>29</first>
   <second>30</second>
   <third>63</third>
   <fourth>31000</fourth>
</Test3>

Here's the PER. Note that it fits into 36 bits so the last 12 are irrelevant.

9401 ff91 8000

I make that 36 bits for PER and 112*8 = 896 bits for XML, a ratio of 1:25.

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