And, finally, here is what really, really, really, really annoys me in what I hear presumable gurus say about service-oriented architecture: for no good reason that I can fathom almost everyone that I have heard speaking on the topic wants to bring systems built around message-queues under the umbrella of what it means for a solution to be "service-oriented." I find that notion to be as moronic as it is unfortunately ubiquitous.
Let's go back to the first principle of what a service is: it is a software entity that exposes a contract that defines everything a client needs to know in order to communicate with the service, including, but not limited to, the messages that the service will accept as input and return as output. That definition should not be in the least bit contentious.
Web services are the paradigm example of services because they expose a contract for communicating with them via WSDL. Yes, WSDL is currently somewhat limited in that it currently cannot accommodate policies, so we can't say, in WSDL, to which requests our service will respond. Yet, one can readily see how WSDL might be extended to permit that, and we can expect that it will be extended in that way soon enough.
However, there is nothing remotely akin to WSDL in message-queuing solutions. Message queues do not expose any information about the kinds of messages they are meant to receive. Therefore, message queues are not services by anyone's customary and useful definition of what a service is.
So, can everyone take those slides out of their decks, please. Thank you.