[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!"
There is the concept of a service which can have many identifiable instances. There is the negotiable semantics embodied by all the services I need to invoke for a task, where each service may have its own vocabulary. Ken On May 25, 2005, at 9:55 PM, Chiusano Joseph wrote: > <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 >> >> >> >> ------------------------------------------------------------------------ ------------------ 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]