There is nothing more mind numbing than sitting in a bland hotel conference room listening to people argue about the naming of an XML tag, or whether some complex type should have a status code (and what are the codes, oh that’s another half an hour).  If you’ve guessed that I’m referring to an industry standards meeting, you’d be right on.  There are those that revel in those exchanges, but I find them a bit pedantic.  Well, that was my week in Miami.  Situated in a hotel in downtown Miami (which these days looks a little like Beirut circa 1980’s) was three days of the quarterly IFX Forum (http://www.ifxforum.org) face to face meeting.  And there I am sniffing for packets on a badly implemented hotel wireless network.

Now, the good part of the meeting was that there is finally starting to be some really forward thinking on not only bank messaging architecture, but also on how various constructions of industry schemas are supported and embedded in web services architectures.  IFX has been making some great progress in this area.  IFX, for those who have not watched this space, is a banking data standard that incorporates messaging and data dictionaries for items like electronic bill payment, ATM/POS devices, foreign exchange, business banking, payments and now branch banking.  In fact they are involved in the IST Harmonization efforts with ISO, SWIFT and others to agree upon a single payment “kernel” that is supported across all those standards.  So they have been doing some great work in that area.  Overlaying that work is the work of their web services working group which has been piloting various IFX message constructions in SOAP wrappers and using WSDL, even now constructing WS-Security headers that are compliant to the security requirements of the various business areas.

I still find that with some of these standards, especially those that carried over structures from either EDI or DTD environments, that there is a basic misunderstanding about what is “interoperable” from a message standpoint.  On one extreme, you have what I call the “bulky” camp.  Those are the people that say that one large XSD constructed with a vertical macro “service wrapper” is REQUIRED for interop.  Oh and forget turning on validation for that schema, the lights would dim as EVERYTHING is contained therein.  On the other extreme are those that believe that interop can occur when two parties agree on data elements and context for those elements, which could occur at a macro or micro level.  Of course I subscribe to that school, tending to believe that composable elements at both the web service and the data level allow ultimate flexibility and infinite connections to business partners and processes.  Certainly with tools like BizTalk Server, smaller elements can be packaged into larger messages and data mapped to a variety of formats and applications.  Or as the “standards folk” like to say….it’s an implementation issue, ignore it….would you pass another stale muffin?

- Josh Lee