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

["Chiusano Joseph" <chiusano_joseph@bah.com>]

<Quote>
It seems to me what we are working on right now is a Service Orientation
Reference Model which is the necessary first step.
</Quote>

+++++++++++1 :)

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

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