[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
That's what I thought, and I would be content with that. I think what you meant in the last note was that the producer only sees the consumer session.. True? Rex At 2:27 PM -0700 6/11/02, Michael Freedman wrote: >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> >> >> -- > > >---------------------------------------------------------------- >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