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

[Subbu Allamaraju <subbu@bea.com>]

I would look at this differently, and disagree that the wire-level 
format is the absolute. The current wire-level format is not natural for 
run-time mappings on the producer. Isn't the wire-level format there to 
help solve problems that occur in the runtime on producers and consumers?

For this feature, I agree about the producer side optimizations, but the 
runtime and consumers still pay a price.

The more I think about this, the more I see this feature designed for 
producer applications and not producer containers. Today, the most 
common producer implementation is a container, and we have to help make 
it easy for containers.

Subbu


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