OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

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