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

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrp message

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


Subject: Re: [wsrp] Scoping of Transient Properties - Mapping to JSR286



Here is how I would order the various complexities we have discussed:
  1. (lowest) Consumer stores, manages and then supplies TPs on each relevant invocation => current spec
  2. Producer also stores TPs and uses an update if changed algorithm to process the TPs the Consumer supplies (i.e. manages side-effects itself).
  3. Producer informs Consumer that it also maintains TPs and the Consumer maintains 'dirty' bits to determine what to send on the next invocation.

#1 has the largest message size. #2 has the same message size as the protocol is not leveraging the fact that the Producer is also maintaining a TP store. #3 has the smallest message size, but increases the work that the Consumer must do both when processing a new TP value and when building the message for the Portlet.

I carefully crafted #3 to leave open an orthogonal issue regarding this optimization; namely:
  1. The protocol could support the Producer informing the Consumer that an optimization can be leveraged, but not require Consumers to take advantage of it.
  2. The protocol could require Consumers support this optimization.
  3. The protocol could require Consumers and Producers support this optimization.

My preference between these options is to require #1 and provide metadata  and conformance statements (fault processing, etc) relative to 3A (I suspect people could easily convince me to make this 3B ... ). This choice maintains the line we normally draw of having the protocol support optimizations without requiring either party implement the complexities associated with the optimization, though I would note our larger tendency is to not require such optimizations of Producers.

The metadata, faults and conformance statements I see 3A requiring include:
- boolean in ServiceDescription saying the Producer supports 3A
- require the Consumer to send wsrp:consumerSessionScopeInitialized to Producers with the boolean set to 'true'
- require reinitialization after a InvalidSession fault (i.e. resend the init event and resend all TPs)

Before hitting send, I am also noting an issue that would need to be resolved. The current model does not require the Consumer to place all Portlets from a Producer within the same group for the sharing of TPs. Wouldn't we need some way to communicate the group membership to the Producer in order for the optimization of 3A to not fundamentally alter the user experience the Consumer seeks to provide? Note: this could become the payload of the wsrp:consumerSessionScopeInitialized event.

Rich


Subbu Allamaraju <subbu@bea.com>

03/31/06 01:38 PM

To
OASIS WSRP TC <wsrp@lists.oasis-open.org>
cc
Subject
Re: [wsrp] Scoping of Transient Properties - Mapping to JSR286





Rich Thompson wrote:
>
> We had talked about transient properties changing into an interface
> style (like navParams) rather than the current storage style. The
> problem one runs into is that not all Portlets are interacted with in
> every user request lifecycle and so the Consumer would have to implement
> a means of remembering to which Producer it already sent a particular
> new value. Another option would be to move transientProperties into

I don't see why this any less complex from dealing with init cookies and
sending URL templates or user properties (and throw in some faults to
make life more interesting for consumer developers). When a producer
requires perGroup cookies, consumer will have to remember to map a group
of portlets to a producer and manage cookies accordingly.

Complexity-wise, it is same with producer scoped state. In fact, it
would be cheaper for the consumer to managing this scoping since it will
have less number of producers to check against.

> MarkupParams such that they participate in any cache key. That would
> handle the case of portlets being rendered on the current page, but
> would also decrease the value of fragment caching (and miss use cases
> related to portlets not on the current page).
>
> I think these were the core reasons that drove us toward making
> transient properties state oriented rather than interface oriented.
> (btw: I noticed on my pass trying to reasonably normalize navParams and
> transProps that the decision to change navParams into an interface style
> wasn't well-reflected through cd01 ... I am making those changes for
> wd15.) It seems to me that the potential reduction in transmitted data
> isn't worth the added Consumer complexity. While I don't think it would
> be horrible to require Producers to cache received transient properties,
> I guess I'm not seeing a good value/cost trade-off driving us in that
> direction.

I'm not so sure about the trade off between performance and complexity.
To me, the complexity issues can be resolved much easier than the
performance issues. Once users start using a protocol, tuning would be
much harder. There is no scope for tuning in this case.

Subbu

