[
Lists Home |
Date Index |
Thread Index
]
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.
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.
Messaging with it's Point to Point and Pub/Sub approaches tends not to suffer
from this type of problem, since it is obvious to the developer when they are
issuing network calls or not. RPC also doesn't have the concept of Pub/Sub
which is a very handy approach to many problems (you can do it with RPC,
but have to roll your own).
Typically you also find that Action => RPC => Synchronous versus Data =>
Messaging => Asynchronous. Many developers seem to want to avoid
asynchronous processing, which is a shame since it tends to scale much more
linearly than synchronous approaches (in general).
There is a good article on the evils of RPC that might be tangentially relevant
to this whole topic:
http://www.omnifarious.org/~hopper/technical/corbabad.html
Worth a read. The author makes some interesting points about the evils of
RPC, that apply to Web Services.
Andrzej Jan Taramina
Chaeron Corporation: Enterprise System Solutions
http://www.chaeron.com
|
