[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [wsrp-comment] Comment on Today's Joint Interfaces Working Telecon
A producer should not use the session to do this -- as a session's scope is entirely defined by the consumer. (Its
going to cause us problems/introduce complexities if we try and allow both to define the rules as they see fit).
Rather the producer should internally manage this data using a key such as the user identity.
-Mike-
Rich Thompson wrote:
> This eliminates recognizing that the Producer actually manages the
> lifecycle of the session. How about a case where a Producer service
> (example, a cooperating set of HR related entities) that wants to enforce a
> policy that each End-User (assume identification by some credential is
> required) interacts through exactly 1 session for all the entities
> regardless of the number of windows/devices/Consumers the End-User uses to
> connect in parallel. Why would we need to exclude the Producer service from
> being able to enforce such a policy?
>
>
> Michael Freedman
> <Michael.Freedman@ To: wsia-comment@lists.oasis-open,
> oracle.com> wsrp-comment@lists.oasis-open.org
> cc:
> 06/11/2002 04:18 Subject: Re: [wsrp-comment] Comment on Today's Joint Interfaces
> PM Working Telecon
>
>
>
>
> 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