Re: [wsrp] [interfaces] session creation

[Carsten Leue <CLEUE@de.ibm.com>]

Alejandro -

in your description of the scenario it is unclear to me how many PSessions
exist. One per entity or one per producer?
If there is one per entity there would be no possibility to share session
data between entities. As we have as a requirement that it should be
possible to share session data, this cannot be the case.
If there is only one PSession per producer that is returned implicitly this
intoduces some problems (from my point of view):
- the namespacing burden is put on the producer. To isolate the portlets
inside the (global) session the producer would have to prefix the
parameters for each portlet that writes into this session. If the consumer
had created separate sessions for sets of communicating portlets this would
not have been the case. How can session data be shared in this case?
- assume the case that multiple portlets should be rendered in parallel
(batch processing) but no session exists. Which one of the portlets to be
rendered should create the session? The producer would have to provide
non-trivial logic to always use the same session
- one way to share session data between different producers would be that
get consumer calls getProperties on the first session and setProperties on
the second one (just copies the session data). In the case that there was
only one session per producer the client needs an additional way to specify
what subset of session data to copy. If the consumer could maintain
multiple sessions per producer this granularity would solve the problem
automatically.

For these reasons I think that the ability to explicitly create sessions
significantly simplifies the data handling.

Best regards
Carsten Leue

-------
Dr. Carsten Leue
Dept.8288, IBM Laboratory Böblingen , Germany
Tel.: +49-7031-16-4603, Fax: +49-7031-16-4401



|---------+---------------------------->
|         |           Alejandro        |
|         |           Abdelnur         |
|         |           <alejandro.abdeln|
|         |           ur@sun.com>      |
|         |                            |
|         |           06/11/2002 05:51 |
|         |           AM               |
|         |           Please respond to|
|         |           Alejandro        |
|         |           Abdelnur         |
|         |                            |
|---------+---------------------------->
  >---------------------------------------------------------------------------------------------------------------------------------------------|
  |                                                                                                                                             |
  |       To:       wsrp@lists.oasis-open.org                                                                                                   |
  |       cc:                                                                                                                                   |
  |       Subject:  [wsrp] [interfaces] session creation                                                                                        |
  |                                                                                                                                             |
  |                                                                                                                                             |
  >---------------------------------------------------------------------------------------------------------------------------------------------|




It's still unclear to me why the consumer would need request the
creation of a session to the producer, maybe I've missed something
during the last conf call. I would like to know what scenarios can not
be covered using a mechanism similar to the HTTP Cookies protocol:

1) A client makes a request to a consumer
2) The consumer creates a Csession for the client
3) The consumer makes a request to a producer
4) The producer creates a Psession for the consumer request
5) The producer, together with the response, sends back the PsessionID
to the consumer
6) The consumer stores the PsessionID in the Csession
7) The consumer, together with the response, sends back the CsessionID
to the client
8) Future client requests to the consumer contain the CsessionID
9) Future consumer requests to the producer contain the PsessionID
associated to the CsessionID of the incoming client request
10) Sessions end/expire re-triggering the session acquisition steps on
subsequent requests

In the absence of a consumer-producer session, the concurrency problem
-when producer receives concurrent consumer requests for different
portlets, where all the requests are to fulfill the same client request-
can be easily solved by having the consumer sending a transient common
ID with all the consumer-producer requests for the same client request.
This transient common ID would help the producer to manage the case when
portlets serving requests for the same client request ask for a session
to be created. Note that this transient common ID for consumer-producer
requests does not have to be same for different client-consumer
requests, although the protocol could use the same placeholder for the
transient common ID and for the consumer-producer session ID
(PsessionID). From the producer perspective, a transient common ID or a
consumer-producer session ID are no different except for the fact that
the later has been created by the producer, it could be used to store
transient local data associated with the session and it could have a
expiration.

Regards.

Alejandro



----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>