WSDL blows!!! My thoughts exactly ...

I am a WSDL and SOAP hater. I have worked on various IDL based systems (e.g., CORBA). When WSDL came out I just looked at it as another IDL. 2 years or so ago I worked with an early version of Apache Axis to build a web service. The web service had to interoperate with .NET. It was truly TRULY hell. Yes, "hello world" is easy and sending a couple dozen Strings around is doable, but try sending a very complex structure around and see how much fun it is. Especially if you are naive enough to think that WSDL is an IDL and you SHOULD start with it first to define your service contract like ... well every IDL before it. After a lot of work, I got it to work. It was a minor victory, but not something that I wanted to repeat. I've tried to avoid web services ever since. I think that WSDL and SOAP meant well, but are doomed. Sadly, much effort has been put into them by many infrastructure companies. By the looks of this theserverside.com article and the links hanging off of it, I am far from being alone in my opinion. How else could there be so many potential replacements for it? I shudder to think where it will all end. Will WSDL/SOAP be shot? Sure looks like it. That should throw a wrench in a couple companies’ product plans. I do like XML and think its a good choice for integration. I favor an event driven approach (e.g., pick a good messaging system (one that does pub/sub for real) or better yet, a good EDA vendor that runs on top of one like our product). I like EDA because it is so configurable and flexible. You don't have to embed the definition of everything in the service definition like you have to with WSDL and all WS-X specs. You just define a simple service - like an Action in struts / event handler in anything. You then use the infrastructure to configure what channels it listens on. EDA has its issues, it isn't a silver bullet, but it is far easier and practical for enterprise integration IMHO.

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

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.