[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [wsia] [wsrp-interfaces] Another case for explicit session creation?
We do have to be careful about violating the current design also. This essentially changes the session concept away from the current private session to a shared session. The discussions on the telecons have settled for providing an initEnvironment() type of operation that would allow any such shared session initilization. One thought being explored is whether having this as a separate portType would be a very clean way for a Producer to indicate whether such an invocation is useful. Alan Kropp <akropp@epicentri To: "'wsia@lists.oasis-open.org '" <wsia@lists.oasis-open.org>, c.com> "'wsrp-interfaces@lists.oasis-open.org '" <wsrp-interfaces@lists.oasis-open.org> 08/07/2002 12:06 cc: PM Subject: [wsia] [wsrp-interfaces] Another case for explicit session creati on? Not sure this went through the first time.. -----Original Message----- From: Alan Kropp Sent: Tuesday, August 06, 2002 11:49 PM To: 'wsia@lists.oasis-open.org '; 'wsrp-interfaces@lists.oasis-open.org ' Subject: [wsia] [wsrp-interfaces] Another case for explicit session creation? I'd like to open another thread for the explicit session creation question. In the standard portal situation, end users configure their own aggregate views or "pages" of the available portlet services. When an end user first accesses their customized page, the portal needs to ask each of the portlets on the page to render their markup, assembles the page, and then presents it to the user. Consider for the sake of argument that a theoretical page is composed of five portlets, all of them remote portlets served by a single Producer. The portal has already created and configured the necessary entities. In the portal startup case, the portal will send five individual requests to this Producer, each of them targetted at a different entity. As there are no sessions in effect yet, the Producer in turn creates a session for each entity, and passes back the handle in the individual getMarkup response. It would be more efficient for the portal, however, if there was just one session created by the Producer, grouping all of the entities into a single session. Otherwise, the portal must now map the end user's request scope, which in the standard http case is a single http session, to multiple Producer sessions, and it must be certain to put the correct session ID into the performInteraction/getMarkup for each entity. The portal could explicitly request a Producer session ahead of any calls to getMarkup, and pass this sessionID to getMarkup for all of that Producer's entities. ---------------------------------------------------------------- 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