[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!"
Duane: Stipulated that particular houses have a particular embedding in the environment. However, why is it that we have made description an essential part of the SOA RM? The answer is, I think, because descriptions are an essential part of modeling service oriented systems. It is of the essence to the benefit of SOAs that we have tons of descriptions. I think (only thinking at this stage) that a similar argument can be made to see how services should be related to each other. The fundamental reason for extending to this is that (a) multiple services are also a key part of the benefit of SOAs and (b) it requires concepts not contained in service in the singular. Note that I am not, here referring to using a service. I.e., modeling service consumers. I also believe that, on the whole, the promise of leveraging multiple services is more in the imagination than in the practice (I know this from one simple fact: no-one seems to be all that keen on working on transparent service composition.) So, what might these concepts be? A first stab: 1. One service can be dependent on another. (This is a possible candidate for a resource-level modeling, I am not sure) 2. A given service may be an epiphenomenon of multiple services (this is transparent service composition) 3. A service may have a management relationship with another Not entirely random thoughts, but need more thinking... :) Frank On May 25, 2005, at 10:29 AM, 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 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>> >>>>>> >>>> >>>> >>>> >>> >>> >>> >>> >> >> >> >> >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]