Recently I've noticed several blogs containing commentary on my most recent Toward Integration column, entitled "Web Services Notifications". It's always great to get such feedback.
Over in the Brain.Save() blog, Steve Maine questions my comments regarding WS-Eventing's reliance on WS-Addressing. Contrary to Steve's comments, I didn't explicitly say that WS-Addressing pins you down to a specific transport; in fact, I make that pretty clear in the first paragraph in the column section entitled "WS-Addressing" that it's transport independent. Later, though, where I say that WS-Eventing should use WSDL service references rather than WS-Addressing, I did imply that WS-Addressing is limited to SOAP over HTTP, and that's where Steve takes me to task. I should have simply said "SOAP" there and left it at that. What I was really trying to imply there was that WSDL is extensible well beyond just SOAP, allowing for many different types of bindings, and using WSDL service references would make all such bindings usable in a WS-Eventing context.
Steve also questions my concerns about metadata discovery, or the lack thereof, in WS-Eventing. He says that other specs such as WS-Discovery and WS-MetadataExchange provide this, so there's no need for it in WS-Eventing. Steve makes a good point, but this points out a fundamental flaw in the WS-Eventing specification: it makes no mention of its reliance on these other specs. A simple paragraph containing a brief discussion of metadata discovery containing pointers to these other specs would suffice. Turning these specs into real standards would help eliminate such hidden assumptions and their resulting lack of clarity.
Mark Baker also commented on my column. Yes, Mark, I did expect your comments! :-) One of Mark's comments was about my discussion around the difficulties of using URIs to represent some types of endpoints such as message queues. I don't disagree with Mark that you could devise a way to do it, but it's just that there's no good standardized way to do it. I mean, if worse came to worst, you could use a URI with the stringified OMG interoperable object reference format ("IOR:" followed by any number of hex digits), especially given that a single IOR can simultaneously represent any number of endpoints, regardless of the complexity of any individual endpoint being represented. But I suspect most people would not want to take that approach. Also, I dislike Mark's suggestion of setting up a service that doles out HTTP URIs to represent resources like message queues, because in a production system, it means you've got another moving part that can not only go wrong but also requires additional deployment, management, and maintenance.
Finally, some bloggers disliked what I had to say about the proprietary nature of specifications such as WS-Eventing. For example, in addition to his comments described above, Steve Maines also commented on this issue. His comments seem to imply that I believe we should go away into some standards never-never land and wait until we have designed-by-committee consensus standards around all these Web Services areas. Hardly! I hate standards bodies as much as the next guy -- probably even more than the next guy, actually, because of all the standards work I've had to do in my career. In reality, I don't fault these companies at all for pushing ahead with these specifications. Instead, I fault them for the following:
- The heavy IP rights tied to these specifications, which makes it very unclear whether companies or individuals who are not authors can even implement them. If I go implement WS-Eventing, for example, will the authoring companies come after me for taking their IP?
- The companies seem to intend to standardize these specs, but only when they're good and ready to do so. Meanwhile, others who want to build similar systems are stuck either wondering whether they can use the proprietary spec or whether they should write a competing one. Either way, it's bad for the industry.
- Standards work is hard because, done properly, it clarifies, tightens, and removes ambiguities from a specification. SOAP 1.2 is a good example. Avoiding standardization just strands these specs at their current relatively low level of quality.
Over in the Centaurs Identity blog, the author seems to imply that standardization equals interoperability. Needless to say, this is false. Yes, the SOAP builders' effort were laudable and fruitful, but they succeeded because all involved were behind SOAP. For event-driven Web Services systems, we have at least two competing specs, WS-Eventing and WS-Notification (assuming WS-Events is now obsolete, since HP is a co-author of WS-Notification). Interoperability testing isn't going to help when there are multiple specs involved. Plus, there's much more to a standard than just interoperability, including APIs and features.
I'm currently in the middle of writing my next column, this time covering WS-Notification, which wasn't out yet when I wrote my previous column. So far I'm pleasantly surprised -- it's got a nice and complete set of features for event-driven systems, the specs are well-written, and all the dependencies between the specs and on other specs are clearly defined. Stay tuned.