MHonArc v2.5.2 -->
wsia message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
Subject: RE: [wsia] RE: [wsrp] Sessions and Transient Entities
Title: RE: [wsia] RE: [wsrp] Sessions and Transient
Entities
Excuse me for saying in advance that what follows is just my best
understanding at present, and represents my opinion, not a statement
of consensus even if it sounds like that's what I'm saying. It is just
easier for me to make statements than to hem and haw around a point in
order to find a very politically correct and inoffensive way to phrase
things.
I thought that consumers asked for sessions from producers who
provide portlets/entities, and it is the producer who gives a session
a sessionID. As of now we have only defined a session to the extent
that it is specific to a single producer to a single consumer to a
single end-user. We haven't successfully approached consensus other
than that AFAIK.
We have not yet adopted or reached consensus on how more than one
producer's portlets can be included in some concept of a shared
session. However...
A consumer can have as many portlets from as many producers as
needed for an individual end-user and how it manages that operation is
up to the consumer. I don't understand what the spec can do to make
that easier or more manageable. In the case of a number of
producers in sequence the problem would get worse with each
producer-consumer pairing.
Portlets from different producers don't need to know about each
other unless we burden the specification with a process for doing so.
That it would make some combinations of specific pairings easier to
manage for some consumers is without doubt, but we need to weigh the
cost to all.
Portlets from a single producer MAY know about each other at the
discretion of the producer. The consumer MAY ask to know if portlets
from a single producer have knowledge of each other in a session those
portlets share from that producer, and it is up to the producer to
allow the consumer to know whether those portlets share their state
information within that kind of shared session. IMO portlets from
different producers SHOULD NOT be required to share sessions.
Where 90 percent of the confusion over this issue has arisen is
from the notion that a consumer creates a session, which we have held
all along was a function of the producer because the producer has to
manage its sessions and entities in order to return the correct
portlet/entity to each consumer's requests and so gives it the
sessionID for that purpose. The need for a consumer to have the
ability through the specification to create a named session that
combines portlets from more than one producer is the real sticking
point, no matter how many ways you find to say it in different
words.
I suspect my position on that is apparent. However, as always, I
will go along with the consensus.
Ciao,
Rex
At 3:05 PM -0400 6/18/02, Eilon Reshef wrote:
Can you elaborate on why you believe it is useful for
the portlets not to know who they are sharing the state
with?
-----Original Message-----
From: Carsten Leue [mailto:CLEUE@de.ibm.com]
Sent: Tuesday, June 18, 2002 2:20 PM
To: Eilon Reshef
Cc: 'Michael Freedman'; wsia@lists.oasis-open.org;
wsrp@lists.oasis-open.org
Subject: RE: [wsia] RE: [wsrp] Sessions and Transient
Entities
Of course the portlets need to be
prepared. But the portlet would not know
with what other portlet is should share the session.
Only the consumer
knows this..
Best regards
Carsten Leue
-------
Dr. Carsten Leue
Dept.8288, IBM Laboratory B�blingen ,
Germany
Tel.: +49-7031-16-4603, Fax:
+49-7031-16-4401
|---------+----------------------------->
|
| Eilon
Reshef |
|
|
<eilon.reshef@webc|
|
|
ollage.com> |
|
| |
|
|
06/18/2002 06:36 |
|
|
AM |
|
| Please
respond to |
|
| Eilon
Reshef |
|
| |
|---------+----------------------------->
>---------------------------------------------------------------------------------------------------------------------------------------------|
| |
|
To: Carsten
Leue/Germany/IBM@IBMDE
|
|
cc: "'Michael Freedman'"
<Michael.Freedman@oracle.com>, wsia@lists.oasis-open.org,
wsrp@lists.oasis-open.org
|
|
Subject: RE: [wsia] RE: [wsrp] Sessions and Transient
Entities |
| |
| |
>---------------------------------------------------------------------------------------------------------------------------------------------|
Can you please elaborate on this - what
would be a working scenario where a
Consumer decides to group portlets without the
portlets pre-programmed to
be shareable?
-----Original
Message-----
From: Carsten Leue
[mailto:CLEUE@de.ibm.com]
Sent: Monday, June 17,
2002 12:21 PM
To: Eilon
Reshef
Cc: 'Michael Freedman';
wsia@lists.oasis-open.org;
wsrp@lists.oasis-open.org
Subject: Re: [wsia] RE:
[wsrp] Sessions and Transient Entities
Eilon
-
because the
consumer may want to decide which portlets to group
together in
a session. The producer
would not be able to do so.
Best
regards
Carsten Leue
-------
Dr. Carsten
Leue
Dept.8288, IBM
Laboratory B�blingen , Germany
Tel.: +49-7031-16-4603,
Fax: +49-7031-16-4401
|---------+----------------------------->
|
| Eilon
Reshef |
|
|
<eilon.reshef@webc|
|
|
ollage.com> |
|
| |
|
|
06/12/2002 02:49 |
|
|
AM |
|
| Please
respond to |
|
| Eilon
Reshef |
|
| |
|---------+----------------------------->
>
---------------------------------------------------------------------------------------------------------------------------------------------|
|
|
|
To: "'Michael
Freedman'"
<Michael.Freedman@oracle.com>,
wsia@lists.oasis-open.org,
wsrp@lists.oasis-open.org
|
| cc:
|
| Subject: [wsia] RE: [wsrp]
Sessions and Transient Entities
|
|
|
|
|
>
---------------------------------------------------------------------------------------------------------------------------------------------|
If a simple
group-id within the portlet UI takes care of the issue
(which I
agree with), why bother
to allow the Consumer to create and manage
sessions
explicitly (versus
implicit creation by the Producer)?
-----Original Message-----
From: Michael Freedman
[mailto:Michael.Freedman@oracle.com]
Sent: Tuesday, June 11,
2002 7:43 PM
To:
wsia@lists.oasis-open.org; wsrp@lists.oasis-open.org
Subject: Re: [wsrp]
Sessions and Transient Entities
Eilon,
I think your suggestion intermixes 2 different
concepts --
that of
session identity and that of instance/entity identity.
My
scenario 1
concerns itself with how an instance/entity id can be used
to
segment
data within a session. My scenario 2 concerns itself with
how
distinct sessions can be established/maintained. I
suggested
we
don't define a way for the producer to describe its
grouping
rules.
Rather a consumer can choose to support grouping (via a
mechanism
its
free to define) or leave it up to the consumer to handle
internally
(via perference/configuration data). So in my scenario 2,
a
consumer
isn't responsible for separating the portlets into
different
sessions. It merely is allowed to do so. Portlets must
assume
they
aren't running in such environments -- rather they must
assume
they
run in a shared session world -- hence they need an ID to
do
the
proper namespacing. As the consumer doesn't know this
grouping
(because it doesn't implement grouping) the producer must
provide its
own UI for getting these keys -- i.e. the producer must
provide
a
configuration/personalization UI that allows a group key to
be
specified for each of its portlets -- it can then use this
"internal"
group id to key/separate data in the shared session.
Just a long way of saying -- I don't buy your scenario 2.
If
the
consumer knows the grouping, I would rather the consumer
maintain 2
discrete sessions as this allows it to continue to pass the
entity id
so
each entity can maintain entity specific data if necessary
(i.e.
portlet A, B, B' in the same session/group -- B and B' can
keep
their
data separate). If the consumer doesn't know the grouping
then
it
controls things just like scenario 1. The producer is free
to
define/manage finer granularity as described above.
-Mike-
Eilon Reshef wrote:
Mike,Per your
recent e-mails, I think that the approach
makes
sense.The only thing that
concerns me is that we have two
different mechanisms to
handle what would seem to be a
very
similar scenario.Scenario
1: If there are two occurrences
of a
single portlet on a page,
then as you described it the
portlet
is responsible for
segregating the occurrence-specific
information, using an
additional key provided by the
portal.Scenario 2: If
there are two occurrences of a pair
of
portlets, then suddenly
the portal is responsible for
segregating the two pairs
by placing them in two separate
sessions.(All, of course,
assuming that the portlets use
sessions)The idea of the
Consumer creating and managing
the
segregation keys has the
scalability advantage that you
mentioned.Can't we use it
to handle both
scenarios?Namely:In
scenario 1, where there's
portlets A1 and A2, then the
portal
sends a key "1"
when displaying A1 and a key "2" when
displaying A2. In
scenario 2, when there's portlet pairs
<A1,
B1> and <A2,
B2>, then the portal sends a key "1" when
displaying A1 and B1 and
the key "2" when displaying A2
and
B2.This would allow the
Producer to create and manage the
session id (and maybe
even create them only when needed,
instead of explicitly
creating them up-front as the
current
draft suggests). The
Consumer only has to take into
account
that it may receive (and
needs to re-send) a separate
session
id for each one of the
keys.Eilon
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
Powered by eList eXpress LLC