As we have often said, IONA's Artix ESB is unlike other ESBs, enough so that 
Anne Thomas Manes doesn't even like to call it one.

A few years ago one of our product managers was sceptical about the idea that 
Web services would resolve all customer requirements.

So we built into our configurable microkernel the ability to switch out 
communication protocols and data formats.  

I suppose some might disagree with our decision to use WSDL as the neutral 
interface format - this was in fact a long discussion - but when customers 
complain about the performance of SOAP/HTTP we suggest a configuration change 
to SOAP/IIOP, SOAP/JMS, fixed format/IIOP, fixed format/JMS, etc.  The 
interface does not change, and in fact if you need two communication protocols 
and data formats for the same service we can do that too.

In the future we expect to support programming models the same way - i.e. these 
are configurable too.  

So I would just respectfully suggest that the characterizations of ESB here may 
not apply to all products that call themselsves an ESB, only those with a fixed 
communications protocol and data format.

Eric


----- Original Message ----
From: Bill Barr <[EMAIL PROTECTED]>
To: [email protected]
Sent: Tuesday, April 3, 2007 1:21:23 PM
Subject: RE: [service-orientated-architecture] Kaufman on Reuse & SO

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] com  
 




From: service-orientated- architecture@ yahoogroups. com [mailto:service- 
orientated- architecture@ yahoogroups. com] On Behalf Of Jerry Zhu
Sent: Tuesday, April 03, 2007 9:22 AM
To: service-orientated- architecture@ yahoogroups. com
Subject: Re: [service-orientated -architecture] Kaufman on Reuse & SO


--- Steve Jones <jones.steveg@ gmail.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 




 
____________________________________________________________________________________
No need to miss a message. Get email on-the-go 
with Yahoo! Mail for Mobile. Get started.
http://mobile.yahoo.com/mail 

Reply via email to