Re: Article: Fat protocols slow Web services

Kurt,

In my understanding, Python _is_ a strongly-typed language. It's just 
dynamically typed, not statically typed. C would be an example of a 
language that is weakly typed (but it is statically typed). So, I think 
the dynamic / static typing contrast is the one you're going for.

Also, a counter example to web services for business is the nascent 
effort from some academic and government research institutions to use 
web services as an interoperability layer for the Grid 
[http://www.gridforum.org], an international high-performance computing 
infrastructure (see, e.g., http://www.ibm.com/news/us/2001/08/092.html ).

Dan

Kurt Cagle wrote:

>>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 10:55:43 UTC