[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!"
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]