Web Services: RPC, REST, and Messaging

How to choose a model for interoperable communication in the enterprise?
For the implementation of Web Services in the enterprise environment,
I've seen many different technologies used. Recently, in my spare moments,
I've reflected on this and have come to the conclusion that all these
technologies tend to fit one of three models (or hybrids of these models).
I would summarise these three models as: (1) Remote Procedure Calls (RPC).
A client-server based remotable pattern where a subset of an existing
system's local functions is exposed pretty much 'as-is' over the wire
to client programs. (2) Resource-oriented Create-Read-Update-Delete
(CRUD). A client-server based resource-oriented pattern where the
server-side provides a representation of a set of resources (often
hierarchical) and exposes Create, Read, Update and Delete capabilities
for these resources to client programs. (3) Messaging (e.g., as commonly
seen with Message Oriented Middleware and B2B). Messages or documents are
passed asynchronously between peer systems in either, but not always both,
directions. Sometimes its hard to distinguish between these models and
where the boundaries lie. In fact, I don't think there are boundaries,
only grey areas and all three models lie in the same spectrum. In the
Web Services world, we may typically implement these three models using
one of the following three approaches: (1') Remote Procedure Calls: SOAP
using a synchronous RPC programming approach and, typically, generated
'skeletons/stubs' and some sort of Object-to-XML marshalling technology.
(2') Resource-oriented Create-Read-Update-Delete: REST or 'RESTful Web
Services' or ROA, re-using World-Wide-Web based approaches and standards
like HTTP and URIs. (3') Messaging: SOAP using an asynchronous
Message/Document passing approach where invariably the documents are
defined by schemas and, often, the use of message-level (rather than
transport-level) security elements is required... When faced with the
REST zealot or the WS-* zealot, we probably need to bear this spectrum
in mind. For the Web Services paradigm, there is not a 'one-size fits all'
and specific requirements for a given situation should dictate which
position in this spectrum best lends itself to satisfying the requirements.
Also, the overlap between the models may be greater [than shown in the
diagram]. For example, some would argue that REST can happily and more
appropriately be used to fulfil what would otherwise be RPC oriented
problems, in addition to solving Resource-oriented CRUD style problems.