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

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

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