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

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

> -----Original Message-----
> From: Duane Nickull [mailto:dnickull@adobe.com] 
> Sent: Wednesday, May 18, 2005 7:42 PM
> Cc: soa-rm@lists.oasis-open.org
> Subject: Re: [soa-rm] FYI: BEA SOA Reference Diagram
> 
> 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.

I believe that having one service and a provider/consumer can constitute
a SOA - perhaps one can consider this a "minimal" or "basic" SOA. Having
said that, I believe that another key question we need to answer for the
RM is what will provide the implementers of this specification the most
value - giving them guidance that will help them (eventually) implement
a "minimal" SOA, or one comprised of more than one service? 

Or put another way, will more SOA's in the world be comprised of only a
single service, or multiple services? Given the answer to that question
(whichever it may be, but I have my own hunch;), should we try to reach
the broadest audience possible for our work? Or only the minimal
audience?

Joe

Joseph Chiusano
Booz Allen Hamilton
Visit us online@ http://www.boozallen.com
  
> 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
> >>
> >>    
> >>
> >
> >
> >
> >
> >
> >  
> >
>