[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [wsrp-wsia] Issue ???: producer induced entity state changes
Andre - I agree with the choices. However I see the third one that the portlet is aware of its read-state. This leads to the scenario I pointed out in the original note. Best regards Carsten Leue ------- Dr. Carsten Leue Dept.8288, IBM Laboratory Böblingen , Germany Tel.: +49-7031-16-4603, Fax: +49-7031-16-4401 Andre Kramer <andre.kramer@eu. citrix.com> To Carsten Leue/Germany/IBM@IBMDE 10/18/2002 04:18 cc PM wsrp-wsia <wsrp-wsia@lists.oasis-open.org> Subject RE: [wsrp-wsia] Issue ???: producer induced entity state changes Carsten, [as I believe Mike is off-line today] I see two choices: 1) The producer always (conservatively) clones the entity if changeOK==false. or 2) The scheme addresses only Entity preferences (or Portlet Properties) but not other Portlet Application state. Basically, as Portlets are required to explicitly "store" preference changes to make them persist, the Portal has a chance to detect the group "commit" and force a clone. [I was quite close to attempting Mike's proposal with a similar scheme which passed modified properties back to the consumer who then does a clone (also creating a new session for the new Entity) followed by a setProperties (followed by a getMarkup and not a performInteraction-retry). Mike's proposal optimises this by eliminating the redundant n/w trips.] In 2, application state (other than Entity properties) is outside the copy on write mechanism. I find it hard to imagine rolling back-end or business logic because the presentation tier has faulted on a write to its customisation settings, and I would make this distinction explicit: preferences are copy-on-write; application state is read/write. Programming to a model that needs to roll back if any changes are required is going to be impossibly complex (without full transactions) with loosely coupled application tiers. This may also give us a way to address the "properties changes in getMarkup/render". Portlets could be allowed to interact with back-end systems in any way they chose (with danger of replay and side-effects noted for render()). This allows JSPs to be included that can still read (an even write-uncommitted) properties/preferences. But they may not "store" property modifications as any scriptlet that calls the Properties.store() method would get an exception in render(). regards, Andre -----Original Message----- From: Carsten Leue [mailto:CLEUE@de.ibm.com] Sent: 18 October 2002 13:50 To: Alejandro Abdelnur Cc: Michael Freedman; wsrp-wsia Subject: Re: [wsrp-wsia] Issue ???: producer induced entity state changes 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> ---------------------------------------------------------------- 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>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC