RE: [wsia] RE: [wsrp] Sessions and Transient Entities

-----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

because the consumer may want to decide which portlets to group together in
a session. The producer would not be able to do so.

-------
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 |

>---------------------------------------------------------------------------------------------------------------------------------------------|

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

wsrp message