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.

Rails, REST, and Anarchist XML

've been digging deeper and deeper into Rails, concluding that after
many years of frameworks offering me more headaches than benefits,
Rails finally provides enough good for me to think it worth using a
potentially constraining framework... Today, by default, Rails
scaffolding does something really simple for XML: it lets you avoid
thinking very hard about the XML coming in and going out. Now, I know,
you could if you wanted create Builder templates that let you ensure
that all of the XML going out was perfectly structured according to
this or that specification, but you don't have to... Rails' RESTful
scaffolding also accepts XML documents coming in through PUT or POST.
Again, it's not advertising a formal schema (by default, anyway).
Instead it seems to be doing something like Examplotron -- look at
a sample document, see what's there, and imitate it. Rails can get
away with this for a couple of reasons. First, the type system within
Rails is extremely simple, and not that hard to specify within documents.
Second, Rails has a pretty thorough understanding within the framework
of how data flows - all that ActiveRecord goodness ensures that Rails
knows what's supposed to be in the data, and makes it more comfortable
sending and receiving without an external set of checks. Perhaps my
favorite part of this approach is that a lot of developers are
fixated on the HTML side of things, but the scaffolding generates
the XML side too. It comes for free. Left as it arrives, it's an
opportunity to open a much wider set of services to XML manipulation,
at zero cost to developers. (Well, except for some potential surprise
if and when people start using their services that way.) It's taken
a decade, and the Rails models are pretty much data-centric rather
than the documents I love working with - but we may finally be reaching
the point where XML is starting to behave the way Walter Perry said
it should, unconstrained by data structures negotiated in advance...

2008 Predictions: SOA, Grid, SCA, Web 2.0, REST

"(1) Grid computing will grip the attention of enterprise IT leaders,
although given the various concepts of hardware grids, compute grids,
and data grids, and different approaches taken by vendors, the
definition of grid will be as fuzzy as ESB. This is likely to happen
at the end of 2008. (2) At least one application in the area of what
Gartner calls 'eXtreme Transaction Processing' (XTP) will become the
poster child for grid computing. This killer app for grid computing
will most likely be in the financial services industry or the travel
industry. Scalable, fault tolerant, grid enabled middle tier caching
will be a key component of such applications. (3) Event-Driven
Architectures (EDA) will finally become a well understood ingredient
for achieving realtime insight into business process, business metrics,
and business exceptions. New offerings from platform vendors and
startups will begin to feverishly compete in this area. (4) Service
Component Architecture (SCA) will become the new way for SOA applications
to be defined as support from all the major platform vendors (sans
Microsoft) will be rolled out... (9) By end of year it will be clear
that an understanding of infrastructure requirements for common
problems such as predictable scalability, reliability, security,
(*-ilities) will be necessary in order to support any combination of
SOA, REST, or Web 2.0 style applications. However the exact architecture
or even the list of requirements in support of such infrastructure
will not be well understood or agreed upon. Such a common understanding
will not come to bear until at least 2010. This will be the new
frontier to explore in the coming years..."