[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!"
This expanding model is growing on me. I think we should keep growing it and finding parallels when other SOA questions arise. It will help clarify our thoughts and be ready-made to explain to others. Ken On May 25, 2005, at 1:29 PM, Duane Nickull wrote: > Let me expand this analogy to suit the conversation. > > A house is a house, it serves it's purpose whether it is part of the > community or not. In order to serve the needs of its' owners, it may > have to be specialized to fit in. There are interfaces to the > community - the outwards appearance, the front door (for people to > enter and leave), the plumbing interface must be able to adapt to the > communities, same for electrical systems etc.. It is almost (but not) > completely irrelevant when designing a front door that it will be used > by people who are part of a community vs. someone who is visiting from > half way around the world. When architecting the plumbing, architects > will have to consider the system used by the community (septic tank vs > city sewer, diameter of supply lines, pressure of water supply etc.). > That is specific to individual architectures for houses however. The > RM for house just says that you need plumbing in order that the house > services it purpose as a human habitat and also states or implies that > each house will have to specialize the plumbing in order to be adapted > to it's specific environment. > > The same applies to the concept of service. A service itself does not > care that it is being invoked as part of an orchestration vs. not. > The service description, however, may have to include some extra > detail specific to the implementation. The service is the front door > - the place where it interfaces with the rest of the world. > > Our job in building the reference model is to ensure that we include > the abstract concept of a front door for people to enter and exit the > house. In our case we note that it's function is to facilitate > invoking something. We also must say that a service description is > present and its function is to declare the details of the service that > invokers need to use (or decide to use) the service. Due to the > nature of a RM, it is implicit that each service designer must > specialize this component in order that is meets their particular > requirements. Our job is NOT to define what specific (ie - concrete) > requirements are, however, that may be illustrated in an example > (Appendix B) or in a separate RA. > > Duane > > Behera, Prasanta wrote: > >> Exactly. Are we designing a house or a town/community? When any >> organization ventures into the "SOA" world, all the infrastructure >> issues needs to be looked into (like a town planning) in addition to >> the individual "house" design. We will have a better story if we >> elucidate the dependency/relationship and focus on the abstract model >> of "house/service" . >> >> Thanks, >> /Prasanta >> >> >> -----Original Message----- >> From: Francis McCabe [mailto:fgm@fla.fujitsu.com] Sent: Wednesday, >> May 25, 2005 8:59 AM >> To: Christopher Bashioum >> Cc: soa-rm@lists.oasis-open.org >> Subject: Re: [soa-rm] David Linthicum Says: "ESB versus Fabric.Stop >> It!" >> >> 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]