MHonArc v2.5.2 -->
wsia message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
Subject: RE: [wsia] The search for per-entity-per-user Consumer state
Gil - I think I missed your point.
May new attempt to answer the question: the client needs to store one
handle per entity per user (or to be more precise: a handle for each entity
users display on their pages).
Best regards
Carsten Leue
-------
Dr. Carsten Leue
Dept.8288, IBM Laboratory B�blingen , Germany
Tel.: +49-7031-16-4603, Fax: +49-7031-16-4401
|---------+---------------------------->
| | Gil Tayar |
| | <Gil.Tayar@webcol|
| | lage.com> |
| | |
| | 06/18/2002 05:40 |
| | AM |
| | Please respond to|
| | Gil Tayar |
| | |
|---------+---------------------------->
>---------------------------------------------------------------------------------------------------------------------------------------------|
| |
| To: Carsten Leue/Germany/IBM@IBMDE |
| cc: wsia@lists.oasis-open.org, wsrp@lists.oasis-open.org, "'Michael.Freedman@oracle.com'" <Michael.Freedman@oracle.com> |
| Subject: RE: [wsia] The search for per-entity-per-user Consumer state |
| |
| |
>---------------------------------------------------------------------------------------------------------------------------------------------|
Carsten,
Either I misunderstood your answer, or you may have missed the fact that I
was searching for _Consumer_ (not Producer) information that must be stored
per-entity-per-user.
Mike's concern about the OO-way of thinking - in which the basis is a
per-entity-per-user references - is that the Consumer will have too many of
these references.
What I was trying to say in this email is that the Consumer _must_ have
information that is per-entity-per-user _anyway_: because of the way
actions
work, and for stateless producer services, the Consumer must at least store
the last action of the producer service.
Gil
-----Original Message-----
From: Carsten Leue [mailto:CLEUE@de.ibm.com]
Sent: Mon, June 17, 2002 19:33
To: Gil Tayar
Cc: wsia@lists.oasis-open.org; wsrp@lists.oasis-open.org
Subject: Re: [wsia] The search for per-entity-per-user Consumer state
Gil - wouldn't a portlet that displays the user's prefered stock price be
an example. There you have per-entity (stock portlet) per user (stock
symbol) state.
Best regards
Carsten Leue
-------
Dr. Carsten Leue
Dept.8288, IBM Laboratory B�blingen , Germany
Tel.: +49-7031-16-4603, Fax: +49-7031-16-4401
|---------+---------------------------->
| | Gil Tayar |
| | <Gil.Tayar@webcol|
| | lage.com> |
| | |
| | 06/12/2002 12:16 |
| | PM |
| | Please respond to|
| | Gil Tayar |
| | |
|---------+---------------------------->
>
---------------------------------------------------------------------------
------------------------------------------------------------------|
|
|
| To: wsia@lists.oasis-open.org, wsrp@lists.oasis-open.org
|
| cc:
|
| Subject: [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: wsia@lists.oasis-open.org; wsrp@lists.oasis-open.org
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>
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
Powered by eList eXpress LLC