Re: [wsrp] Consumer Request Lifecycle scope

[Subbu Allamaraju <subbu@bea.com>]

I agree with the concerns raised by Rich.

Personally, I had to explain/educate a number of portlet developers on 
making assumptions about WSRP life cycle phases taking place within a 
single request life cycle. In one specific instance, some developers 
wanted to treat the first render of a portlet after an interaction 
differently from all other following render requests. Your proposals 
seem to be addressing such usages.

Since the WSRP protocol does not guarantee that a render will follow a 
pbia/handleEvents phase, making assumptions about request life cycle may 
lead to bad programming.

Do you have any concrete examples that can only be solved with what you 
are proposing?

Subbu


Michael Freedman wrote:
> When we discussed transient properties I talked about a scope 
> representing the extent of a single client request in the consumer.  
> I.e. the execution of one complete lifecycle as we define it in wsrp.  
> At the time I indicated this scope was largely needed by producers to 
> manage portlet specific (non-shared) data.  Because it wasn't a shared 
> thing we dropped it.  Upon further reflection and after gaining more 
> experience with adapting environments such as JSF to wsrp I think we 
> would be well served to define a mechanism in wsrp 2.0 to facilitate 
> managing producer state a this scope albeit a mechanism not based on 
> transient properties.
> 
> The problem:
> Some portlet development models, though distinguishing between an action 
> phase and a rendering phase, assume that  these phases (typically) 
> complete within a single request lifecycle.  In so doing they rely on an 
> ability to maintain state between these phases which either implicitly 
> or explicitly is removed when the scope ends.  Unfortunately wsrp 
> doesn't provide any means for a producer to detect/manage such a scope.
> 
> Two possible solutions:
> 
>    1. Have the consumer provide a lifecyle id in the Runtime context. 
>       This id is the same for each call in a single lifecycle but unique
>       for each new lifecyle. 
> 
>       Pluses:  Relatively simple and straightforward addition. 
>       Relatively easy for consumers to implement -- for example a
>       consumer could use the current time as the lifecycle id.
> 
>       Minuses: Producers detect the termination of scope by recognizing
>       a new scope has begun.  Producers may want/need to account for
>       detecting termination by inactivity.
> 
>    2. Introduce a new consumer managed opaque state concept akin to
>       portlet sessionContext (perhaps called requestContext).  Like the
>       sessionContext the requestContext is passed to each lifecycle
>       operation [action, event, render] and returned from each.  Unlike
>       sessionContext the requestContext would not be a reference; it
>       would represent the state directly via a binary (opaque) field. 
>       At the beginning of a lifecycle [first call in a lifecycle] the
>       consumer would pass a null value [omit]  for this field.  For the
>       duration of the lifecyle the consumer would pass whatever the
>       producer had previously returned from the previous call in the
>       lifecycle.  At the completion of the lifecycle, the consumer would
>       discard the state.
> 
>       Pluses:  Consumer discards state at end of scope.  Producer has no
>       worries for detecting/managing.
> 
>       Minuses:  (1) Producer needs to be able to prepare its state so it
>       can be passed as an opaque binary field and receive such.  This
>       may not be something the higher level portlet environment models. 
>       (2) Data sets might be large making it inconvenient/inappropriate
>       to send across the wire.  (3) If the producer decides to send a
>       reference instead of the data itself it still has the minuses
>       discussed above. Note it recongizes a requestContext whose data is
>       null as an indicator that a new lifecycle has started so the
>       previous is out of scope.
> 
>   -Mike-
> --------------------------------------------------------------------- To 
> unsubscribe from this mail list, you must leave the OASIS TC that 
> generates this mail. You may a link to this group and all your TCs in 
> OASIS at: 
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php