I ran into two Web service related articles recently. One really resonated with me: Enable the Service Oriented Enterprise, in the MS Architecture Journal. It presents the Enterprise Service Orientation Maturity Model, or ESOMM. Okay, I know what you're thinking: eeeeeeeewwww, a maturity model! But it's a lot more interesting and useful than you think (and they distance themselves from that other MM in a sidebar). Lots of developers and some architects think about service orientation in terms of the famous four tenets. They are good guiding principles and very useful, but not what a lot of people mean when they talk about SOA, all caps. Sure, there's a lot of hype around SOA, but there is a real point there too. Many companies are trying to redesign their software infrastructure into a portfolio of coarse-grained, reusable services. To do that successfully, you have go way past the four tenets for individual services and think about how you're going to organize the whole thing. I spent a lot of time thinking about that problem when I was at Mindreef. This article really summarized a lot of what I'd thought about, and a bunch of stuff I hadn't, in a nice, easy to understand way. If you work at a company doing “big SOA”, look at ESOMM.
The other article, Avoid XML Schema Wildcards For Web Services Interfaces, appeared in Internet Computing, but can't be downloaded without purchasing (which is pretty crumby, guys!). I got my copy forwarded by an interested reader who wanted my opinion on the position it took. I agree with the beginning of the article, which was disagreeing with the schema techniques described by Dave Orchard (and reiterated with slight variation by Dare) that were embraced by the W3C TAG. This approach is just too complicated in practice. The second part of the article described a versioning model that supported backward compatibility (old sender, new receiver) but did not address forward compatibility (new sender, old receiver). The problem with this one-way compatibility is that it just doesn't work. Imagine a typical request/response message exchange between an old client and a new service. The request message must support backward compatibility so that the old sender (the client) can communicate with the new receiver (the service). But the response message must support forward compatibility so that the new sender (the service) can communicate with the old receiver (the client). Having one without the other is essentially useless. Supporting both was big part of what lead me to my own versioning model. I'm not saying there are no other approaches to versioning, but if they don't support both backward AND forward compatiblity, then they're not useful in the context of most Web services today.
Posted
May 19 2006, 02:30 PM
by
tim-ewald