RE: [soa-rm] David Linthicum Says: "ESB versus Fabric.Stop It!"

["Chiusano Joseph" <chiusano_joseph@bah.com>]

> -----Original Message-----
> From: Duane Nickull [mailto:dnickull@adobe.com] 
> Sent: Wednesday, May 25, 2005 9:31 PM
> To: Christopher Bashioum
> Cc: soa-rm@lists.oasis-open.org
> Subject: Re: [soa-rm] David Linthicum Says: "ESB versus 
> Fabric.Stop It!"
> 
> The service is invokable.  That is all it needs to do.  It 
> does not and should not care about anything else since it is 
> basically beyond its ability to control.  If something can 
> invoke it, it is equally possible that that something can 
> invoke other services and coordinate the sequence or parallel 
> nature of those calls.
> 
> Therefore, the assertion that it is the responsibility of the 
> orchestrator (I think you mean the consumer) to orchestrate 
> calls to multiple services.

Is the orchestrator *really* the consumer? Or is it more of an
intermediary that is itself a consumer (of the services it
orchestrates)?
 
> The services themselves in a specific architecture might need 
> to be specialized to fit in with a specific orchestration 
> sequence, but at runtime, the service itself does not know of 
> any calls to other services, only calls to it.
> 
> This is similar to a conversation we had about XML designed 
> using UML modeling techniques.  While it is good design to 
> work from a good object model to make XML, at runtime, the 
> parser only knows it is either XML or not XML and does not 
> care about whether it was made with UML.

Not always:
http://www-128.ibm.com/developerworks/library/x-wxxm24/#code1 
(sorry, could't resist;)

Joe
 
Joseph Chiusano
Booz Allen Hamilton
Visit us online@ http://www.boozallen.com
 
> Duane
> 
> Christopher Bashioum wrote:
> 
> > Excellent question. I hadn't thought of that before, but I 
> think the 
> >answer is that it is the responsibility of the service - not the 
> >orchestrator.  If the orchestrator is really good, but the 
> services are 
> >not orchestratable (due to tight coupling with consumers or other 
> >services, or too large a granularity, etc.) then you cannot 
> re-purpose 
> >or orchestrate
> >
> >-----Original Message-----
> >From: John Harby [mailto:jharby@gmail.com]
> >Sent: Wednesday, May 25, 2005 7:57 PM
> >To: soa-rm@lists.oasis-open.org
> >Subject: Re: [soa-rm] David Linthicum Says: "ESB versus 
> Fabric.Stop It!"
> >
> >Is it the responsibility of the service to be orchestratable 
> or is it 
> >the responsibility of the orchestrator to conform? ;)
> >
> >On 5/25/05, Christopher Bashioum <cbashioum@mitre.org> wrote:
> >  
> >
> >> Good point.  However, I would still say that SOA does not care if 
> >>orchestration is actually done or not, only that the services are 
> >>orchestratable.
> >>
> >>There are many SOA implementations that do not currently have any 
> >>orchestration, though they do have aggregation.
> >>
> >>
> >>-----Original Message-----
> >>From: Metz Rebekah [mailto:metz_rebekah@bah.com]
> >>Sent: Wednesday, May 25, 2005 5:01 PM
> >>To: soa-rm@lists.oasis-open.org
> >>Subject: RE: [soa-rm] David Linthicum Says: "ESB versus 
> Fabric.Stop It!"
> >>
> >>    
> >>
> >>>Can I ask you what would make a single service care that 
> the consumer
> >>>      
> >>>
> >>is
> >>    
> >>
> >>>invoking it as part of an orchestration?  Why should the 
> service care.
> >>>It's function is simply to facilitate the invocation request.  If 
> >>>someone created a dependency on the service to know about 
> the state 
> >>>of other service invocation requests, that would be very bad 
> >>>architecture IMO and also violate the principles of 
> autonomicity (not 
> >>>really an English word but you get the idea).
> >>>      
> >>>
> >>Ah!  So here lies an important distinction that gets back to the 
> >>house/community analogy - and what makes SOA a SOA?  Is SOA == the 
> >>house or is SOA == community?  A single service probably 
> wouldn't care 
> >>whether or not it is being invoked as part of an 
> orchestration, much 
> >>like a house doesn't care if it is in a planned development 
> or urban 
> >>development or a cornfield or an island.  But, a SOA may very well 
> >>care about it, much like a community cares about things like the 
> >>positioning of individual houses and green space (which 
> don't directly 
> >>related to an individual house).
> >>
> >>
> >>    
> >>
> >>>I will propose that we accept this axiom:
> >>>
> >>>"Services should not have to have explicit knowledge of 
> the states of 
> >>>other services called by a consumer that invokes them"
> >>>      
> >>>
> >>So this goes back to the service as an operational concept, and I 
> >>think leads me to think that we are working toward a 
> definition at the 
> >>"community" level and not at the "house" level.
> >>
> >>Rebekah
> >>
> >>
> >>
> >>
> >>    
> >>
> >
> >
> >
> >  
> >
>