OK, so the title is a little facetious (back at ya Mark), but this post by Matt Garland sums up how Web Services should be. These are not baby steps, these are huge leaps and they aren't mired in Web dogma.
We as a community have managed to make something so simple as Matt describes into a complex tangle of mess and hyperbole. We should be ashamed. Matt's post and the Microsoft enterprise architecture documentation are, as far as I am concerned, the cutting edge of Web Services architecture. Everybody should read them.
Matt does make a point on semantics though:
BookOrderShredders, on the other hand, could conceivably define a BookOrder, but surely the results of posting a message to their endpoint are different! So I potentially have to distinguish between the outcomes of posting the same message to two different web services. I'm not aware that WSDL provides the means for making this distinction.
Even in a RESTful situation BookOrderShredders would still have different semantics to the BookMonger service. The semantics are defined by the service and presumably either written in natural language as part of the service documentation or as some machine-interpretable semantic description. However, I must stress that the semantics of a message exchange are not part of the Web Services architecture, but part of the application. As Matt points out, this is effectively some:
"...combination of the endpoint and the message."
This is very encouraging indeed.