Can't Network latency and reliability issues be
addressed comfortably with (asynchronous or
synchronous) reliable messaging and distributed event
driven ESB?
An ESB actually adds to the problem, substantially. It's even worse when
the overhead of XML is introduced. After we completed our ESB
evaluations last year, we basically concluded:
Use BPEL if we want to time processes with a calendar;
Use WS* if we want to time processes with a stopwatch;
Use JMS (non-durable) if we want to keep your jobs;
Use something faster to keep a competitive edge.
Of course, our real-time requirements are not typical but when we looked
at the numbers and saw orders of magnitude difference between
approaches, the way was clear.
--
email: [EMAIL PROTECTED]
________________________________
From: [email protected]
[mailto:[EMAIL PROTECTED] On Behalf Of
Jerry Zhu
Sent: Tuesday, April 03, 2007 9:22 AM
To: [email protected]
Subject: Re: [service-orientated-architecture] Kaufman on Reuse
& SO
--- Steve Jones <[EMAIL PROTECTED]
<mailto:jones.steveg%40gmail.com> > wrote:
> For highly interactive systems (such as plant
> management) don't under
> estimate the cost of network latency.
> The bigger drivers against shared infrastructure
I've seen have been latency and reliability, sometimes
there really are reasons to put the tin next to the
users.
>
Can't Network latency and reliability issues be
addressed comfortably with (asynchronous or
synchronous) reliable messaging and distributed event
driven ESB?
Jerry
__________________________________________________________
Expecting? Get great news right away with email Auto-Check.
Try the Yahoo! Mail Beta.
http://advision.webevents.yahoo.com/mailbeta/newmail_tools.html
<http://advision.webevents.yahoo.com/mailbeta/newmail_tools.html>
