Ouch, that must have hurt:

Web Services Addressing is trying to define an addressing scheme that can work over HTTP, SMTP, FTP, and any other protocol you can imagine. However, each of these protocols already have their own addressing systems. Developers working with these protocols don’t want and don’t need a different addressing system that’s marginally more compatible with some protocol they’re not using in exchange for substantially less compatibility with the protocol they are using. Besides nobody’s actually doing web services over anything except HTTP anyway. Doesn’t it just make more sense to use the well understood, already implemented debugged HTTP architecture for this instead of inventing something new?

This is taken from Elliote Rusty Harold’s link to the WS-Addressing spec’s becoming a candidate recommendation. Ted Neward has a thoughful response, arguing that ERH is completely missing the point. I think it’s just a matter of perspective: for Web scenarios, nobody uses anything but HTTP anyway, and for the vast majority of company-internal use-cases, I’d consider HTTP to be a much better solution than some vendor’s proprietary messaging middleware. But even if one assumes that HTTP is going to become the protocol of choice for EAI as well, WS-A still has merit to support asynchronous processing of SOAP messages.

Dave Orchard, in an email to the WWW-TAG mailing list that ERH linked to, noted that

Effectively, the Web services architecture is a separate architecture from the Web architecture […] This separation, based upon SOAP and WSDL, is growing with the expected widespread adoption of WS-Addressing.

As I wrote before, I no longer believe the two architectures can be (cleanly) aligned. But so what — healthy competition is a guarantee for movement, and fuels a decent amount of weblog entries …