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


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]