[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!"
But I can plan to build a house with the assumption that utility hookups will exist without including a description of the power transmission lines. Similarly, I need a computing device to use a SOA service, but the computer is not part of the SOA. However, certain attributes of power transmission or of a computer may be necessary to give the appropriate grounding to a RM of a house or a SOA. Ken On May 25, 2005, at 11:58 AM, Francis McCabe wrote: > However, ...., > Town planning is a necessary part of modern society. You do not get > to build a house, or even to make significant modifications to the > house, without planning permission/city permits whatever. (In fact > there is a whole raft of people with an interest in your house.) > The upshot of that thinking would be, in my current opinion, that > while how you orchestrate is out of scope, the fact that there may be > networks of services may be an important part of the RM. > At the moment, I could not say how this could fit in to the RM; > something about dependency relationship between services seems to be > at the appropriate level of abstraction. > Frank > > On May 25, 2005, at 6:01 AM, Christopher Bashioum wrote: > >> Duane - that's a good point. I'm beginning to think that >> orchestration >> itself is not part of SOA, rather, the end result of an SOA is an >> architecture of services that are "orchestratable". >> >> >> >> -----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. >> >> 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]