MHonArc v2.5.2 -->
wsia message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
Subject: [wsia] 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