[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [soa-rm] David Linthicum Says: "ESB versus Fabric.Stop It!"
> -----Original Message----- > From: Duane Nickull [mailto:dnickull@adobe.com] > Sent: Wednesday, May 25, 2005 2:29 PM > Cc: soa-rm@lists.oasis-open.org > Subject: Re: [soa-rm] David Linthicum Says: "ESB versus > Fabric.Stop It!" > > The question that Rebekah asked that is tough and we need to > answer is "What is the opposite of Services". On other > words, if it is not service oriented, what is it. This is a > tough question and our RM must address a level of clarity > that we can point at something that is not SOA as well as > something that is. > > I would like to hear opinions on this. Duplication of services instead of sharing services: Not SOA. Kind Regards, Joseph Chiusano Booz Allen Hamilton Visit us online@ http://www.boozallen.com > Duane > > Rex Brooks wrote: > > > Having finally now gone through the whole of draft 7 other than the > > supporting materials, and having gone through all the > threads, these > > sorts of conclusions finally start to be distilled out of > it. But, it > > takes all of the discussion so far, and will take much more > I am sure. > > I like Rebekah's last diagram the most of those so far, but it will > > still take some more work to reach the ultimate draft for the first > > version. > > > > Ciao, > > Rex > > > > At 1:30 PM -0400 5/25/05, Chiusano Joseph wrote: > > > >> > -----Original Message----- > >> > >>> From: Rex Brooks [mailto:rexb@starbourne.com] > >>> Sent: Wednesday, May 25, 2005 1:27 PM > >>> To: Chiusano Joseph; soa-rm@lists.oasis-open.org > >>> Subject: RE: [soa-rm] David Linthicum Says: "ESB versus > >>> Fabric.Stop It!" > >>> > >>> I think a single service and a single service consumer for that > >>> service comprise the definition of an atomic SOA. > >>> Multiple services in a void of service consumers don't make an > >>> SOA, only the potential for an SOA. We reflect that in current > >>> thinking in our modeling in the draft 7 of the RM. > >>> Figures 2 and 2.1, even though 2.1 precedes 2, and 2 shows > >>> multiple services behind Service A. It might be wise for > us to have > >>> another diagram and arrange it so that the series runs: > >>> 2.0 Components of a Service, 2.1 Components of a SOA, and 2.2 > >>> Service Aggregation. > >> > >> > >> I like that idea very much. > >> > >> Joe > >> > >> Joseph Chiusano > >> Booz Allen Hamilton > >> Visit us online@ http://www.boozallen.com > >> > >>> Ciao, > >>> Rex > >>> > >>> At 9:13 AM -0400 5/25/05, Chiusano Joseph wrote: > >>> > > -----Original Message----- > >>> >> From: Duane Nickull [mailto:dnickull@adobe.com] >> Sent: > >>> Tuesday, May 24, 2005 2:56 PM >> To: Michael Stiefel >> Cc: > >>> soa-rm@lists.oasis-open.org >> Subject: Re: [soa-rm] David > >>> Linthicum Says: "ESB versus Fabric.Stop >> It!" > >>> >> > >>> >> Endpoints are part of a service description IMO. > >>> >> Orchestration of multiple services is out of the scope of > >>> the core > >>> >> RM, much the same way as how multiple houses are positioned > >>> next to >> each other in a grid layout is un-necessary > in order to > >>> define a RM >> for house. > >>> >> > >>> >> A service or house do not have to exist amongst multiple > >>> houses in >> order to be services/houses. > >>> > > >>> >Which brings us back to what I believe is the single most > >>> important >question for us to answer: Does one service > constitute a > >>> SOA? Or are 2 >or more services required? > >>> > > >>> >If 2 or more services are required, then it seems to me > that in > >>> order >to call something a *SOA* reference model, the notion of > >>> multiple >services must be incorporated - as that is the minimal > >>> amount of >information necessary to *effectively* > represent/model > >>> the "targeted >entity" (which is SOA) for the intended audience. > >>> > > >>> >If one service constitutes a SOA, this implies that a SOA may > >>> have more >than one service. It then seems to me that one has a > >>> choice for their > >>> >RM: include only a single service in the model, or include > >>> multiple >services. The question then becomes which approach > >>> enables the most >effective representation for the > intended audience. > >>> > > >>> >So as you see, I believe everything flows from this > single most > >>> >important question. > >>> > > >>> >Joe > >>> > > >>> >Joseph Chiusano > >>> >Booz Allen Hamilton > >>> >Visit us online@ http://www.boozallen.com > >> Duane > >> >> > >>> Michael Stiefel wrote: > >>> >> > >>> >> > Could we then conceive of endpoints and orchestration in > >>> such a > >> fashion? Or is the critical point aspect or > attribute > >>> in which case >> > endpoint qualifies, but > orchestration does not. > >>> >> > > >>> >> > To make a grammatical analogy, the RM defines a > substantive, > >>> and >> > therefore adjectives (aspects and > >>> attributes) are part > >>> of the RM, > >>> >> but > verbs (actions) are not. > >>> >> > > >>> >> > (side note: I know verbs have aspect, but we are not using > >>> the > >> > >> > >> term > that way). > >> > >>> >> > > >>> >> > Michael > >>> >> > > >>> >> > At 02:34 PM 5/24/2005, Duane Nickull wrote: > >> > >> > >> > > >> > >>> >> >> Since Structural Integrity is an aspect of all > houses, it > >>> could >> be >> part of a RM as an abstract concept. > Even if you > >>> do not >> explicitly >> design a house to have a certain set of > >>> structural >> integrity >> parameters, it still does. > It is not a > >>> component >> itself, just an >> aspect or attribute. > >>> >> >> > >>> >> >> Duane > >>> >> >> > >>> >> >> > >>> >> >> Michael Stiefel wrote: > >>> >> >> > >>> >> >>> I thought of structural integrity in terms of > the entire > >>> house, >> not >>> just a wall, but I think your point > remains the > >>> same. > >>> >> >>> > >>> >> >>> Granted that each architecture needs to specify its > >>> structural >> >>> integrity, but shouldn't the RM have > the concept > >>> of structural >> >>> integrity since it is an abstract concept > >>> shared by all RAs. > >>> >> >>> > >>> >> >>> Michael > >>> >> >>> > >>> >> >>> At 02:06 PM 5/24/2005, Duane Nickull wrote: > >>> >> >>> > >>> >> >>>> The RM does not necessarily have to get into > cardinality > >>> rules >> IMO, >>>> unless they are very obvious. In > the case of a > >>> house, >> you may not >>>> make consistent rules stating that > >>> every house has >> to have at least >>>> three walls since a > >>> wall can be curved or any >> number of > > walls from > >> >>>> > >>> 3 up. You may be able to infer from the relationships > > that > >>> there >> >>>> is a certain cardinality if the RM for a > house said > >>> that each >> room >>>> has one door. > >>> >> >>>> That would declare an association between the > number of > >>> rooms >> to >>>> the number of doors. > >>> >> >>>> > >>> >> >>>> Structural integrity is an aspect of a wall, > which must be > >>> >> >>>> specialized for each architecture based on a number > >>> criteria. >> The >>>> RM declares what the wall is and its' > >>> purpose, the > >>> >> architect has >>>> the job of specifying the actual > walls to > >>> be used >> for each >>>> architecture and ensuring they > map back > >>> to >> requirements. > >>> >> >>>> > >>> >> >>>> You are right - analogies are not definitions, > however I > >>> have >> found >>>> them very useful in conveying the meaning. > >>> >> >>>> > >>> >> >>>> Duane > >>> >> >>>> > >>> >> >>>> Michael Stiefel wrote: > >>> >> >>>> > >>> >> >>>>> Does the RM understand that some of the concepts are > >>> unique >> and >>>>> some multiple (without an exact > number, you > >>> could have one >> >>>>> circular wall, 3 walls, 4 walls, etc.)? > >>> >> >>>>> > >>> >> >>>>> Using your analogy, how does the RM deal with > concepts > >>> such as >> >>>>> structural integrity. Structural > integrity would > >>> apply to all >> >>>>> house RAs. In my way of thinking concepts > >>> such as endpoints or >> >>>>> orchestration are > analogous to this. > >>> >> >>>>> > >>> >> >>>>> In the analogy I would see the reference > architecture as > >>> >> Colonial >>>>> American Reference Architecture, or > even more >> > >>> specifically >>>>> Colonial American Cape Ann, or Colonial > >>> American >> Greek Revival >>>>> reference architectures. > >>> >> >>>>> > >>> >> >>>>> Analogies are useful, but they are not definitions. > >>> >> >>>>> > >>> >> >>>>> Michael > >>> >> >>>>> > >>> >> >>>>> At 12:56 PM 5/24/2005, Duane Nickull wrote: > >>> >> >>>>> > >>> >> >>>>>> RA means Reference Architecture. As per the > previous > >>> emails >> on >>>>>> this subject, it is a generalized > >>> architecture. > >>> >> >>>>>> > >>> >> >>>>>> The relationship is that architects use a RM as a > >>> guiding >> model >>>>>> when building a RA. > >>> >> >>>>>> > >>> >> >>>>>> For example, if you are architecting a house, > an RM may > >>> >> explain >>>>>> the concepts of gravity, a 3D > environment, walls, > >>> >> foundations, >>>>>> floors, roofs, ceilings etc. It > is abstract > >>> >> however. > >>> >> There is > >>> >> >>>>>> nothing specific like a wall with > measurements such as > >>> 8 feet >> >>>>>> high. Note that the RM has only one > each of these > >>> things - it >> >>>>>> does not have 4, 16, 23 walls, > just one as a > >>> concept. > >>> >> >>>>>> The architect may uses this model to create a > specific > >>> >> >>>>>> architecture for a specific house (accounting for > >> > >> > such things > >> > >>> >> as >>>>>> property, incline, climate etc) or an > architect MAY > >>> elect >> to use >>>>>> it to build a more generalized reference > >> > >> > architecture. > >> > >>> >> The >>>>>> latter is often done by architects who > design houses. > >>> >> When they > >>> >> >>>>>> sell a house, they must often re-architect > the RA for > >>> >> specific >>>>>> implementation details such as > incline of land, > >>> >> climate, facing >>>>>> the sun etc.. > >>> >> >>>>>> > >>> >> >>>>>> So why do we need a RM? Simple - we now have > logical > >>> >> divisions >>>>>> amongst the components of a house > and what they > >>> >> mean. > >>> >> That way, > >>> >> >>>>>> when a company says " we are a flooring company..", > >>> that is >> >>>>>> meaningful since we all know what that means. > >>> The same >> applies >>>>>> to a roofing company. Without the > >>> basic consensus on >> the logical >>>>>> divisions, a roofing > >>> contractor may also try to >> include the >>>>>> ceiling and > >>> walls as part of his offerings. > >>> >> >>>>>> That would not work and not allow the general > >>> contractor to >> build >>>>>> a house very easily since > there may > >>> not be consensus >> upon the >>>>>> division of labor and > >>> components to build the house. > >>> >> >>>>>> > >>> >> >>>>>> Do you guys think an explanation of this > nature may be > >>> good >> to >>>>>> include in the introduction section? > >>> >> >>>>>> > >>> >> >>>>>> Duane > >>> >> >>>>>> > >>> >> >>>>>> Chiusano Joseph wrote: > >>> >> >>>>>> > >>> >> >>>>>>> What is an RA? What is the relationship > between an RM > >>> and >> an RA? > >>> >> >>>>>>> What is > >>> >> >>>>>>> the RM->RA path for SOA? > >>> >> >>>>>>> > >>> >> >>>>>>> Matt also submitted last week (I believe) > that we may > >>> not >> even >>>>>>> need an RA. How should that change > our notion > >>> of RM, > > if at all? > >>> > > >>>>>>> > >>> >> >>>>>>> Joe > >>> >> >>>>>>> > >>> >> >>>>>>> Joseph Chiusano > >>> >> >>>>>>> Booz Allen Hamilton > >>> >> >>>>>>> Visit us online@ http://www.boozallen.com >>>>>>> > >>> >>> > >> > > >>> >> > >>> > >>> > >>> -- > >>> 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]