OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrp-interfaces message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [wsrp-interfaces] Transient properties


Richard Jacob wrote:
> Subbu Allamaraju <subbu@bea.com> wrote on 09/08/2005 03:25:34 PM:
> 
>  > Some comments below.
>  >
>  > Subbu
>  >
>  > Richard Jacob wrote:
>  > > I have some comments on the scopes:
>  > >
>  > > - wsrp:consumerRequest
>  > > This seems to be pretty much the same as sharing a property via 
> events.
>  > > Didn't we introduce publicParams (and now transient properties) 
> because
> we
>  > > argumented that events are considered a "one time thing" and difficult
> to
>  > > manage the shared consumer managed state use case. If we have 
> events in
> 2.0
>  > > why should we introduce a similar means by introducing this scope.
>  >
>  > How is this the same as sharing a proeprty via events? You could
>  > probably work-around with events, but it is lot more expensive.
> well, conceptually it is the same. Via events you pass the param as an
> event to all portlets, they compute a new navState and redner accordingly.
> Open questions we had: what happens on page-reload, where is the data
> stored, how long, when do the values need to be re-supplied ,etc.
> The above scope raises the same questions but only moves the caching to the
> cosumer side.

I don't think these questions are unique to transient properties. 
How/where the consumer can store these properties are up to the impl to 
figure out. A memory-hog consumer could store these somewhere in its 
memory (session, context etc), or it could delegate to an external 
caching layer.

> What are the use cases for this one time shot?
> 
>  >
>  > > - wsrp:navState
>  > > This makes sense for me. The use cases we intended to solve with the
>  > > proposal are really transparent/shared navState. The Consumer can
> choose
>  > > how to handle its navState (perPage, or broader).
>  > > It would offer a consistent end-user experience, i.e. the transient
>  > > properties disappear in the same way navState does.
>  > >
>  > > - wsrp:consumerSession
>  > > why do we need this? It seems to produce an inconvenient end-user
>  > > experience. If the session times out part of the UI is not displayed,
>  > > because parts of the navState get lost.
>  >
>  > The main use case I can think of is to let a group of portlets maintain
>  > some state about, e.g. the user or something that the user is doing as
>  > part of a session.
> 
> well, so your intent is to use have a shared session accross producers? And
> allow every portlet to write into the session?
> I can see you use case and know that customers like to heave a global
> galactic store because of its ease of use.
> But there is one think to consider. Consumers try to keep their sessions as
> small as possible.
> Sessions don't scale very good. And allowing everybody to stuff things in
> is quite dangerous and can prohibit large scalable systems.
> Then the question arises how can data be deleted, otherwise sessions will
> grow.

That's a good point. To take a property out of a scope, portlet or the 
consumer could simply set a nil value.

>  > > - wsrp:ConsumerApplication
>  > > what is meant by that? Is it implicating some kind of persistence? how
> is
>  > > it different to navState?
>  >
>  > In the J2EE world, this context is similar to shared servlet context.
>  > Again, the use cases would be similar to consumerSession. The only
>  > difference is that this scope is not tied to a given session. This is
>  > broader than consumerSession.
> 
> So? what is the definition?

"Duration of the consumer" as Mike's proposal states.

>  >
>  > > I don't think we need all of these scopes and I have the feeling that
> this
>  > > will definitly confuse developers and that thing really get messed up.
>  > > In my opinion one crisp definition (refering to the props as a "shared
>  > > navState") will be clearer and solve the use cases we initially had in
>  > > mind, i.e.
>  > > resultingNavState = portletOpaqueNavState + transientProperties
>  >
>  > I'm afraind that is too simplistic. I got a chance to speak to several
>  > developers who using WSRP in their apps, and lack of sharing data with
>  > these scopes was pointed out as one of the key limitations. The pain is
>  > understandable. In most large enterprises, although portlets are fairly
>  > decoupled in terms of processing logic and UI, portlets need to somehow
>  > coordinate with each other to provide for broader use cases and
>  > experience at the consumer level. Transient properties offer an
>  > inexpensive way to share transient state not just across requests, but
>  > across a group of portlets.
> 
> well yes, we have the same set of customer requiring the data sharing.
> But that's the point. In most cases they want a means to share data accross
> portlets, period.
> Scoping was not the issue for most of our customers at least the ones I
> know.
> We already noticed that some customer have problems to distinguish between
> navState, interactionState, session, groupSession.
> So what they often end-up with is to stuff the things in the most general
> means and if needed namespace themselves.
> And I'm afraid we're adding more confusion to this now. (And there are
> events, too).

Not exactly. Scoping goes along with data. For example, consider JSP 
model. There are several scopes to deal with, and each of those scopes 
have distinct roles, and solve distinct use cases. In any case, producer 
containers should attempt to abstract these scopes to existing/new 
programming models and shield the details from portlet developers. The 
same goes for other WSRP constructs like navState, interactionState, 
session etc.

> 
>  >
>  >
>  > > Mit freundlichen Gruessen / best regards,
>  > >
>  > >         Richard Jacob
>  > > ______________________________________________________
>  > > IBM Lab Boeblingen, Germany
>  > > Dept.8288, WebSphere Portal Server Development
>  > > WSRP Team Lead & Technical Lead
>  > > WSRP Standardization
>  > > Phone: ++49 7031 16-3469  -  Fax: ++49 7031 16-4888
>  > > Email: mailto:richard.jacob@de.ibm.com
>  > >
>  > >
>  > >
> 
>  > >              Michael Freedman
> 
>  > >              <michael.freedman
> 
>  > >              @oracle.com>
> To
>  > >                                        interfaces
> 
>  > >              09/07/2005 01:18
> <wsrp-interfaces@lists.oasis-open.o
>  > >              AM                        rg>
> 
>  > >
> cc
>  > >
> 
>  > >
> Subject
>  > >                                        [wsrp-interfaces] Transient
> 
>  > >                                        properties
> 
>  > >
> 
>  > >
> 
>  > >
> 
>  > >
> 
>  > >
> 
>  > >
> 
>  > >
>  > >
>  > >
>  > >
>  > >    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.
>  > >
>  > >
>  >
> 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]