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

[Rex Brooks <rexb@starbourne.com>]

Didn't mean that there was no value in what we call SOA, just that it 
causes me some semantic difficulties and leads to confusion over what 
constitutes an Architecture with a capital A. Like Art with a capital 
A.

Perhaps we need to develop another term term such as 
sub-architecture, for any set of architectural components short of 
the superset EA? Unfortunately, like philosophy, any enterprise has 
an EA whether it is conscious and deliberate or result of ad hoc 
increments. Same with Knowledge Base. It starts becoming a problem 
for first order logic in terms of what we mean when we that term.

Ciao,
Rex

At 11:19 PM -0400 5/18/05, Chiusano Joseph wrote:
>  > -----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
>>


-- 
Rex Brooks
President, CEO
Starbourne Communications Design
GeoAddress: 1361-A Addison
Berkeley, CA 94702
Tel: 510-849-2309