[wsrp-wsia] Issue ???: producer induced entity state changes

[Michael Freedman <Michael.Freedman@oracle.com>]

Sorry, but we got on to this topic this morning without identifying its
issue number.

This morning we discussed a potential modification to the 2 phased
protocol described in the .7 draft supporting producer controlled entity
state changes.  The current proposal has us passing a boolean to each
operation where a producer might update entity state [currently only
performInteraction].  The boolean is called entityStateChangeOK.  If
true the producer can freely update an entity's state.  If false, the
producer must not update the entity state.  Rather it throws a special
fault which the consumer recognizes and decides on how to proceed.
Typically, it is expected the consumer will clone the entity and then
recall the original operation on the newly cloned entity. This handles
the situation that the consumer understand/manages when new entities
come into existence, however the producer has a need to update entity
state.

In a side conversation with Rich, I had suggested the following
modification to this scheme.  Expand the meaning of
"entityStateChange".  Allow this field to carry one of three values:
"OK", "Fault", or "Clone".  "OK" and "Fault" has the same semantics as
the original proposal.  "Clone" means the producer MUST clone the entity
prior to making any state change.  Upon return from the call the
producer returns the new entity [and new refhandle] to the consumer who
MUST update its state accordingly.

This morning it was pointed out that a simpler scheme could be
sufficient.  This scheme removes the "Fault" situation in deference to
"Clone".  I.e. The field would become "cloneEntityOnStateChange".  If
the value is true, the producer MUST clone the entity before making any
changes, otherwise it is free to change the entity state in any way it
desires.

I had originally proposed the first scheme as I was worried there might
be use cases where the consumer had to direct/control the clone
operation.  I.e. we have talked about giving the consumer [some]
latitude in supporting hierarchies/etc.  I wasn't sure whether in such
situations a simple clone was sufficient.  Keeping the "Fault" case
allowed a [back]door for these consumers.  If we choose to move to the
simpler, no-fault, scheme folks need to make sure there isn't a need for
anything other then a simple clone.

I will leave it to Rich to expand upon this.  Specifically, to describe
the changes to the return value(s) from performInteraction.

    -Mike-