OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrp-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: Re: [wsrp-comment] Comment on Today's Joint InterfacesWorkingTelecon


Right. The producer only sees the session that is established between the consumer
and it.  It doesn't see the session that is established between the client and the
consumer.
    -Mike-

Rex Brooks wrote:

> 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