|
Absolutely - which is why I prefaced that part of my remark with "When
implemented".
:)
Kind Regards,
Joseph Chiusano
Booz Allen Hamilton
Joseph
It seems to me that
MOM (message oriented middleware) would be specific to a particular
implementation. If one considers Bluetooth to be a specific
implementation of a SOA then one might have to concede that MOM would not be
part of the implementation. Irrespective the MOM is to concrete for a
reference model. The reference model should not be concerned with the
specific communication pattern but the pattern of interaction between the
model constructs.
/r
Michael Ruiz
703-668-4243
703-785-9503
From:
Chiusano Joseph [mailto:chiusano_joseph@bah.com]
Sent: Wednesday, March 30, 2005 2:03
PM
To: Schuldt, Ron L; Duane
Nickull; Thomas Erl
Cc:
soa-rm@lists.oasis-open.org
Subject: RE: [soa-rm] Architectural Scope
of Reference Model
I believe a communications
specification (or however we term it) is key. When implemented, this may be a
MOM capability/product (for example).
From:
Schuldt, Ron L [mailto:ron.l.schuldt@lmco.com]
Sent: Wed 3/30/2005 10:19 AM
To: Duane Nickull; Thomas Erl
Cc:
soa-rm@lists.oasis-open.org
Subject: RE: [soa-rm] Architectural Scope
of Reference Model
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:dnickull@adobe.com]
Sent:
Wednesday, March 30, 2005 7:45 AM
To: Thomas Erl
Cc:
soa-rm@lists.oasis-open.org
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
***********
|