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

 


Help: OASIS Mailing Lists Help | MarkMail Help

soa-rm message

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


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


> However, is any SOA possible if there are no communications? 

Agree with Ron - to apply Duane's car analogy in a different way here: A
car does not have be driven on a road in order to be considered a car, 

*but*

A car does have to have the necessary components to *enable* it to be
driven on a road (we know what those are - no need to list).

Kind Regards,
Joseph Chiusano
Booz Allen Hamilton
Visit us online@ http://www.boozallen.com
 

> -----Original Message-----
> From: Schuldt, Ron L [mailto:ron.l.schuldt@lmco.com] 
> Sent: Wednesday, March 30, 2005 10:19 AM
> To: Duane Nickull; Thomas Erl
> Cc: soa-rm@lists.oasis-open.org
> Subject: RE: [soa-rm] Architectural Scope of Reference Model
> 
> Team,
> 
> I agree in principle with Thomas and Duane. For the reference 
> model, I agree that we should not be defining messages. 
> Message design is clearly an implementation architecture artifact. 
> 
> However, is any SOA possible if there are no communications? 
> I can't think of any example and I'm not saying one doesn't 
> exist. If no example exists, then don't we need a 
> communications element in the reference model? If so, then 
> there would be a need for an artifact called a communications 
> specification - although the reference model would not define 
> the content of a communications specification.
> 
> Ron
> 
> 
> -----Original Message-----
> From: Duane Nickull [mailto:dnickull@adobe.com]
> Sent: Wednesday, March 30, 2005 7:45 AM
> To: Thomas Erl
> Cc: soa-rm@lists.oasis-open.org
> Subject: Re: [soa-rm] Architectural Scope of Reference Model
> 
> 
> 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
> ***********
> 
> 


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