Re: [soa-rm] FYI: BEA SOA Reference Diagram

[Duane Nickull <dnickull@adobe.com>]

Michael:

Concur.  I think we all agree that a reference architecture (or two) is 
a logical next step.

For the RM however, if I have only one service, is it not SOA yet if I 
have two of them it is SOA?  That is the key question we have to answer 
for the RM.

Perhaps a way to facilitate the usefulness of the RM is to illustrate 
this concept as part of appendix B.

Duane

Christopher Bashioum wrote:

> Well said - I agree
>
>-----Original Message-----
>From: Michael Stiefel [mailto:development@reliablesoftware.com] 
>Sent: Wednesday, May 18, 2005 3:02 PM
>To: soa-rm@lists.oasis-open.org
>Subject: Re: [soa-rm] FYI: BEA SOA Reference Diagram
>
>I agree that " The essence of a SOA is multiple services coming together to 
>satisfy a set of needs."
>
>I believe that to be useful to our audience we need to discuss how multiple 
>services work together. Even if there is just one service, that service has 
>to be designed in a certain way if it is to potentially participate in a 
>SOA.  Another way of looking at it is that one service is just the 
>degenerate case.
>
>It seems to me what we are working on right now is a Service Orientation 
>Reference Model which is the necessary first step. You can call the next 
>step a SOA Reference Model, or a SOA Reference Architecture, but without 
>that next step I do not think we will produce something that will be of 
>lasting value to the larger community.
>
>I do not see how discussing how services can be connected together is any 
>more concrete that discussing the nature of a single service. Abstraction 
>is always relative to the level of discourse.
>
>Take  the ISO stack as an example, the idea of connection is implicit in 
>the abstraction. The whole point is to describe how two layers in the stack 
>in different processes in different systems can communicate without having 
>to understand the lower level protocols. The reason the communication is 
>not shown (although I have seen pictures of it with the communications 
>shown as in Tannenbaum's Computer Networks) is because the abstraction 
>being shown is how the protocols are organized in one of the processes. If 
>that is the level of discourse, there is no need to show a connection.
>
>Incidentally,  I too do not like the use of the word architecture in the 
>term SOA. Maybe we should propose what the SOAP 1.2 specification did and 
>make the acronym the name.
>
>Michael
>
>
>At 02:06 PM 5/18/2005, Duane Nickull wrote:
>
>
>  
>
>>Ken Laskey wrote:
>>
>>    
>>
>>>The essence of a SOA is multiple services coming together to satisfy a 
>>>set of needs.
>>>      
>>>
>>This is the core point we have not reached consensus on yet.  This is a 
>>well worded as can be so I would like to use this assertion as a basis for 
>>the discussion.
>>
>>Thoughts:
>>
>>I would agree that "The essence of a SOA infrastructure is multiple 
>>services coming together to satisfy a set of needs.  I do have 
>>reservations about the concept of multiplicity of services being used as a 
>>key metric to define SOA.
>>
>>Questions:
>>1. Is it necessary that there be more than one service in order that SOA 
>>be SOA? 2. If yes to #1, is it necessary to call services only in sequence?
>>
>>My gut feeling is that having multiple services is probably a given for 
>>any specific implementation of SOA, however it is not a requirements for 
>>something to be service oriented.  If I architect one application and 
>>build it with a single service, service description, policy set, (+ 
>>whateverElseGetsInTheReferenceModel), is that service oriented 
>>architecture?  I think yes.
>>
>>I would fully support a reference architecture depicting multiple 
>>services  being used either sequentially or in parallel, however think 
>>that is a sub project best left for a dedicated sub committee.
>>
>>Duane
>>
>>    
>>
>
>
>
>
>
>  
>