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

Saturday, January 15, 2005

Finally got a Mac

I've wanted to buy a Mac laptop for over a year now. A couple of weeks ago I finally bought one. I bought a 15 inch Powerbook with a superdrive (guess you can burn DVDs and what not). I am enjoying this new computer. MAC OS X is a great operating system. Its fun to have a new toy. I also set up a wireless network in our place. It was a lot easier than I thought. To help make room for the baby on the way I am in the process of selling the parts of the computer I built 5 years ago on eBay. I am surprised at how well some of the parts are doing. The case alone is going for $100. The auction will be complete in a couple of hours. Then I'll ship the parts of to their new owners. I started a new class for grad school. Seems like it is going to be rather hard, sadly. I am taking OMSE 522 -- Modeling and Analysis of Software Systems. Basically, its using discrete math to specify requirements specifications. It looks like it will be a ton of fun (sarcasm). I haven't done any real math since college and I never took this specific type of math. I need to buy a second book for the class today at Powell’s Technical Books down the street here in Portland. Its a book on the actual math involved. The class is on applying the math to software requirements. Ok, off to pack things for my eBay sale, etc.