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

[Matthew MacKenzie <mattm@adobe.com>]

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 <mailto:scott@justiceintegration.com>
> http://www.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
> > ***********
> >
>