Re: [wsrp-interfaces] Transient properties

[Rich Thompson <richt2@us.ibm.com>]

I think these are good questions, but
also think that we should focus first on the overall model and debate the
semantics/value of particular scopes once we agree that introducing a multi-scoped
transient property model makes sense.

This proposal includes:
1. A means by which Portlets declare
state which the Consumer must instantiate if it is going to use the Portlet.
2. A recognition that state can have
various lifetimes and a means by which the Portlet and Consumer cooperatively
establish the lifetime for each property.
3. A strong encouragement that Consumers
cause multiple declarations of the same name to be shared across the declaring
Portlets. This leaves room for some edge cases where the Consumer application
needs to not share such properties in order to provide intended results
while establishing the normal case being the sharing of such properties.
4. Property values can be set by any
constituent (while this was not called out, I presume this means on responses
from pbia() and he(), on URLs and by any Consumer component)

In addition to determining whether we
find value in such a model, we should also debate where introducing such
a model would break our normal mapping of RESTful behavior (the key issue
being whether an http get on render and resource URLs results in idempotent
processing on both the Consumer and Producer). What guidance would we provide
such that a render URL setting property values could be processed in an
idempotent manner that allows it to be replayed?

Rich

Stefan Hepper <sthepper@hursley.ibm.com>

09/07/05 05:36 AM

To	Michael Freedman <michael.freedman@oracle.com>
cc	interfaces <wsrp-interfaces@lists.oasis-open.org>
Subject	Re: [wsrp-interfaces] Transient properties

Hi Mike,
could you provide some use cases for these different scopes?

- why would you need a pre client request scope? Isn't that violating 
the MVC pattern where the render should be replayable?

- what is the use case for the consumer session scope? Why would we 
allow to change the consumer session state with a render link?

- same for application scope, why can you modify it with a render link?

Stefan


Michael Freedman wrote:
> Attached is a proposal for supporting transient properties.  You
may 
> recall that in mid-August we decided to make one last push to see
if we 
> could define transient properties in 2.0 vs relying on public parameters
> [and needing to retrofit in 3.0].  Please review and comment
asap as 
> there isn't much time to refine this before needing to make the go/no
go 
> decision for 2.0.     -Mike-
> 
> ------------------------------------------------------------------------
> 
> 
>     Transient Properties
> 
> 
>       Definitions:
> 
> Transient Property:  a piece of shared consumer managed state
with a 
> defined-persistent lifetime declared by the producer and supplied
to 
> that producer in all non-initialalization calls in its Markup port
> (required feature in 2.0).
> 
> 
>       Summary
> 
> Transient properties:
> 
>     * a piece of shared ... state: the property can be set/received
by
>       any constituent of the consumer including the
declaring portlet.
>     * are consumer managed state:  the consumer maintains
the property
>       and supplies it to the producer at appropriate
times.
>     * have a defined non-persistent lifetime:  lifetimes
are defined by
>       scope (names).  The following names are
reserved/predefined:
>       wsrp:consumerRequest, wsrp:navigationalState,
>       wsrp:consumerSession, and wsrp:consumerApplication.
[To fit into
>       our existing declarative model we will also need
wsrp:persistent
>       and wsrp:registration, though these don't pertain
to transient
>       properties; see below for details]
>     * are declared by the producer:  the basic declaration
includes a
>       name, type, suggested default, minimum required
scope, and
>       preferred scope.
>     * supplied to that producer on all non-initalization
call in its
>       Markup port: values for each property declared
by that portlet and
>       maintained by the consumer are sent on each invocation
of
>       PerformBlockingInteraction(), HandleEvents(),
GetMarkup(), and
>       GetResource().
>     * (required feature in 2.0):  Consumers must support
transient
>       properties with at least wsrp:consumerRequest
and 
>       wsrp:navigationalState. 
> 
> Scopes:
> 
>     * wsrp:consumerRequest:  in this scope the property
is maintained
>       for the lifetime of the consumer request.  I.e.
one pass through
>       our 3-step protocol.  This enables data
management within a single
>       request lifecycle [something not currently doable
in WSRP 1.0] .
>        Though this scope can be used for intra-lifecycle
coordination
>       its most likely used by the portlet itself to
support/manage such
>       a notion of scope in itself.  
>     * wsrp:navigationalState: in this aintscope the property
is
>       maintained for the same duration as the consumer
maintains the
>       portlets' navigationalState.  This enables
the coordination at the
>       same level as navigational state is being maintained.
 Its
