[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
How about a generic notion that leaves the scope of the session open:
Session: a session groups sequential requests between a producer and a
consumer into a conversation, allowing producers to maintain transient
state across a related set of calls from the same Consumer.
And another suggestion: how about renaming it to "scope" or
"conversation" to make the distinction between the conceptual notion and
the implementation feature (a producer session may be used to implement
transient entitles, portal handles and many other things).
So the API would become ...createScope(), destroyScope() or
createConversation() etc.
Eilon
-----Original Message-----
From: Rich Thompson [mailto:richt2@us.ibm.com]
Sent: Tuesday, June 11, 2002 4:34 PM
To: wsia-comment@lists.oasis-open; wsrp-comment@lists.oasis-open.org
Subject: Re: [wsrp-comment] Comment on Today's Joint Interfaces Working
Telecon
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