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.
From: Ken Laskey [mailto:]
Sent: Sunday, April 10, 2005 4:29 PM
To: Hamid Ben
Malek
Cc: Smith, Martin;
Subject: Re: [soa-rm] Architectural
Scope of Reference Model
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.
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
***********
------------------------------------------------------------------------------------------
Ken
Laskey
MITRE Corporation, M/S H305 phone: 703-883-7934
7515 Colshire
Drive fax: 703-883-1379
McLean VA 22102-7508