>       introduced  not only because its  reasonable
to tie this
>       coordination lifetime to the same lifetime as
something that
>       already exists [navigationalState], but also
because it should be
>       easy for consumers to do so.
>     * wsrp:consumerSession: in this scope the property is
maintained for
>       the lifetime as the consumers client/end-user
session.
>     * wsrp:consumerApplication: in this scope the property
is maintained
>       for the lifetime that the consumer itself is
active.
> 
> How they work:
> 
>     * TransientProperties are declared in PortletDescription
[though
>       described in ServiceDescription].
>     * The requiredScope field must come from the set of
scopes consumers
>       are required to support [consumerRequest and
navigationalState].
>        The preferredScope field may name any scope
including a custom
>       scope.  The requiredScope field must be
of equal or lesser scope
>       then the preferredScope.   Note: do we think
that WSRP 1.0
>       adequately defines/requires the ntion of consumerSession
scope?
>        If so we can add this to the list of required
scopes.
>     * The consumer uses the declaration to create/manage
the property.
>        The property qname identifies the property.
 Consumers are
>       strongly encouraged to recognize identical name/type
declarations
>       from different portlets as declaring the same
property as
>       properties are commonly used for data coordination.
 In such a
>       case only one transient property is maintained
and its value is
>       shared between all declaring parties. The consumer
is free to
>       choose any scope equal to or higher then the
scope specified in
>       requiredScope.  The consumer is free to
move the property to a
>       different scope at any time as long as it doesn't
violate the
>       stated minimums. This later is provided so that
when portlets get
>       added to a page at runtime, the consumer can
upscope an existing
>       transient property it wants to share.
>     * The consumer passes the property name, value, and
current scope on
>       each invocation of the PerformBlockingInteraction,
HandleEvents,
>       GetMarkup, and GetResource when that property
has a non-null
>       value.  When a property is out of scope
it is has a null value.
>     * The producer uses the property values as it sees fit.
 The
>       producer recognizes the absence of a passed property
as an
>       indication that the properties value is null
[or it is out of scope].
>     * The producer/portlet can set a property value in the
response from
>       a PerformBlockingInteraction and HandleEvents
and by encoding the
>       action of setting the property in a renderURL.
> 
> 
>       Details:
> 
> 
>         PropertyDescription:
> 
>     change to:
>      PropertyDescription
>         [R] QName        name
>         [R] QName        type
>     *    [O] string       preferredScope
>         [O] string       requiredScope
>         [O] Property     default*
>         [O] LocalizedString    label
>         [O] LocalizedString    hint
>         [O] string        capabilities[]
>         [O] Extension        extensions[]
> 
>     from:
>      PropertyDescription
>         [R] QName        name
>         [R] QName        type
>         [O] LocalizedString    label
>         [O] LocalizedString    hint
>         [O] string        capabilities[]
>         [O] Extension        extensions[]
> 
> Discussion:
> I added the preferredScope, requiredScope, default fields into 
> PropertyDsecription because a ModelDescription must be used to define
> the set of transient properties.  The way we have defined 
> ModelDescription requires everything be in PropertyDescription.  These
> fields are optional.  The set of predefined scopes are:
> 
>     wsrp:consumerRequest:  duration of a single client/consumer
request
>     wsrp:navigationalState: duration of navigationalState
in this consumer
>     wsrp:consumerSession: duration of consumer's user session
>     wsrp:consumerApplication: duration of active consumer.
>     wsrp:persistent: duration is persistent across consumer
activations.
>     wsrp:registration: duration of this registration
> 
>     The default preferred/required scope value is based
on the context
>     of the description.  For registration properties
its
>     wsrp:registration [this is the only valid value].  For
a portlet's
>     properties its wsrp:persistent [again this is the only
valid value].
>      In the case of transient properties its wsrp:consumerRequest.
> 
> 
>         PortletDescription:
> 
>     change to:
>      PortletDescription
>         [R] Handle        
   portletHandle
