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

[john c hardin <john@crossconnections.ws>]

Agreed. I have forwarded the email from Duane to ebSOA members with this opener:

FYI - ebSOA group -

This is an update on the voluminous discussions happening at the SOA-Reference 
Model group level. I felt that this email summarized the overall direction for 
SOA-RM, with references to example work from OSI and others. I am forwarding it 
for the persons not subscribed to SOA-RM. My apologies to those who have seen 
this already.

John

~~~~~~~~~
john c hardin
CIO - crossconnections.ws
313.279.1377 new *VONAGE* number
313.930.5323 cell
mailto:john@crossconnections.ws

"The new electronic interdependence recreates the world in the image of a global 
village."

     Marshall McLuhan, "Gutenberg Galaxy", 1962



Rex Brooks wrote:
> 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
>> ***********
> 
> 
>