Agreed
From: Chiusano Joseph
[mailto:]
Sent: Monday, April 11, 2005 11:27
AM
To: Christopher Bashioum; Ken Laskey; Hamid Ben
Malek
Cc: Smith, Martin;
Subject: RE: [soa-rm] Architectural
Scope of Reference Model
Since such a component does
not have to even be a bus configuration (there are other possible
configurations, such as a star), I think "infrastructure communications
component" (or similar) may be more abstract than using the term
"bus".
Joe
Kind Regards,
Joseph Chiusano
Booz Allen
Hamilton
Visit
us online@ http://www.boozallen.com
From: Christopher Bashioum
[mailto:]
Sent: Mon 4/11/2005 11:14
AM
To: 'Ken Laskey'; 'Hamid Ben Malek'
Cc: 'Smith,
Martin';
Subject: RE: [soa-rm]
Architectural Scope of Reference Model
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
