[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [wsrp] Follow-on Example
The example below demonstrates the differences in view regarding transient handles. Example: -------- Many applications use the session object to store transient data, which includes data entered by the user. For example, when you buy a plane ticket, the application stores the departure airport, the arrival airport, etc. in the session object. For argument's sake, assume a third party creates a reservation portlet for tickets, and has no data-sharing-across-portlets issue. And, assume that the portal wants to put two of those services side-by-side and allow two reservation to be placed in parallel (without one affecting the other). Assessment: ----------- There are two views (again, I am hoping that I am doing the right association with names, please correct me otherwise): Approach 1 - Web Architecture (Mike, Carsten): The Producer and the Consumer collaborate to create two separate "sessions". This can be achieved with Producer meta-data that hints that the Consumer should do so (suggested e.g. by Carsten) or by the Producer receiving some sort of context information that allows it to know it needs to use a separate session (suggested e.g., by Alejandro). Approach 2 - Object Oriented (Gil, Charlie): The Producer does not use user sessions at all. (Well, there's nothing to share) (Side comment: conceptually, there's nothing user-ish about this transient information. In fact, this creates the well-known usability thing, that when a user opens two Web windows today, she can't make two reservations in parallel). Instead, the Producer requires the portal to (ALWAYS!) create a transient entity each time it wants to use the service. Each such transient entity, presumably creates a dedicated session object at the Producer end. Subsequent requests are segregated because they are associated with two separate sessions. --> I would like to know that approach (2) implies an object-oriented thinking. It may simplify development on the portlet end (no need for manual segregation of sibling portlets), but as Mike noted requires a bit more data on the portal's end. Approach (1) would be very natural in a stateless line of thinking.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC