[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [wsrp-wsia] Issues #6 - Is groupID required?
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>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC