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

[Duane Nickull <dnickull@adobe.com>]

Hi Rebekah:

Since SOA is a paradigm for architecture with services as the central 
component, I would assume it is applicable to the house (application).  
I make a "foo" application, and architect it with service(s), a service 
description, a policy statement etc, I can state my architecture for the 
Foo application is "service oriented".  I do not need an entire 
community of other SO applications or even a consumer present before I 
can make this claim.  It is simply stating that the architecture is 
oriented towards services being present.  This does not mean that it is 
constrained to exist alone in a void without other services.  As the 
analyst joseph quotes stated "orchestration of multiple services is core 
value for SOA", which in itself means that it is not part of SOA.

An SOA infrastructure OTOH, would be equivalent to the community.  Much 
the same way as the OSI stack is for networks.  A network with one end 
point is hardly useful or interesting, however, making logical divisions 
in the stack is requisite to architecting a network that consistently 
aligns with other networks.

Now I want to confuse you further with inline comments ;-)

Metz Rebekah wrote:

> 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.
>
DN - actually, a single concrete service will probably take into account 
what it's use is.  It is the reference model that does not get 
specific.  That is what we are trying to write and should remain 
abstract.  Once we get past the RM into RA, we can then start showing 
more concrete things.  An architect for a single house must account for 
the fact that roads exist and the house must be positioned to align with it.

> 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).
>  
>
DN - and likewise, an SOA infrastructure will probably also take similar 
things into account, but the RM does not. It is abstract. RA is the 
place for that.

> 
>  
>
>>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.
>  
>
DN - once again, I would ask anyone to state any position where a 
service has to know about the state of another service being called 
directly by its consumer.  This does not include the service composition 
or aggregation scenarios, but refers to why a single service should have 
to know about the state of a series of transactions. 

Duane