[wsia] The search for per-entity-per-user Consumer state

Michael,
Your inclination 
towards the "web approach" is largely based on scalability reasons - i.e. try to 
reduce the amount of information the Consumer has to store per all entities per 
all users. To that effect, let me try and continue to search for reasons why a 
Consumer will _have_ to have information per-entity-per-user.

In the 
discussion in the joint interfaces meeting yesterday, I suggested that the 
Consumer would have to store (per-entity-per-user) whether to call performAction 
or getFragment. You, rightly so, told me that you never liked the distinction so 
that this is (not yet) a valid argument.

 

To tell 
you the truth, I'm not sure *I* like the distinction between performAction and 
getFragment. It may be that we will have *only* performAction, where the action 
should be _exactly_ the "URL state" you mentioned in your point (a) 
below.

Well, in this case, if the consumer has multiple portlets on the 
page, it _must_ store the "last" action of all of them, and this _must_ be 
per-user. To contrast with the web approach, in the simple Web application, the 
browser stores the application's state in the address bar per-user. In the 
WSRP/WSIA scenario, the Consumer must also store that information, per-portlet! 
This is the only way to allow stateless portlets.

Am I missing 
something?
Gil

-----Original Message-----
From: Michael 
Freedman [mailto:]
Sent: Wednesday, June 12, 2002 00:19
To: 
; 
Subject: Re: [wsia] 
Follow-on Example

Eilon,
   Oracle's approach/point of 
view (on the web approach) is as follows:
    a) we strongly 
discourage portlets from maintaining any kind of
transient state.  We 
have found that even with moderate sized user
communities, stateless portlets 
lead to significantly improved portal
response times.  So our preferred 
solution for your reservation scenario is
(0):  there is neither a 
session nor a transient entity.  The reservation
state is maintained by 
encoding the information in URLs inserted into the
generate response 
content.  I.e. only use sessions when state must be shared
between 
entities.
    b) recognizing that sessions will be used 
however, the base scenario
should be one in which the two reservation 
portlets cooperatively run in the
same session.  In this scenario the 
two portlets would be responsible for
namespacing encoding their session data 
to avoid collisions.  This is
analogous to the (servlet) web model 
though obviously a more insidious
situation as servlets often (safely) assume 
only one "instance" runs in a
session.  All we would need to do to 
support this would be ensure that a
portlet is able to determine and use a 
"key" that distinguishes one use (on
a page) from another.  If this 
key/id were generated by the consumer, the
consumer could easily choose an 
algorithm for generating such an id that is
repeatable without maintaining 
any dynamic (state) information.  Hence the
ID would have little/no 
cost.

   For us/me the above completely covers Approach 1: the 
web approach.  It
allows multiple entities of the same type to run in a 
session with entity
private session data while still allowing these same 
entities to share
session data between themselves of entities of other 
types.

The outstanding question is whether we consider the situation 
where a
portlet only has entity private data so common that we should allow 
for them
to be so declared and mandate the consumer honor such a 
declaration?
Personally, I think this is reasonable.  Not having to 
partition (namespace)
the session would be useful to such developers.  
And I think this occurs
commonly enough for us to represent 
formally.

Another scenario to consider is one where a set of entities 
want to share a
session distinguished from another set running in the same 
consumer.  This
is a situation where a service provides 2 portlets 
designed to work
together.  For example a news feed display portlet and 
a topic portlet.  If
2 sets of these run is the same page how is one 
set's session data isolated
from the other?  My answer is that the 
consumer merely chooses to establish
2 sessions (vs. one) and passes the 
correct session ID to each set.  I
further believe we shouldn't define 
how a consumer chooses/learns to do
this.  I.e. I don't think we should 
define producer meta data that describes
potential groupings for its 
sessions.  Rather, portlets must expect that the
consumer will 
potentially run all of these entities in the same session and
behave 
accordingly.  In many circumstances this may mean that the sets
trounce 
each others shared data.  However, well coded portlets could choose
to 
represent this demarcation in its own settable configuration data for 
the
portlets.  I.e. the config screen could have a setting for group id 
allowing
the page developer to set a common group id for the 2 portlets in 
each set.
      
-Mike-

----------------------------------------------------------------
To 
subscribe or unsubscribe from this elist use the subscription
manager: 
<http://lists.oasis-open.org/ob/adm.pl>