[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [wsrp-wsia] Issues #6 - Is groupID required?
I guess I am missing something. I don't understand how an entityHandle gives the necessary information for a producer to handle initialization issues. How does a producer distinguish between 2 different users accessing the same entity? I thought the original groupId [passed to performInteraction/getmarkup] allowed the consumer to express which [concurrent] invocations where in its concept of a session. If we want to support this type of initialization don't we still need this? As for passing groupID to initEnviroment() I really prefer we don't do this. Unlike initilaization grouping, this type of grouping is clearly not needed in our specification -- it is being added as a convenience and we would be served much better by not exposing it in the protocol. In particular I want nothing to do with groupID when all the entities of a producer are in the same logical group. -Mike- Rich Thompson wrote: > My understanding (reflected in v0.8 :}) is that groupID is not sent on > getMarkup/performInteraction invocations at all. For Producers using > initEnvironment, it has already been used there. For those handling the > initialization issues themselves, the necessary information is available > through the entityHandle reference. > > I have kept groupID on the initEnvironment invocation for v0.8 (though > required it to be one the Producer specified) as this keeps the semantics > of the invocation clearer and reduces the sophistication required of the > Producer. > > > Michael Freedman > <Michael.Freedman@ To: wsrp-wsia@lists.oasis-open.org > oracle.com> cc: > Subject: Re: [wsrp-wsia] Issues #6 - Is groupID required? > 10/23/2002 01:07 > PM > > > > Andre, you completely lost me. My understanding is that initEnvironment > doesn't > pass or return a groupID. Its also my understanding that the groupID sent > to > getMarkup/performInteraction is not the same groupID that is being proposed > to > be included in the meta data, rather it is a consumer generated ID used > when > initEnvironment() is not used. > > Eilon, no the initEnvironment() wouldn't have to be called as frequently > as > you suggest. I expect most JSR 168 containers to do an initial check to > see if > the passed session is still valid before communicating to a portlet. If > its > invalid, it throws the defined exception which causes the consumer to > recall > initEnvironment() and thus reestablishing the session before retrying. > -Mike- > > Andre Kramer wrote: > > > The assumption is that something on the producer detects that the http > > session expired (and has possibly been recreated automatically), throwing > a > > soap fault to signal that a (new) call to iniEnvironment() is required [I > > also prefer to name it initGroup()]. Now, I would still say that > including > > the groupID, that initXXX returns, on each performInteraction() or > > getMarkup() call help with exactly this kind of session expiry detection. > > [initGroup() puts the groupID in the session object. performInteraction() > > and getMarkup() check that the session contains the right group id. So > the > > 'redundancy' can help detect expired sessions and consumer problems in > > following transport cookie requirements.] > > > > regards, > > Andre > > > > -----Original Message----- > > From: Eilon Reshef [mailto:eilon.reshef@webcollage.com] > > Sent: 22 October 2002 22:01 > > To: wsrp-wsia@lists.oasis-open.org > > Subject: RE: [wsrp-wsia] Issues #6 - Is groupID required? > > > > Mike, > > > > Thanks for the elaborate explanation. > > > > Wouldn't this also imply that the Consumer needs to call initEnvironment > > on every page, to handle cases where the session expires? I.e., a JSR168 > > Producer will renew the session automatically, and this also needs to be > > serialized? > > > > Eilon > > > > -----Original Message----- > > From: Michael Freedman [mailto:Michael.Freedman@oracle.com] > > Sent: Tuesday, October 22, 2002 3:35 PM > > To: wsrp-wsia@lists.oasis-open.org > > Subject: Re: [wsrp-wsia] Issues #6 - Is groupID required? > > > > Eilon, > > I also remember that at the F2F we decided to discourage the > > practice of using shared data. In doing so we decided that an ID > > corresponding to a shared session wouldn't be defined/carried in our > > protocol. Instead, I recall we said that portlets needing to do such a > > thing wouldn't have to attach/encode the shared session ID in the entity > > session ID. To deal with concurrency issues [calls handled concurrently > > from different users and calls handled concurrently for the same user], > > groupID was added to the getMarkup/performInteraction calls. Used here, > > groupID is consumer defined name for the potential shared session. > > After the F2F, we learned that the above mechanism wouldn't support > > JSR 168. There were two problems: a) In the JSR 168 world shared > > sessions are encoded in an http cookie. b) There was no convenient, > > safe way to create such a cookie in a concurrent, load balanced > > environment. > > My understanding is that when we added initEnvironment() we didn't > > [intend to] remove the "encode shared sessions in an entity session > > mechanism". The .7 Draft still passed this consumer generated ID to > > getMarkup, etc. What seems to have been under discussion here is > > whether the groupId that was passed to initEnvironment() was needed. As > > initEnvironment() itself signified a group it appeared we could remove > > it. However, Carsten then came up with a usage that though not required > > would make implementing a producer [in the usage scenario] easier. > > Namely have a producer meta-data defined groupId that allows the > > consumer to understand and manage the fact that this producer requires > > more than 1 > > initEnvironment() [per user]. So in the end there are two concepts of > > groupId in our spec [if we adopt Carsten's proposal]. The groupID in > > meta data that controls the number of times initEnvironment is called > > for a given user and the groupID that is sent to > > getMarkup/performInteraction that defines a shared session context. > > This later is still a consumer generated ID though if we add the former > > we will likely constrain its semantics. I.e. the consumer groupID can't > > cross producer groupID boundaries. > > > > As for your suggestion about removing initEnvironment and restricting > > the semantics of sharing so that sharing can't begin until a > > performInteraction is called -- this unfortunately won't work for JSR > > 168. JSR 168 allows the shared session to come into existence at any > > time -- hence why we invented initEnvironment(). We could however > > consider your suggestion for our "official" shared session mechanism -- > > i.e. only pass the consumer groupID to performInteraction -- and > > mandating that if shared sessions are to be used they can/must only be > > started in a performInteraction. > > -Mike- > > > > Eilon Reshef wrote: > > > > > 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> > > > > ---------------------------------------------------------------- > > 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> > > ---------------------------------------------------------------- > 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