Here's what I consider to be a good ESB article (Oct
2004) by Fred Cummins of EDS:
http://www.intelligenteai.com/showArticle.jhtml;jsessionid=USLY1TIFBS4IAQSNDBCCKHSCJUMEKJVN?articleID=49400918
Title: "In Pursuit
of Agility"
Publication:
Intelligent Enterprise
Kind Regards,
Joseph Chiusano
Booz Allen Hamilton
Visit us online@ http://www.boozallen.com
From: Hamid Ben Malek
[mailto:]
Sent: Monday, April 04, 2005 7:03
PM
To: Smith, Martin
Cc:
Subject: RE: [soa-rm] Architectural
Scope of Reference Model
[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.
Hamid.
From: Smith,
Martin [mailto:]
Sent: Monday, April 04, 2005 2:44
PM
To: Hamid Ben
Malek
Cc:
Subject: RE: [soa-rm] Architectural Scope
of Reference Model
Hamid -
-
OK, this brings me
out of my cave . . .
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.
Whew - - I feel
better.
Martin
-----Original
Message-----
From: Hamid Ben
Malek [mailto:]
Sent: Monday, April 04, 2005 2:58
PM
To:
; 'Duane Nickull'; 'Schuldt, Ron L'
Cc: 'Thomas Erl';
Subject: RE: [soa-rm] Architectural Scope
of Reference Model
Hi all,
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.
Hamid.
-----Original Message-----
From: Vikas
Deolaliker [mailto:]
Sent: Monday, April 04, 2005
11:27 AM
To: 'Duane Nickull'; 'Schuldt, Ron L'
Cc: 'Thomas Erl';
Subject: RE: [soa-rm] Architectural Scope of
Reference Model
The binding mechanism is transport
related and IMHO would not completely
specify the communication mechanisms need
for SOA-RM. We would still need to
have some "Hello Packets or Ping" type
specification which allows us to
answer the question "Is that service
SOA?"
Vikas
-----Original
Message-----
From: Duane Nickull
[mailto:]
Sent: Wednesday, March 30, 2005 4:21
PM
To: Schuldt, Ron
L
Cc: Thomas Erl;
Subject: Re: [soa-rm] Architectural Scope
of Reference Model
Ron:
I will attempt to answer your
question. If designing a service oriented
architecture for an infratructure, yes -
probably none would exist
without messaging or messages. If
you use SOA principles to design a
single component (for example - some sort
of specialized services
server), it, by itself, may not have any
"messages" or mesage generation
software, only a component of the service
that recevies messages from
other components (which I have been
calling a "binding mechanism"). So
if one were to ask the question " is that
services server SOA?", the
answer would be yes if it had all the
elements (which we have not yet
defined) of
SOA.
I hope this makes some
sense?
Duane
Schuldt, Ron L
wrote:
>Team,
>
>I agree in principle with Thomas and
Duane. For the reference model, I
agree that we should not be defining
messages. Message design is clearly an
implementation architecture artifact.
>
>However, is any SOA possible if there
are no communications? I can't think
of any example and I'm not saying one
doesn't exist. If no example exists,
then don't we need a communications
element in the reference model? If so,
then there would be a need for an
artifact called a communications
specification - although the reference
model would not define the content of
a communications
specification.
>
>Ron
>
>
>-----Original
Message-----
>From: Duane Nickull
[mailto:]
>Sent: Wednesday, March 30, 2005 7:45
AM
>To: Thomas
Erl
>Cc:
>Subject: Re: [soa-rm] Architectural
Scope of Reference Model
>
>
>Thomas:
>
>Thank you for this very elegant
summary!
>
>I think the answer may be in the
definition of a "reference model" vs.
>"architecture". I think case
studies will help clear up this
>confusion. A reference model
will normally not contain "messages" as a
>component.
>
>1. Please look at the OSI Reference
model. This is a communication
>stack yet it does not contain
messages:
>http://www.scit.wlv.ac.uk/~jphb/comms/std.7layer.html
>
>This does not contain any "message"
although messages will occur in
>implementations using the reference
model
>
>2. The ITA Reference Model likewise
does not have "messages":
>http://www.ewita.com/earlywork/itarefr.htm
>
>3. RCS Reference
Model
>http://www.isd.mel.nist.gov/documents/messina/euro_cast.pdf
>
>Again - no messages even though there
is an element marked
>"Communications" in figure one.
>
>The reference Model should not
contain "messages" as a component. That
>belongs in architecture or
implementations based on the reference
>model. I have never encountered
one reference model with concrete terms
>in it. If it had such, it would
not be abstract.
>
>We must think abstract, not
concrete.
>
>Duane
Nickull
>
>
>
>
>
>Thomas Erl
wrote:
>
>
>
>>Some thoughts regarding the
on-going discussion of whether a message
>>element should be part of our
reference model:
>>
>>As per our chosen definition of
architecture, in order to describe
>>service-oriented architecture we
need to:
>>1. Define elements that comprise
the structure of a system.
>>2. Define external properties of
these elements.
>>3. Define relationships between
these elements.
>>4. Define the overall structure
of the system.
>>(not necessarily in this
order)
>>
>>Starting with the first point,
different element collections have been
>>proposed in the two position
papers submitted so far. As has been
>>discussed, the MacKenzie/Nickull
paper does not identify a message
>>element, whereas Kohring's
does.
>>
>>A related difference I noticed
when reviewing these papers is that
>>Kohring's establishes a broader
range of SOA elements. Specifically,
>>both service provider and
requestor (consumer) roles are separately
>>identified and described. As
mentioned in item #3 above, we are
>>required to define the
relationship between the elements we define.
>>Therefore, it makes sense that
this paper includes a separate element
>>(message) that can be used to
help describe the relationship between a
>>service and its
requestor.
>>
>>The elements identified in the
MacKenzie/Nickull paper are:
>>-
Service
>>- Service
Description
>>- A form of advertisement to
facilitate discoverability.
>>- Service
Contract
>>- Data
Model
>>These elements form a narrower
architectural scope, leading to a
>>proposed architecture that
revolves primarily around the service (or a
>>service assuming the provider
role). Because a service requestor is
>>not explicitly identified as a
separate element, it makes sense that
>>an element representing some unit
of communication (message or
>>otherwise) is also not
identified. Within this model's scope, the
>>definition of a relationship
between a service and its requestor
>>(beyond details implied by
description, contract, data model, and
>>advertisement elements) is not a
requirement.
>>
>>I believe that in order to
address the issue of whether a message is a
>>legitimate element within the
reference model, we should begin
>>by clearly defining the scope of
our abstract architecture. Given that
>>we are establishing core elements
that are expected to be present in
>>all forms of SOA, this raises the
question: Does an architecture
>>require the presence of both a
service provider and a service
>>requestor (the coffee shop and
the patron) in order to be classified
>>"service-oriented"? If yes, we
must define this relationship. To
>>properly do so, we very well may
need to further identify and define a
>>separate element to represent an
abstract unit of communication passed
>>between them.
>>
>>Thomas
>>
>>
>>
>>
>
>
>
>
--
***********
Senior Standards Strategist - Adobe
Systems, Inc. - http://www.adobe.com
Vice Chair - UN/CEFACT Bureau Plenary -
http://www.unece.org/cefact/
Adobe Enterprise Developer Resources
-
http://www.adobe.com/enterprise/developer/main.html
***********
