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

The binding mechanism is transport related and IMHO would not completely
specify the communication mechanisms need for SOA-RM. We would still need to
have some "Hello Packets or Ping" type specification which allows us to
answer the question "Is that service SOA?"



-----Original Message-----
From: Duane Nickull [mailto:dnickull@adobe.com] 
Sent: Wednesday, March 30, 2005 4:21 PM
To: Schuldt, Ron L
Cc: Thomas Erl; soa-rm@lists.oasis-open.org
Subject: Re: [soa-rm] Architectural Scope of Reference Model


I will attempt to answer your question.  If designing a service oriented 
architecture for an infratructure, yes - probably none would exist 
without messaging or messages.  If you use SOA principles to design a 
single component (for example - some sort of specialized services 
server), it, by itself, may not have any "messages" or mesage generation 
software, only a component of the service that recevies messages from 
other components (which I have been calling a "binding mechanism").  So 
if one were to ask the question " is that services server SOA?", the 
answer would be yes if it had all the elements (which we have not yet 
defined) of SOA.

I hope this makes some sense?


Schuldt, Ron L wrote:

>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.
>-----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
>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 
>1. Please look at the OSI Reference model.  This is a communication 
>stack yet it does not contain messages:
>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":
>3. RCS Reference Model
>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.   

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  -

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