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


Any self-contained system, is by definition, not SOA. It may have any 
number of functional services within it, but as long as it is 
self-contained it is not SOA. That's why I keep saying that the 
atomic unit of SOA is a service AND a service consumer. I guess we 
have to qualify it to the extent that the systems are essentially 
separate, even if they may have endpoint interfaces that allow 
connection and other connections are possible or even occur, but they 
are not connected as an atomic unit until the service is invoked, or 
an agreement to allow invocation has been reached.

That is of course, just my opinion, even though I state it as if it were fact.

Ciao,
Rex

At 4:21 PM -0700 5/25/05, Duane Nickull wrote:
>While relevant, this is more of a "good vs. bad" design.  A service 
>that duplicates another service is still a service per se.   This 
>did twig a relay in my own cerebral cortex however.
>
>One thought that did occur (based on your post), is that using a 
>procedural methodology and re-constituting a service's functionality 
>within each block of code that needs it is definitely not SOA.  It 
>is however OO.  So what makes SOA different than OO?  OO is usually 
>within a known environment while SOA does not presuppose the same 
>environment and must have additional components to explicitly 
>facilitate the functionality of declaring the details the consumer 
>needs.
>Let's continue this thread in response Rebekah's question.  I liked 
>the way she asked it.
>
>D
>
>Chiusano Joseph wrote:
>
>>>-----Original Message-----
>>>From: Duane Nickull [mailto:dnickull@adobe.com] Sent: Wednesday, 
>>>May 25, 2005 2:29 PM
>>>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.
>>>   
>>>
>>
>>Duplication of services instead of sharing services: Not SOA.
>>
>>Kind Regards,
>>Joseph Chiusano
>>Booz Allen Hamilton
>>Visit us online@ http://www.boozallen.com
>>
>>>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
>>>>>>
>>>>>>         
>>>>>>
>>>>


-- 
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]