[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [soa-rm] FYI: BEA SOA Reference Diagram
Agreed. If you could drop me a note with the book title, I would appreciate it. Like I need more reading material, right? However, it is probably a good idea to have something more general to counteract the tunnel vision I'm getting from trying to get comfortable with the limits of the ADLs out there. I find myself asking if there isn't anything more recent on that topic than 2002, which is now seeming like a decade ago. What's a modeler to do when there isn't a comfortable modeling language handy, let alone a toolset built therefrom? Let's not answer that one right now. ;-) Rex At 9:16 PM -0400 5/19/05, Chiusano Joseph wrote: > > -----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 >> -- 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]