OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebsoa message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


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



-------- Original Message --------
Subject: Re: [soa-rm] Architectural Scope of Reference Model
Date: Wed, 30 Mar 2005 06:45:28 -0800
From: Duane Nickull <dnickull@adobe.com>
To: Thomas Erl <terl@serviceorientation.org>
CC: soa-rm@lists.oasis-open.org
References: <955953BEFC7F5C4AA0F1428F3F335F1C9D84BC@ZZX3UG-0100.DHSNET.DS1.DHS> 
<424886FC.3090207@adobe.com> <000f01c53500$0f60ee50$06a25318@guestoo2y3ipzi>

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




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




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]