[
Lists Home |
Date Index |
Thread Index
]
Michael clarifies:
> 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.
You might be right there....
> 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.
Problem is most developers don't seem to think in this mode.
> Action-oriented = request/response messaging,
> although the response does not necessarily need to be synchronous.
True, but the tendancy (including SOAPs RPC) seems to be towards a
synchronous approach. Async request/response usually takes a lot of extra
coding (beyond synchronous RPC or even Pub/Sub messaging).
> 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.
A very powerful paradigm when used correctly.
> RPC is just one narrow
> case of "action-oriented" in this view.
Yes...but it is a common view.
> I strongly suspect others are not viewing these terms the same way.
Probably not.
> 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.
Plus ca change....plus ca meme chose as the "Froggies" like to say. I see
novice developers (and some not so novices) still struggling with concepts that
were solved decades ago in the mainframe world (ACID transactions,
reliability, etc.).
> 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.
Most of my developers have learned that their CTO/Chief Architect gets very
upset when they do this! <grins> Messaging is a good thing...
> 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.
To be fair, the cost of a more generic EAI solution from a vendor tends to be
massive.....so in many situations it seems to be cheaper to just hack together
the point to point stuff...or at least it can be justified that way. A case of "it's
easier to chip away at the budget" than to cost justify a large upfront amount
(even if it might end up cheaper and more flexible in the long run).
The EAI vendors are all going to probably go out of business (or change their
biz models very quickly) with the advent of Web Services, XML, SOAP et al.
> 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.
Seems to be human nature, alas. But there is always an opportunity at the
beginning of any project to develop better architecture. Sometimes it has to be
done "on the sly"....but you can usually slip it in.
Andrzej Jan Taramina
Chaeron Corporation: Enterprise System Solutions
http://www.chaeron.com
|
