Anil,
Besides, it is always fun (and, to me, educational) when Todd and Steve
get riled up. Now, if we could add in REST and some Jini ... :-)
I'm sorry but, I can't talk about Jini. It's a secret weapon. :) What I
can say though is that Jini makes ESBs and SOA in general, edge cases
for integration and B2B/B2C implementations. When I control the client,
service provider and the wires in between, I opt for something a lot
more performant, scalable and manageable.
Bill
--
email: [EMAIL PROTECTED]
________________________________
From: [email protected]
[mailto:[EMAIL PROTECTED] On Behalf Of
Anil John
Sent: Thursday, March 29, 2007 3:48 PM
To: [email protected]
Subject: RE: [service-orientated-architecture] ESB Standard
Definition
Bill,
Not at all! If the archives do not address your points (or at
least point to the areas of contention that your observations bring up)
please by all means, let me welcome you to the latest opening act of
this ongoing play.
Besides, it is always fun (and, to me, educational) when Todd
and Steve get riled up. Now, if we could add in REST and some Jini ...
:-)
BTW, while I am not an ESB (as a product) proponent (I believe
that the combo of products that we have deployed as part of our SOA
runtime infrastructure give us the capabilities that are typically
attributed to an ESB product with the flexibility to independently
optimize the implementation of a particular capability and w/o building
in a dependency on a particular vendor), I was intrigued by your
comments about your evaluation of Open Source ESB products.
I am always interested in how an Enterprise architects their SOA
infrastructure, and in particular how they see a particular product
mapping into their SOA. So I for one would be interested in knowing, if
that is something that you can share, how an ESB (and its various
capabilities) plug into your architecture.
Regards,
- Anil
________________________________
From: [email protected]
[mailto:[EMAIL PROTECTED] On Behalf Of
Bill Barr
Sent: Thursday, March 29, 2007 10:57 AM
To: [email protected]
Subject: RE: [service-orientated-architecture] ESB
Standard Definition
Well stated! I'll shut up. :)
________________________________
From:
[email protected]
[mailto:[EMAIL PROTECTED] On Behalf Of
Anil John
Sent: Wednesday, March 28, 2007 7:05 PM
To:
[email protected]
Subject: RE: [service-orientated-architecture]
ESB Standard Definition
Expired equine + long stick + vigorous activity
:-)
It may be worthwhile to look at the archives of
this list regarding this
particular subject.
Regards,
- Anil
:-
:- Anil John
:- http://www.aniltj.com/blog/
<http://www.aniltj.com/blog/>
:-
________________________________
From:
[email protected]
<mailto:service-orientated-architecture%40yahoogroups.com>
[mailto:[email protected]
<mailto:service-orientated-architecture%40yahoogroups.com> ] On Behalf
Of
Bill Barr
Sent: Wednesday, March 28, 2007 1:36 PM
To:
[email protected]
<mailto:service-orientated-architecture%40yahoogroups.com>
Subject: RE: [service-orientated-architecture]
ESB Standard
Definition
The problem I have with all of this is that it
just seems like
we're putting the cart before the horse.
But of course! That's what IT does: "Here's a
really cool
solution. Let's go find a problem to solve with
it!" :)
The definition of what an ESB does will be
ever-changing, just
as the definition of what an application server
does has been
ever-changing. It's a fruitless exercise to try
to nail it down.
I disagree. There are lots of smart people
reading, why not
collaborate, come up with a definition that we
can agree upon based on
our needs and then tell the vendors what an ESB
is? We can change the
definition as we need it to change.
--
email: [EMAIL PROTECTED]
<mailto:bbarr%40expedia.com>
