[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsrp] Scoping of Transient Properties - Mapping to JSR286
I agree that this probably would be more efficient however I think there
are some question/problems with this approach.
- In WSRP we have no real notion of the "application" scope, besides the
famous group id which allows us to fake such a notion only via HTTP
sessions. WSRP sessions have no support/tie here.
- we are currently addressessing each portlet seperatly (single request per
portlet), I think it could work if we had bulk operations, i.e. gM() for
all portlets in a group.
The implicit tie of two request is quite problematic in my opinion, both
conceptual and implementation wise. Debugging could become a horror.
You send message1 to portlet1 sending the "shared transient properties" and
in message2 for portlet2 you rely on the contents of message1.
What about parallel access to both portlets? What about routing
(anticipating we will have it at some point in time)? There is no ordering
guarantee in the network.
Or would message1 then need to be blocking?
- On the caching side: wouldn't this mean that the producer would need to
tie its session life time / cache life time to that of the user session on
the consumer? What would be the indicator to the Consumer to resend the
data? I guess in this case we would need the group session scope to be able
to indicate this (which was denied to be in 1.0 :-) ).
Mit freundlichen Gruessen / best regards,
Richard Jacob
______________________________________________________
IBM Lab Boeblingen, Germany
Dept.8288, WebSphere Portal Server Development
WSRP Technical Lead
WSRP Standardization
Phone: ++49 7031 16-3469 - Fax: ++49 7031 16-4888
Email: mailto:richard.jacob@de.ibm.com
Stefan Hepper
<sthepper@hursley
.ibm.com> To
OASIS WSRP TC
03/31/06 10:18 AM <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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]