I'm reading Nature's Numbers by Ian Stewart at the moment. It is an
interesting book that promises to explain to me why physical symmetry
(in the "two legs, two arms" - sense), breaks down at a certain level
of detail (why is your heart positioned left of center? Why have we one
liver but two kidneys? And so on.). I have always wondered about that.
It also promises to examine complexity and chaos theory from a purely
layman's perspective, which I am looking forward to. I feel it behooves
me to keep up to date with all the analogies being used to explain this
stuff to non-math types like me. Especially, given that I drop
references to numbers like "4.669" in April Fool jokes on XML-DEV
(http://lists.xml.org/archives/xml-dev/200204/msg00000.html).
Stewart's book is only the second publication I have ever read that
uses the word "reification". The first was the RDF specification. Its
presence in that specification helped a non-zero number of people to
leave RDF on the proverbial long finger. Having read about reification
in Stewarts book, it is no longer scary to me. More importantly, I
think the concept cuts to the heart of a very important and
occasionally highly charged ongoing debate between two Web
philosophies: the REST school versus the SOAP school.
Stewart uses the term "thingification" as a simple explanation of
reification. Simply put, it is a way of viewing the world in which
processes are treated as real things, just as if they had a physical
reality. "Bananas", for example, are things, while "farming" is a
process; a "water boiler" is a thing, but "heating" is a process. And
so on.
Now put this into a Web context. Say I want to publish my electronic
bananas on the Web. How do I do that? First, I create a resource -- be
it an HTML page, an XML instance, whatever. Second, I give the resource
a name. A URI. Behold! http://www.seanmcgrath.com/bannanas.xml is born.
Now people and computers alike -- armed with nothing more sophisticated
than the "GET" verb in the HTTP protocol -- can interact with my
bananas. A stunningly simple, rampantly successful, demonstrably
scaleable way of building everything from electronic news sites to
interactive applications.
But what about things that are processes, like "searching" or "buying
books"? How should these be made available on the Web? A reificationist
(!) would argue that such processes can be treated the same way, with
the same infrastructure:
- Step 1: Create a resource -- Most probably XML because it allows
machines, and thus other processes, to interoperate.
- Step 2: Give that resource a name -- The name is a URL. The
fundamental verbs of the Web - GET and POST -- can then be used to
interact with the processes in exactly the same stunningly simple,
rampantly successful, demonstrably scaleable way of building everything
from.... You see where I'm going with this.
Part of the glory of the Web is the way it subverts any attempt at
distinguishing "thing" from "process". A resource is anything that has
a URI, which is all you need to be "on the Web". Some resources are
real things, some are processes. Software can treat both types of
resource uniformly. They are all services available on the Web be it
Intranet, Extranet or Internet. Web Services if you like.
This is where things get very interesting. SOAP, the latest silver
bullet to hit software development, does not work this way. Its notion
of "on the Web" is rather different. Yes, services have URIs but you
cannot treat them as if they were simple resources like XML documents
or HTML pages. They are not merely "things" in the great primordial
soup of things on the Web. To talk to SOAP services you must jettison
much of what you know and have already and deploy new infrastructure
and new paradigms, infrastructure specific to talking to SOAP,
infrastructure that takes away your rubber-on-the-road Web experience
with helpful APIs and wizard tools that do all the work for you.
Last weeks article on the dangers of APIs
(http://www.itworld.com/nl/xml_prac/04182002/) are relevant here. What
do I want a new API for? I have a really simply one that works called
HTTP GET/POST. I have a rich way to pass data structures in-and-out of
URLs called XML. What more do I need to play the game?
Nothing. Not only do you not need anything else to start playing the
game, you should beware of big vendors bearing gifts to help you play
the game. Gifts of APIs to "help" you deploy an infrastructure for
which there is, perhaps, no need, a need that is, perhaps in the best
traditions of marketing, created by vendors for vendors.
Perhaps the Web's greatest strength is its reificationist base. A way
of looking at the world in which things and processes are treated
uniformly by a small set of permissible actions (HTTP verbs) sitting on
top of a universal namespace known as the URI namespace.
I suspect an element of the data-head versus doc-head divide surrounds
all of this. As a self-confessed doc-head, I find myself gravitating
towards a position that has become known as the REST architectural view
of Web Services. Data-heads, lean the other way in my experience,
towards API based approaches.
The recent interest caused by the SOAP API to Google has brought the
philosophical debate to a head. A very simple, HTTP GET-based mechanism
for talking to Google has been replaced by a SOAP-based mechanism. To
use the former, you just concocted a URI and plugged it into your
browser/spider/EJB whatever. You got back an XML file. Easy.
Today? Well today you need new infrastructure. SOAP stuff. Its all API
based. Geeks are back in your mailbox muttering "interface" and "you
need to be qualified to do this". Consultants and vendors are hovering
in the corridors sniffing Purchase Orders.
Speaking as a geek and a commercial software developer, there is
nothing to be proud of here for my industry. The Web currently gives us
all the rope we need to build systems that add value for customers.
SOAP seems to be two steps backwards, which, at best, will bring us two
steps forward to where we are today. At worst, it is a small crack in
the Universal Namespace that will grow into a fully blown crevice in
the infrastructure. A crevice perhaps too deep to ever crawl out of.
Lets hope not.
