Re: [soa-rm] Architectural Scope of Reference Model

["Scott Came" <scott@justiceintegration.com>]

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
>> > ***********
>> >
>>
>