When architectures collide...

At the last WS-I community meeting in Miami, Gudge observed that the WS-* protocols were designed to support lots of possible architectures. On the surface, that sounds like a good thing. We want a technology that can adapt to fill different needs over time. Consider COM as an example. While many opponents of that technology saw it's changing role over time as evidence that it lacked a well-defined architecture, I always thought it was a sign of strength that COM could be adapted to create OLE, ActiveX, DCOM, OLEDB, MTS/COM+, etc., all of which solved different classes of problems.

But even in COM, we agreed on the basic architecture of components, interfaces, creation, endpoint resolution, etc. We need to agree on the same things for Web services. As Steve recently observed, however, we don't seem to be making much progress toward a shared vision of a Web services architecture that everyone (or even most people) agree on. Instead, we agree on a bunch of protocols that are open enough to lead to all sorts of problems.

The one that really worries me is the issue of semantics that I posted about the other day. What happens if one toolkit sees the value of the WS-Addressing Action header as the source of meaning in a Web service request and another toolkit that ignores that URI and focuses on the expanded name of the element in the message body instead? What if each toolkit ties security and other policy statements to the value it is interested in? Will we still get interoperability?

All of these issues will presumably be grappled with by the W3C's WS-Addressing group, which is to my mind the single most important standardization effort for Web services going at the moment (yes, even more than security). This is the place where the actual system architectures that vendors are supporting with their infrastructures will come to light. WSA is likely to change how aspects of SOAP works (which is a legal thing for a header to do). For instance, wsa:ReplyTo might trump the SOAP HTTP's binding requirement that a response ride the transport backchannel. More interesting, could wsa:Action trump the meaning of soap:Fault?

Reading some of the archive of the WG's mailing list, it's clear to me that that's the place to lurk if you want to watch different vendors' architectures collide!