Lately I've been posting thoughts here about multi-protocol endpoint references (EPRs). Jim Webber comments that he prefers a single kind of endpoint per EPR, i.e., having one or more SOAP endpoints in an EPR would be ok, but having a SOAP, MQ, and IIOP endpoint in the same EPR, for example, would not.
Seems like a needless restriction. Jim says we should just "accept that Web Services are about SOAP not WSDL." If the EPR or the WS-Addressing spec becomes extraordinarily complicated by adding optional support for things other than SOAP, then I agree, let's not go there. Fortunately, that doesn't need to happen. There are a boatload of existing and valuable services in all the enterprises out there that, with a suitable approach, can be brought forward into the service-oriented present in an economically viable manner without requiring them to be rewritten, retested, requalified, and redeployed just to make them speak SOAP.
Web services are not so much about SOAP as they are about messages and contracts, rather than being about ubiquitous object models and specific infrastructure implementations as with prior approaches. SOAP is certainly a good way to encode such messages, but it's not the last good way we'll ever see. WSDL is, however, a great way of describing and abstracting services, one that can last for quite awhile because it's a step removed from specific technologies. It supports SOAP, but does not require SOAP. Through its extensibility, WSDL can also support the older protocols and message formats that are still important in today's enterprises. As underlying technologies like SOAP come and go, and they surely will, WSDL and its extensibility can accommodate them.
Look at CORBA IDL. It was defined years before IIOP, and was used with a variety of vendor-specific protocols and transfer syntaxes before IIOP was created. What's interesting is that IDL didn't change at all when IIOP came along. It worked for IIOP-accessible systems and yet continued to work for all the older vendor-specific protocols too. This allowed vendors to support the then-new IIOP interoperability standard as well as continue to support their own protocols, all without requiring their customers to make any application changes. CORBA would likely have died in the mid 90's if not for this fact, and yet here we are ten years later and it's still going strong.
Now, let's not get into yet another "WSDL is not IDL" argument. I'm not talking about objects vs. services, statefulness vs. statelessness, or any of those kinds of arguments. That's not my point. My point is that, just like with my business card analogy, what matters is the service and its contract. How I access the service might change over time, or might even change from one day to the next. What I'm ultimately interested in, and what ultimately provides business value, is the service, not the pipes leading to it. In other words, it's the end, not the means, that matters.
It all comes down to which word of the two words in the phrase "web services" you focus on. Jim, I would guess, focuses on the "web" part, hence his opinion that SOAP is all that matters. My colleagues and I, OTOH, focus on the "services" part, because most "web services" work today occurs within the enterprise, where a variety of protocols and message formats are a fact of life and will be for quite some time. There's no reason that I'm aware of that WS-Addressing can't serve both of these viewpoints equally well.