[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [wsia] [wsrp-interfaces] Another case for explicit session cr eation?
My reply to Alan seems to have been bounced (as I'm not on wsai). Basically, this Portal use case may argue for separating the http session management from the WSRP level session? Rely to Alan: ----------------------------------------------------------------- I do think this is a use case that is worth more consideration. On high latency networks, an extra round trip to establish a session, however, seems a high cost. Instead, the Portal consumer should normally use only one http 1.1 connection until it receives a session from the producer (i.e. it can send multiple getMarkup requests back-to-back on one SOAP client). A session is established once the consumer receives a session identifier (cookie) in the first reply. Once such a http session is established, the consumer can freely use multiple http 1.1. connections (but needs to include the right http session identifier / cookie on each http request). Having a "batch" request mode, allowing multiple "getMarkup" requests in one SOAP request would help force the consumer to do the above but, as previously discussed, is not really needed? The number of request to fire off on the first connection before waiting for a reply needs to be configurable. For high speed / high latency (e.g. satellite) it may be best to just send all. I believe the producer should be free to implement its own session management and may very well use one http session / one cookie *per consumer to producer connection* with connections on a *per Portal user* basis. This would be hidden from the Portal portlet proxy (if it actually compared cookie values it may find two entities have a common http session id) and from the Portlet entity which would only see its private session data. The producer would use the entity handle to partition the state objects (http session) referenced by the http session identifier (cookie). The consumer would only be encouraged to use the right cookie value, associated with an entity by the http session identifier returned by the producer, and should avoid using a connection with a different http cookie value than the one a getMarkup request (for a user & entity combination) was previously made on. The above is not meant to be prescriptive in any way but aims to try to identify guidelines for http session management for consumer Portals for "private" portlet sessions. Those shared sessions are quite another beast altogether ;-) regards, Andre -----Original Message----- From: Rich Thompson [mailto:richt2@us.ibm.com] Sent: 08 August 2002 13:16 To: wsia@lists.oasis-open.org; wsrp-interfaces@lists.oasis-open.org Subject: Re: [wsia] [wsrp-interfaces] Another case for explicit session creati on? 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> ---------------------------------------------------------------- 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