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


It does not raelly have an opposite, except as much as "talk" has an
opposite that is "not talk" (and is that "silence"?).
Service is a capacity to use a resource managed by another entity, it is
event based and it involves crossing a boundary between entities, that much
we seem to have agreed so far. If something is not a service, it's not a
service: it doesn't mean that it *is* something else. The concept of
"opposite of a service" is, for me, meaningless...

-Peter
-----Original Message-----
From: Duane Nickull [mailto:dnickull@adobe.com] 
Sent: 25 May 2005 18:29
Cc: soa-rm@lists.oasis-open.org
Subject: Re: [soa-rm] David Linthicum Says: "ESB versus Fabric.Stop It!"

The question that Rebekah asked that is tough and we need to answer is "What
is the opposite of Services".  On other words, if it is not service
oriented, what is it.  This is a tough question and our RM must address a
level of clarity that we can point at something that is not SOA as well as
something that is.

I would like to hear opinions on this.

Duane

Rex Brooks wrote:

> Having finally now gone through the whole of draft 7 other than the 
> supporting materials, and having gone through all the threads, these 
> sorts of conclusions finally start to be distilled out of it. But, it 
> takes all of the discussion so far, and will take much more I am sure.
> I like Rebekah's last diagram the most of those so far, but it will 
> still take some more work to reach the ultimate draft for the first 
> version.
>
> Ciao,
> Rex
>
> At 1:30 PM -0400 5/25/05, Chiusano Joseph wrote:
>
>>  > -----Original Message-----
>>
>>>  From: Rex Brooks [mailto:rexb@starbourne.com]
>>>  Sent: Wednesday, May 25, 2005 1:27 PM
>>>  To: Chiusano Joseph; soa-rm@lists.oasis-open.org
>>>  Subject: RE: [soa-rm] David Linthicum Says: "ESB versus  
>>> Fabric.Stop It!"
>>>
>>>  I think a single service and a single service consumer for  that 
>>> service comprise the definition of an atomic SOA.
>>>  Multiple services in a void of service consumers don't make  an 
>>> SOA, only the potential for an SOA. We reflect that in  current 
>>> thinking in our modeling in the draft 7 of the RM.
>>>  Figures 2 and 2.1, even though 2.1 precedes 2, and 2 shows  
>>> multiple services behind Service A. It might be wise for us  to have 
>>> another diagram and arrange it so that the series runs:
>>>  2.0 Components of a Service, 2.1 Components of a SOA, and 2.2  
>>> Service Aggregation.
>>
>>
>> I like that idea very much.
>>
>> Joe
>>
>> Joseph Chiusano
>> Booz Allen Hamilton
>> Visit us online@ http://www.boozallen.com
>>
>>>  Ciao,
>>>  Rex
>>>
>>>  At 9:13 AM -0400 5/25/05, Chiusano Joseph wrote:
>>>  >  > -----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.
>>>  >
>>>  >Which brings us back to what I believe is the single most 
>>> important  >question for us to answer: Does one service constitute a  
>>> SOA? Or are 2  >or more services required?
>>>  >
>>>  >If 2 or more services are required, then it seems to me that  in 
>>> order  >to call something a *SOA* reference model, the notion of 
>>> multiple  >services must be incorporated - as that is the minimal 
>>> amount of  >information necessary to *effectively* represent/model 
>>> the "targeted  >entity" (which is SOA) for the intended audience.
>>>  >
>>>  >If one service constitutes a SOA, this implies that a SOA  may 
>>> have more  >than one service. It then seems to me that one has a 
>>> choice for their
>>>  >RM: include only a single service in the model, or include 
>>> multiple  >services. The question then becomes which approach 
>>> enables the most  >effective representation for the intended audience.
>>>  >
>>>  >So as you see, I believe everything flows from this single most  
>>> >important question.
>>>  >
>>>  >Joe
>>>  >
>>>  >Joseph Chiusano
>>>  >Booz Allen Hamilton
>>>  >Visit us online@ http://www.boozallen.com  >  >>  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  >>>>>>>
>>> >>>  >  >> >
>>>  >>
>>>
>>>
>>>  --
>>>  Rex Brooks
>>>  President, CEO
>>>  Starbourne Communications Design
>>>  GeoAddress: 1361-A Addison
>>>  Berkeley, CA 94702
>>>  Tel: 510-849-2309
>>>
>
>




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]