W3C home > Mailing lists > Public > xml-dist-app@w3.org > January 2002

Re: Article: Fat protocols slow Web services

From: Kurt Cagle <kurt@kurtcagle.net>
Date: Wed, 9 Jan 2002 01:37:19 -0800
Message-ID: <001901c198f1$3bb43290$9569fea9@seatails>
To: "Asynch Messaging" <asynch_messaging@hotmail.com>
Cc: <xml-dist-app@w3.org>
> Right on, man. But I've got to say that 85% of the developer base WILL
apply
> VB design principles (single machine, single user, ui oriented, functional
> decomposition) until they see it done differently and try it out.
> What can we do to make it easier to 'try it out'?
> How can we make asynchronous messaging more visible and visceral to
> programmers?
> Who is going to provide the 'asynch toolkit'?

I'd say there's a definite market opportunity there. Something of a
counterveiling force to the current largely synchronous web services mindset
is beginning to emerge, but it's still coalescing. For simplicity, call the
two groups the procedural and declarative camps (vast simplifications on
both sides, of course, but it gives the basic idea of where each stand). The
procedural group sees web services and XML as a way of extending the API
model to ever larger domains. In essence, to the proceduralists, the server
is also a COM object or a Java Bean - an entity with distinct properties,
methods, and events. This is a powerful vision, certainly, and in certain
domains it may actually work quite well ... but not all. The proceduralists
are framework oriented, prefer strongly typed languages, and usually tend
towards the vendor-driven APIs.

The declarational group, on the other hand, are much more oriented toward
stream based relational models that tend to diminish the importance of the
object in favor of the relationship. The people in this group usually favor
languages such as XSLT as the primary mechanisms for doing most operations,
with that XSLT acting as much as a routing and control interface as it is a
view generator. This group also tends to gravitate toward P2P architectures
where the notion of client vs. server becomes irrelevant; P2Ps primary
difference from C/S has as much to do with the relative strengths of the two
systems as anything. The declarative group also tend to favor messaging
architectures over RPC architectures, and are much more likely to adopt
solutions such as XForms, SVG, RDF (assuming that the encumbrance issues on
these can be resolved) than they are large frameworks such as Java or .NET.
Finally, they prefer weakly typed languages (I see a lot of people in the
Perl and Python crowds that fit in here, as well as the obvious hard-core
XML Technologies types).

Neither of these groups have a monopoly on the truth of course, and there is
a certain amount of crossover that will be inherent in either position. The
proceduralists will likely remain the dominant ones for some time to come,
because much of the momentum is in this area, but at the same time the
Internet itself and many of the critical tools for the Internet have been
the result of declarative thinking and methodologies. You see this in the
XML Protocol documents; XMLP can work just as well in a messaging as in an
RPC environment, but the paradigm that you adopt -- declarative or
procedural -- will largely dictate which portions of the XML Protocol
documents are important in your application.

My final thought on this (the fateful, "In conclusion") is that the web
services architectures are currently being driven by the vendors for
adoption within businesses. Business has a tendency to see itself as the
center of the universe, and so of course the proceduralist visions of web
services has a lot of that same strong-hierarchical modelling to it that the
business structures which underlie this vision also have. However, most of
the web is not business oriented, at least not in the commercial sense, and
it is this substrate web -- home of e-mail and mailing lists and message
boards and communal infrastructure -- that will likely end up proving the
longest lasting.

-- Kurt Cagle
Received on Wednesday, 9 January 2002 04:45:02 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:59:05 GMT