[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [wsrp-comment] Comment on Today's Joint Interfaces WorkingTelecon
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> > > --
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC