soa-rm message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [soa-rm] Architectural Scope of Reference Model
- From: "Scott Came" <scott@justiceintegration.com>
- To: soa-rm@lists.oasis-open.org
- Date: Wed, 30 Mar 2005 09:44:00 -0800 (PST)
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
scott@justiceintegration.com
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
> ***********
>
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]