[wsrp][interfaces]: Agenda for June 6th conference call

[Michael Freedman <Michael.Freedman@oracle.com>]

IMPORTANT:  Conference call starts at 7:30am PDT (10:30 EDT, 4:30
CET?).
Number and conference id is still the same: 877-302-8255 or 303-928-2609
ID: 8814427

This time change is for this week only.

Agenda:
1) Alert new mailing list for this subcommittee. Subscribe now! (wsrp-interfaces@lists.oasis-open.org) Starting next Monday all e-mails targeting [interfaces and protocols] should go to this list.

2) Continue discussing requirements.  We are going to skip ahead a little and discuss the session requirements (described at end of this message) as we are still waiting for other requirements to be written up.

3) If time we will discuss Alejandro's "Separate Administration Interface" issue.  (See mail discussion from this past week.
 

(Draft) Session requirements:

Sessions:

This section discusses the requirements for creating/managing and deleting
sessions in support of transient information.

 
R22: [must] The specification must allow a portlet service to maintain transient information on an N to 1 basis where N is the number of discrete representations of transient data per portal and 1 being the portlet service.

Q6:  Do we need to support maintaining transient data at the entity/instance level as well or is the session sufficient?  If we do need to maintain per instance transient data is this scoped to the session or not?  I.e. is there a transient ID per portlet instance per session or just one transient ID per portlet instance across all sessions (of a single portal).

R23: [must] The specification will provide this support by defining the concept of a session.  A session will be an identifier passed between the portal and the service that allows the portlet entity to map back to the discrete transient information.

R24: [must] The specification must allow the portal to define the [portal] scope of the session.  I.e. though its likely that a session is mapped to a user the portal must be free to define alternative scopes.

R25: [must] A session must be able to span all portlets managed by the portlet service.

R26: [must] The specification must allow for the session to be created either at the instigation of the portlet or the instigation of the portal.

Q7:  This begs the question of how?  I.e. how should we deal with the complexities of creating sessions in a concurrent world?  For example:  if we allow portlets to create sessions at any time by returning an id don't we imply the requirement that the service manage the race condition?  I.e.  where two portlets that should run in the same session receive a concurrent request from a portal where no current session ID exists, doesn't the service need to guarantee that each portlet receives the same newly created session if both ask for one?  If so how does the service know which portlets (requests) belong to the same session?  Another worrisome case occurs again when portlet A and B receive concurrent requests with no current session ID indicated.  In this case A requests a session but be does not.  I.e. A returns a session id but B doesn't.  What must the portal do in this case?  Do we require the portal to recognize the return from A and send it to B on all subsequent requests.  The final case occurs when sessions go style -- portlet A and B are running in the same session signified by ID XXX.  Portlet B receives a request, recognizes the session has timed out and creates a new session/returns a new ID.  What must the portal do in this case?  Must it recognize the change and pass the new sessionID to A on subsequent requests?  The alternative to this mess is to define the API where the portal must create the session explicitly via a createSession call.  In this way it can make the call prior to sending any concurrent requests.  To handle the session timeout situation we would define that portlet methods could return a SessionInvalid error -- the portal would be required to create a new session and retry the operation that failed.

R27: [must] A portal must maintain sessions needed by the portlet service.

R28: [may] A portlet service may choose to not create a session when requested to do so by the portal.

R29: [must] However if it chooses to not create upon request, it must never create a session as a side effect in future request processing.  A portal may ignore such sessions created by non conforming services.

R30: [must] The specification must allow a portal to tell the portlet service when a session is not longer valid/active.

R31: [may] A portal need not tell the portlet service when a session becomes invalid/inactive.

R32: [may] A portlet service may invalidate/inactivate a session at any time.  A portlet service need not tell the portal when such invalidation/inactivation occurs.

R33: [must] A portal must never send a known invalid/inactive session to a portlet service.

R34: [must] A portlet service must be able to describe whether or not any of its portlets require session maintenance.

Q4: [open]  Do we want/need to describe which portlets need sessions -- or sufficient as a boolean?