I'm going to have to stop using fake equations as the titles to blog posts, people read too much into them. But in this case I think I have a point.
Steve blogs:
I take issue with the purists who say that a "web service" is defined as a SOAP-based service, nothing more, nothing less. It's like saying that a Domino's pizza shop shall only take verbal orders over the phone, and if it accepts orders via a website or by fax or from a person who physically walks into a shop and verbally speaks their order to an employee, then it's not a Domino's pizza shop. Obviously such a restrictive definition is pointless, because what customers ultimately want is the service that Dominos provides, regardless of how they request it. Similarly, what ultimately matters with a "web service" is the "service" part, not the "web" part.
Well I guess Steve must have an issue with me then because I am a purist. If Domino's want to expose a fax interface to their business, that's fine. If they want to expose a HTML interface, that's fine too. And if they want to expose an object accessible via RMI, that also is fine. (Well it isn't but play along.)
The fact is that none of these are Web Services. They might be CORBA interfaces, they might be Java objects but they are not Web Services. One of the problems with the kinds of Web Services arguments that Steve alludes to is entirely the fault of WSDL. Why WSDL had to have different bindings for various transfer protocols I simply do not know. All it really needs is a SOAP binding.
Why have a CORBA binding in WSDL? We already have IDL which does that job. Why have a Java binding? Why have a DCE binding? Why have a DCOM binding? You see where I'm going here - there are already interface definition languages for all of these, so WSDL didn't need to go round providing bindings for them (ok - allowing bindings for them).
So onto the scene strides WS-IF. I've blogged before about this glue and I am not a fan. The point is that an entity (I won't call it a service) designed to be consumed by RMI just won't be a good fit for a service designed to be consumed via SOAP. So you can bind this entity to anything you want, but there will only be one comfortable fit - the native binding - and why do I need WSDL in that case?