[
Lists Home |
Date Index |
Thread Index
]
> From: Andrzej Jan Taramina [mailto:andrzej@chaeron.com]
<snip/>
> Roger proposes:
>
> > I have convinced myself that there are two fundamentally different
> > approaches to designing Web service XML messages. They are:
> >
> > 1. The data-oriented approach
> >
> > 2. The action-oriented approach
>
> It's not just Web Services that has this paradigm choice.
> Client server has
> wrestled with Messaging vs RPC for a long time as well. This
> seem to be just
> a continuation of the same debate.
I think there is some confusion over terminology happening, here. I don't
think "action-oriented" necessarily means RPC; it can operate at a higher
level of abstraction than that.
The way I was interpreting this is data-oriented = one-way messaging. You
fire off some information and you don't care what gets done with it. Very
loose couplings between systems, very scalable. It's an ideal approach when
you can get away with it. Action-oriented = request/response messaging,
although the response does not necessarily need to be synchronous. There is
simply an expectation on the part of the publisher of the message that there
is an endpoint receiving this message that will fulfill the intent of the
message, and will provide an appropriate response. RPC is just one narrow
case of "action-oriented" in this view.
I strongly suspect others are not viewing these terms the same way.
> Soap allows both paradigms, but it seems that RPC is the
> default modus
> operandi for many developers, probably since it looks like
> local method
> invocations and as such is easily understood. The problem
> with RPC has
> always been that the developer loses sight of the fact that
> the calls are in fact
> network invocations and as such have massively larger
> latencies. This causes
> no end of problems when inexperienced developers use too fine
> a level of
> granularity.
Yes, kind of like Java developers invoking a bunch of fine-grained "get" and
"set" methods on an EntityBean in an EJB app, rather than using
coarse-grained "value objects" as advocated by Sun's J2EE blueprints (and
then proclaiming that EJBs are not scalable). You are quite right that web
services are rehashing the same design issues that previous distributed
computing architectures wrestled with -- and web services developers will
repeat the same mistakes.
It is not simply because developers like the local method call approach.
Even in scenarios where you do not have that abstraction and developers are
having to build integrations between systems, I've seen a tendency to
immediately gravitate to building a bunch of hand-crafted, tightly coupled
point-to-point integrations. This is a challenge that EAI vendors have had
to confront in the marketplace. They have a sound solution to a very real
problem, but getting customers to pay attention and actually seek a solution
to this problem rather than just plodding along incurring the costs and pain
of fragile point-to-point integrations is a hard sell. From my own
experience, I have found that when things are working, you often can't get
anyone to pay attention to architecture. But if you are there at the right
time with the right solution when things blow up and everyone is wondering
how to prevent these sorts of catastrophes, you can start to get through to
people and get them to think a bit more about the architecture they are
employing. You have a brief window, then, to get folks to think about
architecture.
|
