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

[Duane Nickull <dnickull@adobe.com>]

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.

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.

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