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

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrp-wsia message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: RE: [wsrp-wsia] Issues #6 - Is groupID required?







The justification for having initEnvironment() in the protocol is related
to initialization of shared sessions in a clustered environment. Only 2
solutions have been presented; 1) Consumer assistance with this
initialization (e.g. initEnvironment()) and 2) sophisticated enough
Producers to manage load balancing within the cluster themselves.

This has been beaten significantly and the decision to date has been to
keep an option for the Producer to request Consumer assistance. Draft v0.7
has this assistance as initEnvironment() ...



                                                                       
                      Eilon Reshef                                     
                      <eilon.reshef@webc        To:       wsrp-wsia@lists.oasis-open.org
                      ollage.com>               cc:                    
                                                Subject:  RE: [wsrp-wsia] Issues #6 - Is groupID required?
                      10/21/2002 08:36                                 
                      AM                                               
                                                                       
                                                                       



Carsten, Mike, Andre, Rich, and other participants in the groupID
discussion:

I would like to bring up a question regarding groupID and
initEnvironment. It's actually mainly regarding initEnvironment, but the
two are tied together, it seems.

Here goes--

To the best of my understanding, the purpose of initEnvironment/groupID
is to support a situation where two or more portlets need to share a
session in order to share transient data. In the F2F, this was
discouraged as a practice, but yet we would like to support it mainly
for legacy apps and for JSR168 portlets that use this practice.

It is my understanding that the scenario is that portlet A stores some
data in the session, which portlet B picks up and uses. One example
brought up was two e-mail portlets: Inbox and MessageText, which are
synchronized (the user clicks on a mail message, and the MessageText
portlet updates).

I completely understand the scenario in the "performInteraction" case.
The user clicks on a different e-mail item in the Inbox portlet, the
Inbox portlet handles the performInteraction call, stores the id of the
e-mail message in the session, and when the getMarkup call is issued,
the MessageText portlet knows which e-mail message to display.

What I fail to see is a scenario where two portlets share information
*even before* the first interaction has happened. Since portlets cannot
dictate to the Consumer the order in which they should be rendered, then
it's very hard for a portlet assume that data from the other portlet
will be available. (Transient data, that is. Persistent data is not an
issue anyway and doesn't need to go through the session.)

If indeed data sharing is applicable only after interaction, wouldn't it
be reasonable for us to assume/dictate that portlets that need to share
data would create the session upon first interaction. If that's the
practice we support, and since performInteraction happens sequentially
anyway, wouldn't that allow us to eliminate the need for initEnvironment
altogether?

Thus, the scenario would be (temporarily ignoring the unification of
entities and sessions):
- Portlets that return a new session in the a getMarkup() cannot
  rely on that session to be passed to other portlets in the same page
  (behavior is undefined).
  - This is true also when a session is being invalidated for timeout
reasons
    (Did we ever agree on the scenario there?)
- Portlets that return a new session in the performInteraction() call
may
  always rely on that session to be passed to all relevant portlets when
the
  page is rendered.

The groupID question is still open even under this scenario, namely: the
Consumer may be required to transfer the new session to all portlets
within the Producer or only to a subset of the portlets.

However, my question is whether this assumption allows us to eliminate
the initEnvironment() call?

Eilon


-----Original Message-----
From: Carsten Leue [mailto:CLEUE@de.ibm.com]
Sent: Monday, October 21, 2002 7:28 AM
To: wsrp-wsia@lists.oasis-open.org
Subject: Re: [wsrp-wsia] Issues #6 - Is groupID required?



Mike -

if I understood your proposal correctly you agree in princple with the
concept of having metadata that is telling the consumer how to group
entities but propose a different way to do it. The basic simplification
seems to be that the producer is enumerates all of its groups (i.e.
applications), so the groupID (--> environmentID) would be much more
limited in range than as if it was a GUID. What is not clear to me is
how a producer could safely tell how many applications it hosts. This
number may change when new applications are deleted or added. Whouln't
it be much simpler to have a globally unique identifer as the groupID
without exposing mutable producer internals?

Best regards
Carsten Leue

-------
Dr. Carsten Leue
Dept.8288, IBM Laboratory Böblingen , Germany
Tel.: +49-7031-16-4603, Fax: +49-7031-16-4401





             Michael Freedman

             <Michael.Freedman

             @oracle.com>
To
                                       wsrp-wsia@lists.oasis-open.org

             10/19/2002 08:11
cc
             PM


Subject
                                       Re: [wsrp-wsia] Issues #6 - Is

                                       groupID required?

















Carsten,
    This looks good, but I think we can [and should] make it a little
simpler.  Basically, as groupID is no longer carried over the wire we
need not concern ourselves with arbitrary group names.  I suggest we do
the
following:
    1) We change the doInitEnvironment field in ServiceDescription to
something like numInitEnvironments. numInitEnvironment would be an int.
A value of 0 would mean initEnvironment should not be called.  A number
> 0 indicates how many initEnvironments the producer requires.
    2) We change the groupID field in EntityDescription to something
like environmentID. environmentID would be an int.  Its value would be
between 1 and numInitEnvironment inclusive.  If numInitEnvironment is 0
or 1 the environmentID field is ignored by the consumer.  [When
numInitEnvironment is 0 this field can be ignored because there are no
environments. When numInitEnvironment is 1 this field can be ignored
because all entities are in the 1 enviornment.] If > 1, environmentID
indicates the environmental context that should be used when interacting
with this entity.  Values outside the range [or missing] signify invalid
entity descriptions. Consumers must not activate/use such entities.


This simplification makes consumer management/lookup simpler and more
efficient and seemingly loses nothing on the producer side.
     -Mike-


Carsten Leue wrote:
      Hi all.


      As discussed on Thurday's call here is a writeup of the proposal
we
      discussed.


      procedure:
      1. the producer tells via metadata what entities belong to an
      application.
      The producer assigns an ID (or name) for each such group. This
name
      should
      ideally be globally unique.
      2. the consumer MUST respect the metadata grouping information. It
      MUST
      call initEnvironment for each user session prior to making a call
to
      any
      entity that belongs to a group.
      3. it would not be required to transfer the grouping-metadata at
all
      across
      the wire, so we could remove groupID (see the disadvantages
section)
      4. the consumer must respect cookies and headers in the HTTP case


      advantages:
      - no explicit groupID mechanism that pollutes the protocol
      - compliance with JSR168


      disadvantes:
      - we lose our per-instance grouping concept
      - functionality depends on metadata-awareness


      comments:
      to 1: in the JSR168 case the producer will choose the application
ID
      as the
      groupID
      to 2: calling initEnvironment on a per-group basis provides a
simple
      (yet
      protocol dependent) mechanism for the producer to support multiple
      JSR 168
      applications. As each application requires an HTTP session and the
      JSR168
      producer respects (1), the call to initEnvironment establishes
such
      an HTTP
      session. Together with (4), ensuring that the session will be
kept,
      the
      producer can reuse this session between the consumer and the
producer

      directly as the HTTP session required by the JSR. No
      re-implementation of
      session management on the producer would be required.
      to 3: after the session has been established the groupID does not
to
      travel
      over the wire as the HTTP together with the entityHandle implies
the
      appropriate grouping on the producer. This implies that the
consumer
      side
      grouping equals exactly the producer side grouping. (1),(2) and
(4)
      ensure
      that.


      Comments?


      Best regards
      Carsten Leue


      -------
      Dr. Carsten Leue
      Dept.8288, IBM Laboratory Böblingen , Germany
      Tel.: +49-7031-16-4603, Fax: +49-7031-16-4401


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





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


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