Re: [wsrp-comment] Comment on Today's Joint Interfaces WorkingTelecon

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

Rex,
   Again, I think we need only consider the description between a consumer and a
specific producer (representing many entities).  However, to clarify for you, the
consumer will maintain distinct producer sessions for a single user session if is
maintaining with a client.  I.e. a client/consumer establish a session.  The
consumer as it talks with each of its X producers establishes a distinct session
to each.  The consumer chooses to scope these producer sessions to the user
session it is maintaining with the client.  By scope I mean the creation/destroy
lifecycle is within the bounds of the create/destroy lifecycle of the
client/consumer session.  Note: The producer never sees the client session it only
sees the producer session.  One is merely (typiaclly) scoped within the other from
a consumer standpoint.
      -Mike-

Rex Brooks wrote:

> This is closer to what I heard. The one remaining question I have is,
> what happens when a consumer needs to manage more than one producer
> for a single user? Is it the case that this definition for a session
> is one end-user to one consumer to one producer for N-many entities,
> and how the producer manages their entities is their business as long
> as the consumer uses the correct sessionID? So it is up to the
> consumer to manage however many sessions are needed for any one user?
>
> Rex
>
> At 1:18 PM -0700 6/11/02, Michael Freedman wrote:
> >How about something like:
> >
> >Session:  represents a conversation between a producer and a
> >consumer.  The scope of the conversation is defined by the
> >consumer and may include from 1 to N entities managed by  the
> >producer where N is all entities that pertain to this
> >consumer.  Such a session allows producers to maintain transient
> >state across the set of entities the consumer sees fit
> >to include in the session.
> >
> >      -Mike-
> >
> >Rich Thompson wrote:
> >
> >>  The glossary type definition I jotted down as this conversation neared
> >>  consensus was:
> >>
> >>  Session: A Producer managed transient data storage mechanism whose scope
> >>  is defined by a Consumer. Common scopes include an End-User, a user group
> >>  or an arbitrary Consumer defined scope.
> >>
> >>  Hope this is close to what others heard as well.
> >>
> >>
> >>                        Rex Brooks
> >>                        <rexb@starbourne.        To:       Michael
> >>Freedman <Michael.Freedman@oracle.com>, Rex Brooks
> >>                        com>                      <rexb@starbourne.com>
> >>                                                 cc:
> >>wsia-comment@lists.oasis-open,
> >>                        06/11/2002 02:23
> >>wsrp-comment@lists.oasis-open.org
> >>                        PM                       Subject:  Re:
> >>[wsrp-comment] Comment on Today's Joint Interfaces
> >>                                                  Working Telecon
> >>
> >>
> >>
> >>
> >>  Thanks, Mike,
> >>
> >>  I wanted to be sure of this since we are scheduled to work on the
> >>  glossary tomorrow, and I would like to capture at least as much as we
> >>  managed to reach consensus on.
> >>
> >>  Rex
> >>
> >>  At 11:11 AM -0700 6/11/02, Michael Freedman wrote:
> >>  >I think you mostly got it.  The key mistake (if I understand your e-mail)
> >>  >is that the client/consumer session is equivalent to the sessionID in the
> >>  >API.  The client/consumer session is of no concern to the API as its
> >>  >something between the client and the consumer vs. the consumer and the
> >>  >producer.  Yes, its likely that a consumer will tie its session
> >>  >conversation with a particular producer to live within this
> >>  >client/consumer scope but it need not.
> >>  >    -Mike-
> >>  >
> >>  >Rex Brooks wrote:
> >>  >
> >>  >>  Hi Everyone,
> >>  >>
> >>  >>  Unless I had cotton in my ears, I think we neared consensus on what a
> >>  >>  Session is for the purposes of having a sessionID for the interface.
> >>  >>  Correct me please if I am wrong, but I believe we arrived at a point
> >>  >>  where we can say that what we mean by Session is the conversation
> >>  >>  started by one end-user requesting service from one consumer, such
> >>  >>  that a sessionID is created by the consumer whose responsibility it
> >>  >>  is to manage this session/conversation with the end-user,  providing
> >>  >>  for delivery of service from one or more producers.
> >>  >>
> >>  >>  There was also a related concept put forward for consideration called
> >>  >>  a sharedSession. This concept had many possible configurations, but
> >>  >>  the basic idea was that something like this was needed, in addition
> >>  >>  to transientEntities for economical management of multiple portlets
> >>  >>  within containers, multiple producers within a session, etc.
> >>  >>
> >>  >>  TransientEntities and sharedSessions were not quite narrowed down
> >>  >>  enough for consensus to emerge, and I may be mistaken about
> >>  >>  sessionID, but we certainly worked tenaciously at the interface
> >  > >>  issues.
> >>  >>
> >>  >>  Thanks,
> >>  >>  Rex
> >>  >>  --
> >>  >>
> >>  >>  ----------------------------------------------------------------
> >>  >>  To subscribe or unsubscribe from this elist use the subscription
> >>  >>  manager: <http://lists.oasis-open.org/ob/adm.pl>
> >>
> >>  --
> >>
> >>  ----------------------------------------------------------------
> >>  To subscribe or unsubscribe from this elist use the subscription
> >>  manager: <http://lists.oasis-open.org/ob/adm.pl>
> >>
> >>  ----------------------------------------------------------------
> >>  To subscribe or unsubscribe from this elist use the subscription
> >>  manager: <http://lists.oasis-open.org/ob/adm.pl>
> >
> >
> >----------------------------------------------------------------
> >To subscribe or unsubscribe from this elist use the subscription
> >manager: <http://lists.oasis-open.org/ob/adm.pl>
>
> --