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

[Carsten Leue <CLEUE@de.ibm.com>]

Hi Alejandro.

I don't think that I understand how Mike's proposal solves the JSR issue
that the portlet needs to be aware of read-only or read/write properties.
However it is a specifc optimization that saves roundtrips by moving logic
from the consumer to the producer.
Currently it works like this:
1. the consumer calls the producer in read-only mode
2. the producer (JSR 168 container) calls the portlet
3. the portlet recognizes that it has been called in read-only mode but
needs to modify some (e.g. backend) state. It communicates this to the
container
4. the producer throws a SOAP fault
5. the consumer calls the producer to clone the entity
6. the producer (JSR 168 container) clones the entity, i.e. the
conversational state, the entity state + all backend state. An apppropriate
implementation of this operation would be to move the actual clonling logic
to the porltet itself
7.the producer communicates the new entity handle back
8. the consumer reinvokes the producer with the new entity in read-write
mode

Mike's proposal eliminates the extra-roundtrips in 4,5 and 8. But it does
not eliminate the need for the portlet to know of the read-state and the
logic to clone the portlet's data.
The main reason why this cannot be handled completely by the container is
that the container cannot know what the complete entity state is and how to
clone it. If the complete entity state would only be the preference data
than I could think of some tricky algorithm to do so. But as this cannot be
guaranteed the portlet needs to know.

Best regards
Carsten Leue

-------
Dr. Carsten Leue
Dept.8288, IBM Laboratory Böblingen , Germany
Tel.: +49-7031-16-4603, Fax: +49-7031-16-4401



                                                                           
             Alejandro                                                     
             Abdelnur                                                      
             <alejandro.abdeln                                          To 
             ur@sun.com>               Michael Freedman                    
                                       <Michael.Freedman@oracle.com>       
             10/18/2002 12:32                                           cc 
             AM                        wsrp-wsia                           
                                       <wsrp-wsia@lists.oasis-open.org>    
                                                                   Subject 
                                       Re: [wsrp-wsia] Issue ???: producer 
                                       induced entity state changes        
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           





Based on what was said this morning during the conf call and a quick
scan to Mike's explanation I would be in favor of the 'clone' approach.
This would allow producer implementations to hide the details of
clonning from entities. Going specific, a JSR168 container could handle
the without any special intervention by the portlet.

Alejandro

Michael Freedman wrote:
> 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-
>
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>


----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>