OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

soa-rm message

[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!"


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]