OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

soa-rm message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


> -----Original Message-----
> From: Rex Brooks [mailto:rexb@starbourne.com] 
> Sent: Thursday, May 19, 2005 8:11 AM
> To: Chiusano Joseph; SOA-RM
> Subject: RE: [soa-rm] FYI: BEA SOA Reference Diagram
> 
> 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? 

Great question Rex. It just so happens that one of the X books I am
reading right now is on EA, specifically an overview of various EA
frameworks (Zachman, DODAF, etc.). The author asserts that there are 3
types of architectures, presented in hierarchical order from the
enterprise level down (copied verbatim below):

(1) Enterprise Architecture (EA): Relates organizational mission, goals,
and objectives to business tasks, activities, and relations, and to the
technology or IT infrastructure required to execute them.

(2) System or Solution Architecture: Relates requirements and the
external world to system/solution structures, including both hardware
and software, so that the effectiveness of a system design concept can
be communicated.

(3) Software Architecture: Relates requirements, fixed system hardware,
and infrastructure (i.e. COTS or GOTS) to software structures in order
to demonstrate software effectiveness.

In addition to your suggestion of sub-architecture, we could also
consider a term such as a "local" architecture (i.e. local being "less
than enterprise").

Joe

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


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]