|
I've noticed that
many people in Internet circles where I travel have started to use the term 'web
services'. But I see little evidence they truly grasp the nature of this new and
somewhat confusing idea. As terms go, this one was likely coined by someone who
didn't give it much thought - probably the same person that came up with
'weblog'; another poorly architected term whose concrete has dried.
Loosely-Coupled.com defines web services with
elegance.
"Automated
resources accessed via the Internet. Web services are software-powered resources
or functional components whose capabilities can be accessed at an internet URI.
Standards-based web services use XML to interact with each other, which allows
them to link up on demand using loose coupling."
In addition to this
definition, I like to apply a simple test to determine if an information
architecture is truly a 'web service'. If the technology in question can be used
to create solutions that the designers didn't plan for, it is indeed a web
service architecture. Unintended
consequences and the ability of the technology to outlive its intended objectives;
that's what qualifies it to be a web service in my view.
For all the rave
that blog tools are making in the trendy space of loosely-coupled applications,
I have to point out that none of them are actually architected as web services.
Sure, you can find instances of web services surrounding their monolithic
client-server designs, but few have actually built their platforms with the
intent of creating unintended consequences. I appreciate that most blog tools
provide RSS and RDF feeds, but these features hardly qualify them to be
considered web services. The Blogger API makes a fair attempt, but it's limited
to a very narrow set of use-cases that inevitably surround a mostly rigid
framework.
As blog tools grow
up, instead of downloading a complete weblog platform, you'll simply pick a few
'collaborative lego's(tm)' off the shelf and assemble the desired weblog
features. One of the legos will provide (properly encoded) remote storage, while
another will include a rich-text editor of your liking.
In the near future,
content management systems, [whether for personal publishing tasks, or
enterprise-wide knowledge management solutions], will likely be the result of
users' interpretations rather than a single company's product vision. It will be
people like us that build these future systems. Our intended designs will be
someone else's unintended consequence. | 
