<Quote>
I suspect when we get to specifying what gives a service
unique identity,
</Quote>
Will we ever reach
that point? That is, is the question of whether or not a service has a unique
identity within the scope of a RM? My take is no - it's a design issue, and
potentially an architecture issue depending on how such a unique identity needs
to be generated/maintained (i.e. may have an "identity engine" component in an
architecture - not to be confused with identity management for
security).
Kind Regards,
Joseph Chiusano
Booz Allen Hamilton
Visit us online@ http://www.boozallen.com
From: Scott Came
[mailto:]
Sent: Wednesday, March 30,
2005 12:44 PM
To:
Subject: Re:
[soa-rm] Architectural Scope of Reference Model
Hello everyone, I've been lurking so far, but let me jump in on
this one...
Thomas' key question, as I read his post, was not whether
messages should be part of the RM, but whether service requestors should
be.
In my view, having services without service requestors doesn't make
a lot of sense. So I would like to suggest that service requestors are a
proper element in the RM.
If you grant that, then the relationship
between a service requestor and a service implies the exchange of some
information (in the general case). We might not call that a "message", but it
does exist. Is there another, more appropriately abstract, name for the
elements of the service's interface that specify the structure of information
exchange that occurs between requestor and service?
Looking at it
another way (and forgive me if this is getting ahead of where we should
be)...I suspect when we get to specifying what gives a service unique
identity, it may well be a (perhaps qualified) name plus a set of interface
elements (operations/behaviors, if you will, and the "signature" of those
operations). If so, then we'll need a name for the elements that represent the
input and output parameters (again, forgive the "concrete" terminology) of
each operation.
Regards...
--Scott
Scott Came
President
and Principal Consultant
Justice Integration Solutions, Inc.
Olympia,
Washington
http://www.justiceintegration.com
>
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
>
***********
>
