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

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

> -----Original Message-----
> From: Rex Brooks [mailto:rexb@starbourne.com] 
> Sent: Wednesday, May 18, 2005 3:24 PM
> To: Christopher Bashioum; 'SOA-RM'
> Subject: RE: [soa-rm] FYI: BEA SOA Reference Diagram
> 
> In today's meeting, I agreed with several other voices that I 
> am not sure there is an architecture per se in SOA, but 
> rather that most of what are called SOAs are, in fact, 
> service-components of an Enterprise Architecture, which is, 
> IMO, where the actual Architecture is realized.

Respectfully disagree - SOA does not have to be at the enterprise level
to add value, or to even be considered SOA. I also try to remember that
architecture does not always mean EA.

Joe

Joseph Chiusano
Booz Allen Hamilton
Visit us online@ http://www.boozallen.com
  
> However, it is too late to bother arguing that, so we will 
> have to be careful in describing what we mean by an SOA per 
> se. So I have to agree with 1) and I think a service and some 
> other infrastructure entity, be it a remote system or another 
> node in the same system are required to constitute an 
> architecture. I'm not sure about whether we should stipulate 
> satisfaction of needs. It makes good common sense, though. 
> But, I think that in essence there has to be a service and a 
> service consumer for an SOA to exist.
> 
> Regards,
> Rex
> 
> At 2:44 PM -0400 5/18/05, Christopher Bashioum wrote:
> >Two points:
> >
> >1) in our document, we make the assertion that a service is the 
> >fundamental building block of an SOA.  If that is correct (and I 
> >believe it is), then you cannot have an SOA with only 1 
> building block.  
> >The concept of a service being the fundamental building 
> block of an SOA 
> >implies rather strongly that the relationship among multiple 
> services 
> >(and the possible specialization of
> >services) is part and parcel of an SOA.  In other words, there is 
> >something important to how these building blocks get put 
> together that 
> >is inherent in SOA.  Not sure what that is just yet, and 
> maybe we can 
> >show that in a single stack.
> >
> >2) I am not sure about the sufficiency of Ken's statement.  I think 
> >there is something about the orientation applied when building a 
> >service description that gets to the re-purposing.  I.e., building a 
> >service with the stated requirement of re-purposing of that service.
> >
> >Having said #2, I am not sure if that is really an essential 
> property 
> >of SOA, or if it is a quality of a "good" SOA.
> >
> >
> >
> >-----Original Message-----
> >From: Duane Nickull [mailto:dnickull@adobe.com]
> >Sent: Wednesday, May 18, 2005 2:06 PM
> >Cc: SOA-RM
> >Subject: Re: [soa-rm] FYI: BEA SOA Reference Diagram
> >
> >
> >
> >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
> >
> >>
> 
> 
> --
> Rex Brooks
> President, CEO
> Starbourne Communications Design
> GeoAddress: 1361-A Addison
> Berkeley, CA 94702
> Tel: 510-849-2309
>