I like "whatever". Some other possibilities are
"thingamajigget" and "whatchamacallit". I also like the concept of a
community. I don't remember any of the discussion threads mentioning that
idea, but it sounds like it may be abstract enough.
So, who is going to write up the glossary of
concepts? I want to give it a shot, but I have to get some paying work
done first. I have saved most of the emails from the TC, but going through
them for the concepts will probably take a few hours. Does anyone have a
list of the concepts handy? If so, I can collect them into a spreadsheet
or document and post it to the site.
From: Ken Laskey [mailto:]
Sent: Monday, April 11, 2005 11:40 AM
To: Chiusano
Joseph; Christopher Bashioum; Hamid Ben Malek
Cc: Smith, Martin;
Subject: RE: [soa-rm] Architectural
Scope of Reference Model
Chris and Joe,
You are both nicely pointing out capabilities
of the "whatever" through which a given service hooks into the
community. Pick a name and let's keep adding to its description until we
agree on what this black box does.
Ken
At 11:26 AM 4/11/2005,
Chiusano Joseph wrote:
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,<?xml:namespace
prefix = o ns = "urn:schemas-microsoft-com:office:office"
/>
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 its 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.
Im 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, its 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
--
---------------------------------------------------------------------------------
/ Ken
Laskey
\
| MITRE Corporation, M/S H305
phone: 703-883-7934 |
| 7515
Colshire
Drive
fax: 703-883-1379 |
\ McLean VA
22102-7508
/
----------------------------------------------------------------------------------
