[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!"
As long as it is optional, and complete opacity is also supported. I can see good reasons why I would not want to expose services that I aggregate and other instances where I would want to give consumers the option to choose among possible services which I could aggregate on their behalf. Ciao, Rex At 1:41 PM -0400 5/25/05, <McGregor.Wesley@tbs-sct.gc.ca> wrote: >A service will declare, define and describe its (level of) opacity >via its policy. > >I think the definition of opacity is now including the ability of a >service to be combined with others which to me is not opacity. > >Perhaps a new metadata tag such as "aggregation" is more appropriate? > >Wes > > -----Original Message----- >From: Rex Brooks [mailto:rexb@starbourne.com] >Sent: May 25, 2005 1:36 PM >To: Christopher Bashioum; soa-rm@lists.oasis-open.org >Subject: RE: [soa-rm] David Linthicum Says: "ESB versus Fabric.Stop It!" > >I think we need to make opacity optional simply to allow repurposing >where there may be more than one possible set of application/prior >services that can be aggregated in a way more easily consumed by a >given consumer/repurposer. > >Ciao, >Rex > >At 9:39 AM -0400 5/25/05, Christopher Bashioum wrote: >> Joe, >> >>I'm beginning to think that the question you are asking (and have been >>asking ; ) carries something more subtle that I don't believe we have >>addressed yet. It is the idea of intent. I have been of the impression >>that the intent of SOA is service opacity and location opacity (i.e., you >>can't see behind the interface (allows for replacement of parts) and you >>can't see where the service is on the network (implies discovery mechanism). >>But - when it comes to the actual services, the intent there is to create >>the interface in such a way as to allow for re-purposing. In other words, >>as I create a service, I include as an implied requirement that it will be >>used by consumers I don't know in a way that I can't foresee. >> >>It is this idea of intent that I think we are having a hard time capturing >>in the RM. I think your concern about multiple services is another way of >>saying the same thing. The problem with the number of services is it really >>may not capture the intent. For example, if I have 4 services - is that >>really sufficient for an SOA? I'm not sure. However, if I have at least >>the infrastructure services that enable an SOA (yet to be defined, but >>conceptually referred to as an ESB, or discovery, messaging, and mediation - >>whatever) do I have an SOA? Or yet again, if I have the infrastructure and >>one non-infrastructure service, do I then have an SOA? >> >>Intuitively, I think that if I have some minimal level of infrastructure >>(messaging, discovery, and mediation) and I expose one single >>non-infrastructure service on this infrastructure, I have an SOA. >> >>-----Original Message----- >>From: Chiusano Joseph [mailto:chiusano_joseph@bah.com] >>Sent: Wednesday, May 25, 2005 9:13 AM >>To: soa-rm@lists.oasis-open.org >>Subject: RE: [soa-rm] David Linthicum Says: "ESB versus Fabric.Stop It!" >> >>> -----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 -- 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]