RE: [soa-rm] changing shared state to shared view

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

<Quote>
I personally think SOA-RM should describe situations where intermediate
states can be accessed (status services, forward progress services, etc)
that are possibly of interest to the requesting process making use of
the entry point service. What prevents those intermediate services from
disclosing information about other services, in particular the entry
point service? While nothing more is learned about each service on its
own than through its inferface, a sufficiently general SOA should allow
for services that supply info on other services. 
</Quote>

Great thoughts - would say that these are more considerable for the RA
than the RM.

Joe

Joseph Chiusano
Associate
Booz Allen Hamilton
 
700 13th St. NW, Suite 1100
Washington, DC 20005
O: 202-508-6514  
C: 202-251-0731
Visit us online@ http://www.boozallen.com

-----Original Message-----
From: Dale Moberg [mailto:dmoberg@cyclonecommerce.com] 
Sent: Wednesday, April 12, 2006 1:45 PM
To: Duane Nickull; Chiusano Joseph; soa-rm@lists.oasis-open.org
Subject: RE: [soa-rm] changing shared state to shared view

Duane writes:

"State alignment is flawed IMO.  You cannot see past the interface
therefore how do you know (or why care) that someone's state is aligned
with yours.
As long as the externally visible properties are synced with your
requirements, you should not care what their actual state is."

BPSS modeled some open-edi and RNIF ideas that assume layering of
message processing. There are several layers of interfacing defined, and
not one monolithic layer called overall "service" So your reasoning
starts out from a false premise: you can see behind "the interface" to
higher layers. For example, if signals for AcceptanceAck and
AcceptanceAckException are used, then there is a layer at which the
validity of the request is acknowledged (from the standpoint of it being
one for which some response is to be performed).  Because the backends
for the responding long-running processes often optimize after all
orders are in (and do not merely use greedy algorithms) for resource
utilization decisions, there is a separation of process into
stages/layers each of which can be conducted somewhat independently. 

You may insist that architectures "should not care about intermediate
processing stage decisions," but that will fit only a certain class of
processing architectures. 

I personally think SOA-RM should describe situations where intermediate
states can be accessed (status services, forward progress services, etc)
that are possibly of interest to the requesting process making use of
the entry point service. What prevents those intermediate services from
disclosing information about other services, in particular the entry
point service? While nothing more is learned about each service on its
own than through its inferface, a sufficiently general SOA should allow
for services that supply info on other services.