[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [wsrp] Re: [wsia] Follow-on Example
Mike - my comments are embedded in [CL] tags. 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> | | | | | | 06/11/2002 11:19 | | | PM | | | Please respond to | | | Michael Freedman | | | | |---------+-----------------------------> >---------------------------------------------------------------------------------------------------------------------------------------------| | | | To: wsia@lists.oasis-open.org, wsrp@lists.oasis-open.org | | cc: | | Subject: Re: [wsia] Follow-on Example | | | | | >---------------------------------------------------------------------------------------------------------------------------------------------| Eilon, Oracle's approach/point of view (on the web approach) is as follows: a) we strongly discourage portlets from maintaining any kind of transient state. We have found that even with moderate sized user communities, stateless portlets lead to significantly improved portal response times. So our preferred solution for your reservation scenario is (0): there is neither a session nor a transient entity. The reservation state is maintained by encoding the information in URLs inserted into the generate response content. I.e. only use sessions when state must be shared between entities. [CL] Weren't sessions introduced in the web-world to avoid the nasty encoding of parameters (data) in the request? [CL] b) recognizing that sessions will be used however, the base scenario should be one in which the two reservation portlets cooperatively run in the same session. In this scenario the two portlets would be responsible for namespacing encoding their session data to avoid collisions. This is analogous to the (servlet) web model though obviously a more insidious situation as servlets often (safely) assume only one "instance" runs in a session. All we would need to do to support this would be ensure that a portlet is able to determine and use a "key" that distinguishes one use (on a page) from another. If this key/id were generated by the consumer, the consumer could easily choose an algorithm for generating such an id that is repeatable without maintaining any dynamic (state) information. Hence the ID would have little/no cost. [CL] I certainly encourage the use of sessions, also accross instances if session sharing is desired. However I do not see the need for such a "key". Even if all remote portlets would share one session (what I do not support) and would need to namespace their own parameters they could use their entitiy key (transient or persistent) to do so. This "key" already uniquely defines the portlet instance on a page. So why would we introduce another key? [CL] For us/me the above completely covers Approach 1: the web approach. It allows multiple entities of the same type to run in a session with entity private session data while still allowing these same entities to share session data between themselves of entities of other types. [CL] I have the impression that we talk about different concepts while using the same terms. Maybe this introduces the confusion (at least for me). My understanding is: Even if there are multiple portlets of the same type on one page they would be identified by distinct entity handles (normally persistent entities). So the question above does not arise. [CL] The outstanding question is whether we consider the situation where a portlet only has entity private data so common that we should allow for them to be so declared and mandate the consumer honor such a declaration? Personally, I think this is reasonable. Not having to partition (namespace) the session would be useful to such developers. And I think this occurs commonly enough for us to represent formally. [CL] I agree to your comment. But doesn't this contratict the statements in (b)? [CL] Another scenario to consider is one where a set of entities want to share a session distinguished from another set running in the same consumer. This is a situation where a service provides 2 portlets designed to work together. For example a news feed display portlet and a topic portlet. If 2 sets of these run is the same page how is one set's session data isolated from the other? My answer is that the consumer merely chooses to establish 2 sessions (vs. one) and passes the correct session ID to each set. I [CL] Great, we are in sync. [CL] further believe we shouldn't define how a consumer chooses/learns to do this. I.e. I don't think we should define producer meta data that describes potential groupings for its sessions. Rather, portlets must expect that the consumer will potentially run all of these entities in the same session and behave accordingly. In many circumstances this may mean that the sets trounce each others shared data. However, well coded portlets could choose to represent this demarcation in its own settable configuration data for the portlets. I.e. the config screen could have a setting for group id allowing the page developer to set a common group id for the 2 portlets in each set. [CL] This is discussable. I would prefer to let the portlets give hints in its metadata to indicate what other portlets to share data with. But the concept of letting the user (or Administrator that installs the portlets) select the grouping is appealing as well. [CL] -Mike- ---------------------------------------------------------------- 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