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

[Rex Brooks <rexb@starbourne.com>]

I understand better now, Duane,

Thanks for the further reference materials.

One question though: Shouldn't we start from the concrete now in a 
bottom-up approach since  structural elements such as messaging 
protocols and the manifold other concerns recently expressed, exist 
at a very mature stage now? I don't think we are in the position of 
driving research and development for protocols to be constructed out 
of our models. Correct me if I'm wrong, but I think we are in the 
position of needing to take full recognition of the existing 
protocols and abstract our models from these concrete architectural 
elements as they exist now.

Then,  maybe we can look at how we can enable a more advantageous 
approach to combining these manifold technologies together in the 
manner our Reference Model can realistically provide.

Ciao,
Rex

At 6:45 AM -0800 3/30/05, Duane Nickull wrote:
>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
>***********


-- 
Rex Brooks
President, CEO
Starbourne Communications Design
GeoAddress: 1361-A Addison
Berkeley, CA 94702
Tel: 510-849-2309