> From: Michael Brennan [mailto:]
>
> 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.
Because at any given time code is being written to get 2 endpoints
communicating, not n endpoints. The developers are in a hurry working
under unrealistic deadlines and expectations. So, for any 2 endpoints
and given enough developer stress, an RPC is the right thing (it gets
the network out of the way quickly, so you can pretend you're writing
procedural code in a single thread of execution). Even if you had 3 or 4
endpoints, you can always decompose the comms into pairs (divide and
conquer as anti-pattern). Then one day you wake up to find you have
_lots_ of pairs making RPC calls and trying to reorder of repurpose some
of them (or heaven forbid, their databases) without breaking something
else somewhere else is extremely difficult; there's too many
permutations and the network is suddenly not the sum of its parts
anymore. You're out of control of the code.
Bill de hÓra