>
> Rich
>
>
> *Stefan Hepper <sthepper@hursley.ibm.com>*
>
> 03/31/06 03:18 AM
>
>                  
> To
>                  OASIS WSRP TC <wsrp@lists.oasis-open.org>
> cc
>                  
> Subject
>                  Re: [wsrp] Scoping of Transient Properties - Mapping to JSR286
>
>
>                  
>
>
>
>
>
> But wouldn't it be more efficient in any case (independent from the
> producer implementation) to define these properties as shared at
> producer level and only send the changes in each request instead of
> sending all properties that a portlet has described to in each request?
>
> Or, as another alternative, can we modify the current spec so that the
> consumer is allowed to only send changed values and the producer needs
> to cache the values)?
>
> Stefan
>
> Rich Thompson wrote:
>  >
>  > While I am sympathetic to the use case where several Portlets at a
>  > single Producer tend to use session properties to share state with each
>  > other and that this shared state could form a convenient means of
>  > indicating interesting transient properties, I think it is stretching
>  > too far to say such properties are shared across all Portlets hosted by
>  > that Producer. The stateful items that are being shared really are
>  > portlet-specific.
>  >
>  > As to whether this causes a problem for a Producer who is mapping these
>  > into shared state and potentially receiving two inputs declaring the
>  > same value with a potential negative side effect of firing listeners
>  > multiple times for what is really a single state change, I would
>  > encourage Producers with such an issue to look at their copy of the
>  > stateful item (i.e. keep a copy locally and manage the missing => null
>  > semantics within the handler for transient properties) and do a value
>  > comparison before setting the value. This avoids the 'local' issue
>  > related to how the Producer is mapping transient properties without
>  > percolating that issue outside of the Producer.
>  >
>  > BTW: I think you provide good reasons why JSR286 should choose to map
>  > transient properties to shared session attributes, I just don't see why
>  > that local architectural decision needs to impact the external WSRP
>  > protocol.
>  >
>  > Rich
>  >
>  >
>  > *Subbu Allamaraju <subbu@bea.com>*
>  >
>  > 03/30/06 12:58 PM
>  >
>  >                  
>  > To
>  >                  OASIS WSRP TC <wsrp@lists.oasis-open.org>
>  > cc
>  >                  
>  > Subject
>  >                  [wsrp] Scoping of Transient Properties - Mapping to
> JSR286
>  >
>  >
>  >                  
>  >
>  >
>  >
>  >
>  >
>  > Based on the discussions we had in the JSR286 EG, I was asked to raise
>  > this topic. Stefan - please step in if you find any items I missed. Mike
>  >
>  > The basic question is what is the natural scoping for specifying these
>  > properties - in the PortletDescription or the ServiceDescription?
>  >
>  > Since most web development platforms provide some notion of sessions, we
>  > (the EG) find it natural to manage session-scoped transient properties
>  > via a native session that is already available to web apps. For example,
>  >  in a J2EE web app, a session-scoped transient property can be mapped
>  > to an attribute in the HttpSession (or the PortletSession). There are
>  > two advantages to such a mapping:
>  >
>  > - Portlet developers are used to using session attributes. To make a
>  > change to an attribute shared across portlets, the developer/deployer
>  > could simply mark that a given session attribute should be made
>  > available to other portlets via a remote protocol such as WSRP.
>  >
>  > - Secondly, this also allows legacy apps or apps built using other web
>  > programming models to rely on session attributes transparently. Those
>  > apps don't have to use special new APIs to take advantage of transient
>  > properties.
>  >
>  > However, such a mapping of session-scoped transient properties to native
>  > session attributes on web containers would bring in one potential
> problem.
>  >
>  > In WSRP, session scoped transient properties are defined on each
>  > portlet, where as sessions are globally accessible to all components in
>  > a web app. That is multiple portlets deployed on a given producer can
>  > share the same session, and hence a portlet-level specification of these
>  > properties does not make sense for web developers.
>  >
>  > To take an example, portlets deployed on a producer may be interested in
>  > sharing two session attributes TP1 and TP2 with other portlets deployed
>  > on other producers. Accordingly, the producer will expose TP1 and TP2 as
>  > transient properties required for *each* portlet deployed on that
> producer.
>  >
>  > When a consumer has a value for one of these properties, it will then
>  > send the same property to each portlet on the producer. In most cases,
>  > this is duplication of traffic, and takes extra effort for both the
>  > consumer and producer. Producers running on J2EE web containers will
>  > also have to worry about session attribute listeners, clustering etc,
>  > since changes to attributes will typically involving invoking these
>  > listeners, and replicating the attribute to other nodes in a cluster.
>  >
>  > (I'm speaking here from J2EE's point of view, and it would be
>  > interesting to see what is natural from .NET side. Mike - any comments?)
>  >
>  > Given this, my question is whether specifying transient properties makes
>  > sense at the portlet level? It seems more natural to specify these in
>  > the ServiceDescription instead, and treat those like other data stored
>  > in the session (e.g. URL templates, or user profiles).
>  >
>  > Regards,
>  >
>  > Subbu
>  >
>  > ---------------------------------------------------------------------
>  > 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
>  >
>  >
>  > --------------------------------------------------------------------- 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
>
>
>
> ---------------------------------------------------------------------
> 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
>
>
> --------------------------------------------------------------------- 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


---------------------------------------------------------------------
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




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