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

["Christopher Bashioum" <cbashioum@mitre.org>]

 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