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: Thu, 31 Mar 2005 15:05:31 -0800 (PST)
I agree that there may be nothing interesting (or sufficiently abstract) to say about consumers at this point.
In a post earlier today, Duane said:
> The data
model is the abstract concept of what data you will pass in and out of a service.
This is really the point
I was after (said much more concisely than I was able to muster), so as long as this abstraction is "in", I
agree.
Thanks all for your patience!
--Scott
> Scott,
>
> A reference
model is about as abstract as we are able to get in this
> field. That said, needing a service requestor
just because there is a
> service to be requested seems like a very concrete statement because
>
requestor implies there is a request, and then that request has to be
> defined. I would merely assume as a
reader that a service would
> obviously have some form of consumer, and in the case of a reference
>
model, discussing the consumer wouldn't serve much purpose.
>
> Request, Message, Call, etc... these
are all no good because they imply
> a physical endpoint. I doubt that requestor or any variation has a
> place in our RM, and if we did need to discuss such a component in the
> document, we would certainly
want to use the word "consumer", since it
> is naive to assume that all services follow the
request/response paradigm.
>
> -matt
>
> Scott Came wrote:
>
>>
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]