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
- From: Rich Thompson <richt2@us.ibm.com>
- To: OASIS WSRP TC <wsrp@lists.oasis-open.org>
- Date: Mon, 3 Apr 2006 10:26:08 -0400
Here is how I would order the various
complexities we have discussed:
- (lowest) Consumer stores, manages
and then supplies TPs on each relevant invocation => current spec
- Producer also stores TPs and
uses an update if changed algorithm to process the TPs the Consumer supplies
(i.e. manages side-effects itself).
- 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:
- The protocol could support the
Producer informing the Consumer that an optimization can be leveraged,
but not require Consumers to take advantage of it.
- The protocol could require Consumers
support this optimization.
- 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]