[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!"
<Quote> Should the RM have one part that describes concepts that will have an identifiable instantiation and others that are a property, possibly distributed among the parts, of the while? </Quote> Ken, could you perhaps provide an example of what you would mean by this? Joe Joseph Chiusano Booz Allen Hamilton Visit us online@ http://www.boozallen.com > -----Original Message----- > From: Ken Laskey [mailto:klaskey@mitre.org] > Sent: Wednesday, May 25, 2005 9:51 PM > To: SOA-RM > Subject: Re: [soa-rm] David Linthicum Says: "ESB versus > Fabric.Stop It!" > > I expect a single service description is sufficient to define > any infrastructure or non-infrastructure service. I think we > can note some number will likely exist and interact, possibly > stating sometimes a service may provide functionality and > sometimes it may consume the functionality of another service. > > However, there are certain fundamental capabilities (or at > least accounting for concepts) that must exist for anyone to > care to build or > use some nonzero number of services. Frank often brings up > semantics. > I've talked about security (and am still uncomfortable that > this is easily subsumed by policy). This gets back to the > idea of structural integrity because indeed something > analogous to structural integrity may need to be part of our RM. > > Should the RM have one part that describes concepts that will > have an identifiable instantiation and others that are a > property, possibly distributed among the parts, of the while? > > Ken > > On May 25, 2005, at 12:35 PM, Duane Nickull wrote: > > > It would be far to concrete for a reference model to dive into > > infrastructure and services to support it. > > > > Duane > > > > Chiusano Joseph wrote: > > > >> <Quote> > >> 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. > >> </Quote> > >> > >> Which implies that we may want to distinguish between > "infrastructure" > >> and "application" services for our SOA RM (not necessarily > advocating, > >> just pointing out the notion). That is, as long as this > notion is not > >> too concrete for the RM - if so, it may be part of an RA. > >> > >> Joe > >> > >> Joseph Chiusano > >> Booz Allen Hamilton > >> Visit us online@ http://www.boozallen.com > >> > >> > >>> -----Original Message----- > >>> From: Christopher Bashioum [mailto:cbashioum@mitre.org] Sent: > >>> Wednesday, May 25, 2005 9:40 AM > >>> To: soa-rm@lists.oasis-open.org > >>> Subject: RE: [soa-rm] David Linthicum Says: "ESB versus > Fabric.Stop > >>> It!" > >>> > >>> 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 > >>>>>>>>>>> > >>>>>>>>>>> > >>>>> > >>> > >>> > >>> > >>> > -------------------------------------------------------------- > ---------- > ------------------ > Ken Laskey > MITRE Corporation, M/S H305 phone: 703-983-7934 > 7515 Colshire Drive fax: 703-983-1379 > McLean VA 22102-7508 > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]