I think you've just evaluated a poor product.
We evaluated every single commercial and open-source ESB product
available on the market, last spring. When we tore out the ESB stack and
just evaluated the underlying message/transport backbone, we began to
see numbers we were expecting to see. In fact, when several ESB vendors
saw our performance requirements, they withdrew themselves from the rest
of the selection process.
Let me make it clear that I'm referring to ESB products, not the ESB
concept.
--
email: [EMAIL PROTECTED]
________________________________
From: [email protected]
[mailto:[EMAIL PROTECTED] On Behalf Of
Hitoshi Ozawa
Sent: Tuesday, April 03, 2007 10:27 PM
To: [email protected]
Subject: Re: [service-orientated-architecture] Kaufman on Reuse
& SO
Hi all,
Back from my assignment. All is going well.
SOA is picking up here in Japan and keeping me busy.
Point I've made at my last customer - SOA is not just about
business as
SOA is not just about IT.
Assess business resources and IT resources and establish what
can be
done within the given timeframe
before going into a project.
That said, I agree with you on your evalutions, but I'm
perplexed about
your conclusion of using ESB.
ESB does not imply BPEL and WS* - ESB can be used with JMS and
something
faster.
The extra endpoint abstraction ESB offers does have a little
performance
effect but is was way less than an order
of a magnitude. The benefit of ESB is that it allows me to
switch to
something faster by abstracting the service endpoints.
I think you've just evaluated a poor product.
Cheers,
H.Ozawa
Bill Barr wrote:
> 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.
>
>
