Title: RE: [soa-rm] Architectural Scope of Reference Model
+1
I believe a communications specification
(or however we term it) is key. When implemented, this may be a MOM
capability/product (for example).
Kind Regards,
Joseph Chiusano
Booz Allen Hamilton
Visit us online@ http://www.boozallen.com
From: Schuldt, Ron L
[mailto:]
Sent: Wed 3/30/2005 10:19
AM
To: Duane Nickull; Thomas Erl
Cc:
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:]
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
***********
