[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]