Re: Article: Fat protocols slow Web services

This has been a fascinating discussion, and with most such issues there are
many good points on all sides. I will be the first to admit that my
expertise in not with large enterprise systems; I am writing from the
vantage point of what I have seen, and there are others here who are far
more familiar with the day to day issues of making systems work.

Ann's comment about the need to tailor the architecture to the application
is a good one, but it doesn't get back to the root cause of my concern.
Intelligently designed, richly threaded applications can work well in either
messaging or RPC environments. The question that I have is whether most of
the applications out there will be designed with an eye toward
asynchronicity, multi-threading, and other techniques to insure scalability,
and whether the fundamentally client/server architecture of RPC oriented web
services can in fact scale effectively in the face of tools that disguise
the fact that web services as written are synchronous.

This is less of a concern on the Java said than it is with the legion of VB
programmers out there who are still working with a point and click interface
as their primary interface mechanism. The notion of asynchronous listeners
in Java has been deeply ingrained in the language from the beginning.
However, having both been a VB programmer at one stage in my career (in the
immortal words of the man transformed into a newt in Monty Python's Holy
Grail, "I got better!") and advised people in the VB community, I know first
hand that there are huge number of VB programmers that have only a vague
inkling of the way that event-based programming in general work, and their
tools of choice are essentially single thread apps. In the vast majority of
cases, this isn't a problem in the kinds of environments in which they work
because the demand level is very seldom to a point where scalability becomes
an issue, but the combination of being able to do synchronous .NET services
on the Internet transparently worries me more than a little.

On a different topic (actually the original one) we're in transition
concerning protocols. Realistically HTTP isn't an ideal mechanism for
performing web services calls, but it has the advantage of being ubiquitous.
Protocols such as BEEP (which was recently adopted by the IETF) are probably
more likely to handle the next generation of web services architectures of
both types, and BEEP is built around XML at the transport layer, rather than
at the application layer as it is with HTTP.

Finally, a clarification about "business processes". There is the idealized
business processes that tend to be the bullwark of EAP - the mythical
"enterprise" which is usually characterized by faceless drones in
accounting, fearful of losing their jobs, the highly faced marketing types,
etc, and then there is reality, which is infinitely messier and harder to
quantify. However, I think that the use of centralized APIs and the concept
of the division server as an object mechanism makes a great deal of sense
here. It's not surprising that the server-centric model of web services is
so central to so many vendors - they recognize the fact that there are
significant advantages to consolidating the complex (and often contradictory
or unnecessarily redundant) code that is produced in most companies every
day.

However, this is also only one area where XML oriented web services have
utility, and other areas have different requirements for web services that
in many respects are far more oriented toward the messaging rather than the
RPC architectures. The point that I'm trying to make here is not to say that
one solution should fit all problems -- it obviously shouldn't -- but that
we don't let the requirements of this one very small but very vocal (and
well-heeled) group of software consumers dictate the shape of all web
services architectures.

* Stepping off the soapbox, no doubt to the relief of everyone else. *

-- Kurt

Received on Wednesday, 9 January 2002 13:20:31 UTC