Sunday, April 10, 2005

Canonical Message Format and XML Schema

I have lived with and without a canonical message format on messaging projects. I think that they are absolutely crucial if the project is going to survive and be extended over time. If its just a one off integration that uses messaging, I guess you could get away with hacking the message format, but even then, I'd be leery as business who experience message based (i.e., SOA, event based integration etc.) tend to get hooked on the concept once they understand it and want to grow/reuse services. When XML is your message body, XML Schema is the natural choice to define the canonical message format. Different industries tend to have different industry standards for helping to define the canonical message format for a given business. I'm simply astounded at how unusable these industry standards are. I have found that the standards bodies don't take usability of these standards into account. Using any of them out of the box is simply out of the question typically. But I've seen companies try over and over again. Eventually, they all drift from the "standard". Sadly, their canonical message format often drifts too. As the company forks from the industry standard schema, they don't write and enforce their own. Instead, the schema ends up being held within the code of different services and in the minds of the developers of the services. This scenario leads to a lot of problems. Try testing a canonical message format like that. Try bringing new developers on board. Try extending your SOA/ESB, etc. etc. A canonical message format is the key stone to a successful SOA/ESB. I have had success using XML schema to define the canonical message format. The teams I have been on typically start with an industry standard and then dumb it down dramatically. Sadly, the writers of the industry standard schemas typically put every feature of the schema spec including the kitchen sink in their schemas. Try running that through Castor, JAXB, XMLBeans, .NET xsd.exe. I think good tool support is crucial as well. I mean if you are going to go to the trouble of writing the schema down down you want it to help you develop your SOA? Afterall, XML Schema really is just an IDL. Why shouldn't you expect tool support? Anyway, this is a rant I guess. But my advise on canonical message format is: 1. Get one 2. Make sure that there is tool support for your format (e.g., JAXB, Castor, .NET xsd.exe) 3. Do not under any circumstances compromise your canonical message format for a quick hack. 4. Nurture it

1 comment:

Anonymous said...

i am planning to create a canonical format for a financial services product.how exactly we should proceed,i am not sure how it should look,could you guide me through.
Thx in advance