[
Lists Home |
Date Index |
Thread Index
]
2/4/2002 7:29:15 PM, Michael Brennan <Michael_Brennan@Allegis.com> wrote:
>
>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 think this is a good interpretation, better than my reply equating "action
oriented" with "synchronous." There are a number of threads related to this
in xml-dist-app recently, and I think there is a growing realization that
these various message exchange patterns need to be supported explicitly in
SOAP 1.2 and considered when designing web applications/services.
Message exchange patterns are closely related to the issue of "coupling, and
this is brought out in the rant against the RPC paradigm that someone recently
posted a link to
http://www.omnifarious.org/~hopper/technical/corbabad.html
"if you think about it, all forms of RPC, including CORBA, require a fairly
explicit detailing of the messages to be sent back and forth. You have to
specify your function signature pretty exactly, and the other side has to
agree with you. Also, the way RPC encourages you to design protocols tends to
create protocols in which the messages have a pretty specific meaning. In
contrast, the messages in the SMTP or XML protocol have a pretty general
meaning, and it's up to the program to interpret what they mean for it. This
bumps RPC protocols up on the coupling scale a fair amount, despite the claims
of the theorists and marketers."
>
>I strongly suspect others are not viewing these terms the same way.
I am now!
> 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.
Right. And this will get easier when tools to support other message exchange
patterns -- on top of SOAP, there's no reason to throw out the baby with the
bathwater -- mature.
|
