If by "Bus" we are referring to some sort of service
connection, be it messaging per se, or pre-arranged BPEL or WSBPEL, or
other formats within the sphere of IT, I am relatively unconcerned,
but if we were to specify a wire signal or wireless protocol as
"THE" Bus, I would object.

Cioa,

Rex

At 11:14 AM -0400 4/11/05, Christopher Bashioum wrote:

Ken,

i don't have any problem staying away from the term
ESB. However, in light of one of your other messages (which
I agree with very much) that we capture the idea and then figure out
what to call that idea later, I would suggest that the idea of some
kind of a communications "bus" is inherent in
an SOA. In other words, services should plug
into something to be a service in an SOA. The bus
defines the boundaries of the SOA. If you are on
the bus, you are "in", if you are not on the bus, you
are "out". This may be crossing into
the concrete too much, but I think the RM should
probably reference something that is an abstract of a
bus.

I would strongly suggest we stay away from the term ESB.
It has become an ill-defined product offering from many vendors and it
is not at all clear what needs to be present in such a component. An
ESB (or some vendor's notion of an ESB) could be an implementation
mechanism but such a conglomeration is show be the output of design,
not the conceptual reference.

Ken

On Apr 4, 2005, at 7:03 PM, Hamid Ben Malek wrote:

[Vikas]: However the point that is lost in this discussion
is the one the original email author made i.e. we need to have an
architectural element which discusses the "communication
infrastructure" in a SOA-RM.

[Hamid] Viaks, I agree with your last sentence above. What you call
"communication infrastructure" in your above sentence, I call it
ESB. Some people misunderstand the term ESB when they look at it
literally: the word "bus" suggests to them many connotations that
does not necessary exist in an ESB. The term ESB should be understood
in an abstract way. It is a technical term that should not be analyzed
through the words that makes it.

Martin,

ESB is not exactly legacy adapter. It is true that most
implementations of an ESB incorporate data transformations and ESBs
are used mostly for EAI. However, this is only the current
implementation of the concept of ESB. Independently of the way an ESB
may be implemented, the fact still remains that there are profound
concepts in the term ESB. Concerning the peer-to-peer topology, that
could be possible with an ESB, but to assume that every transaction or
call is peer-to-peer would be a very restrictive design of what SOA is
about. For example, a client application that is connected to an ESB
should be possible to invoke a service that it does not even know
about. The ESB finds the right service, based on various criteria
(that could also include the fees to pay for invoking such a service),
and the bus (ESB) makes the call on behalf of the application. Or
sometimes, the service invocation itself may involve multiple
invocations among a group of other services, orchestrated by some
important components within the ESB.

What I hear people call an ESB seems to be a "legacy adapter" (EAI
- - protocol and data transform) plus various other functions I would
model as independent components, including BPM, reliable messaging,
and services location.

I think it's essential to separate out the "legacy adapter"
functionality from the rest. And I would prefer to model the
separate functions as separate entities/whatevers in our RM. The
fact that the functions are marketed in various combinations should
not overly influence our analytical decisions.

I'm very concerned that the use of the term ESB suggests that every
transaction in the system (meaning the relevant collection of services
and consumers) passes through the "bus." This seems
very wrong to me.

The unifying element in an SOA environment is the services catalog,
which allows any consumer or service to find and bind to others.
After that, it's peer-to-peer unless "helper" or QOS services
are needed.

I have not been following the discussion on this mailing list as I
have not read all the messages yet (or should I say I have read only
two or three emails). But it just happened that I have read this one,
and I felt compelled to give my input to it. What Duane is calling
"binding mechanism" (namely the component(s) responsible for
receiving/sending and handling of messages) is actually part of a
system called "Enterprise Service Bus". SOA Reference Model should
try to define the general principles of an ESB in a way that is
independent of any specific implementation of the ESB. The question
whether a given service by itself is an SOA service, does not make lot
of sense. Any service could become an SOA service if it is hooked up
to an ESB. The real questions are how to define an ESB in an abstract
way, and how to define the adapters that can hook up a given service
to an ESB? The best analogy would be to compare the ESB to the
internet, a service to a computer, and the adapters to the network
cable and its accessories that allow a given computer to hookup to the
internet (to get connected). In regards to the feasibility of defining
a "ping" specification to SOA-test a service, I think that is
possible, but it will be defined within the specification of an
ESB.