>         [R] MarkupType        markupTypes[]
>         [O] ID          
     groupID
>         [O] LocalizedString      
 description
>         [O] LocalizedString      
 shortTitle
>         [O] LocalizedString      
 title
>         [O] LocalizedString      
 displayName
>         [O] LocalizedString      
 keywords[]
>         [O] ID          
     portletID
>         [O] QName        
   publishedEvents[]
>         [O] QName        
   handledEvents[]
>     *    [O] ModelDescription     transientPropertyDescriptions*
>         [O] string        
    userCategories[]
>         [O] string        
    userProfileItems[]
>         [O] boolean        
   usesMethodGet
>         [O] boolean        
   defaultMarkupSecure
>         [O] boolean        
   onlySecure
>         [O] boolean        
   userContextStoredInSession
>         [O] boolean        
   templatesStoredInSession
>         [O] boolean        
   hasUserSpecificState
>         [O] boolean        
   doesUrlTemplateProcessing
>         [O] Extension        
   extensions[]
> 
>     from:
> 
>      PortletDescription
>         [R] Handle        
   portletHandle
>         [R] MarkupType        markupTypes[]
>         [O] ID          
     groupID
>         [O] LocalizedString      
 description
>         [O] LocalizedString      
 shortTitle
>         [O] LocalizedString      
 title
>         [O] LocalizedString      
 displayName
>         [O] LocalizedString      
 keywords[]
>         [O] ID          
     portletID
>         [O] QName        
   publishedEvents[]
>         [O] QName        
   handledEvents[]
>     /    [O] ModelDescription     publicParameterDescriptions
-- removed/
>         [O] string        
    userCategories[]
>         [O] string        
    userProfileItems[]
>         [O] boolean        
   usesMethodGet
>         [O] boolean        
   defaultMarkupSecure
>         [O] boolean        
   onlySecure
>         [O] boolean        
   userContextStoredInSession
>         [O] boolean        
   templatesStoredInSession
>         [O] boolean        
   hasUserSpecificState
>         [O] boolean        
   doesUrlTemplateProcessing
>         [O] Extension        
   extensions[]
> 
> Discussion:
> publicParameters were merely transient properties at 
> wsrp:navigationalState.  To add transientProperties we merely
replace 
> the publicParameterDescriptions field with a 
> transientPropertyDescriptions field.
> 
> 
> Property Types:
> 
>     change to:
>      Property
>         [R] QName    name
>         [O] string    xmlLang
>         [O] Object    value[]
>     *    [O] string    scope*
> 
>     from:
>      Property
>         [R] QName    name
>         [O] string    xmlLang
>         [O] Object    value[]
> 
> Discussion:
> With the addition of transient properties there is now a need/interest
> in representing the [current] scope of a given property .  We
require 
> this field have a value when passing transient properties otherwise
its 
> optional.
> 
> 
>         RuntimeContext:
> 
>     change to:
>     RuntimeContext
>         [R] string        userAuthentication
>         [O] Key        portletInstanceKey
>         [O] string        
namespacePrefix
>         [O] string        interactionFieldPrefix
>         [O] Templates        templates
>         [O] ID          
 sessionID
>     *    [O] Property        
transientProperties[]*
>         [O] Extension        extensions[]
> 
>     from:
>      RuntimeContext
>         [R] string        userAuthentication
>         [O] Key        portletInstanceKey
>         [O] string        
namespacePrefix
>         [O] string        interactionFieldPrefix
>         [O] Templates        templates
>         [O] ID          
 sessionID
>     /    [O] Property        
publicParameters[]/
>         [O] Extension        extensions[]
> 
> Discussion:
> Again, to pass transientProperties to performBlockingInteraction,
> handleEvents, getMarkup, and getResource, we merely replace the 
> publicParameters field with a transientProperties field.
>