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

[Duane Nickull <dnickull@adobe.com>]

Hamid:

Well said. We must stay in the abstract.

Duane

Hamid Ben Malek wrote:

> Hi all,
>
> I have not been following the discussion on this mailing list as I 
> have not read all the messages yet (or should I say I have read only 
> two or three emails). But it just happened that I have read this one, 
> and I felt compelled to give my input to it. What Duane is calling 
> “binding mechanism” (namely the component(s) responsible for 
> receiving/sending and handling of messages) is actually part of a 
> system called “Enterprise Service Bus”. SOA Reference Model should try 
> to define the general principles of an ESB in a way that is 
> independent of any specific implementation of the ESB. The question 
> whether a given service by itself is an SOA service, does not make lot 
> of sense. Any service could become an SOA service if it is hooked up 
> to an ESB. The real questions are how to define an ESB in an abstract 
> way, and how to define the adapters that can hook up a given service 
> to an ESB? The best analogy would be to compare the ESB to the 
> internet, a service to a computer, and the adapters to the network 
> cable and its accessories that allow a given computer to hookup to the 
> internet (to get connected). In regards to the feasibility of defining 
> a “ping” specification to SOA-test a service, I think that is 
> possible, but it will be defined within the specification of an ESB.
>
> Hamid.
>
> -----Original Message-----
> From: Vikas Deolaliker [mailto:vikas@sonoasystems.com]
> Sent: Monday, April 04, 2005 11:27 AM
> To: 'Duane Nickull'; 'Schuldt, Ron L'
> Cc: 'Thomas Erl'; soa-rm@lists.oasis-open.org
> 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?"
>
> Vikas
>
> -----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
>
> Ron:
>
> 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?
>
> Duane
>
> Schuldt, Ron L wrote:
>
>>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
>
> ***********
>

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