[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [wsrp-interfaces] Re: [wsrp-wsia]: Updated alternative API
Rich,
On your more involved use case has WSIA drilled into this enough to know how it might want to represent a coordinated
cross producer session? I can see solutions where this is a distinct session reference from the one under consideration
between the consumer and the producer. Or am I misunderstanding what you mean by coordinating?
-Mike-
Rich Thompson wrote:
> I agree that the simplest case is when the Consumer cares that the state of
> the Producer matches its expectation of that state as it manages
> incremental updates to that state.
>
> A more involved use case involves a Consumer coordinating state changes
> between multiple entites at multiple Producers. A number of the WSIA
> scenarios require the Consumer being capable of doing such coordination.
>
>
> Eilon Reshef
> <eilon.reshef@webc To: "'Michael Freedman'" <Michael.Freedman@oracle.com>
> ollage.com> cc: "'interfaces'" <wsrp-interfaces@lists.oasis-open.org>,
> "'wsrp-wsia'" <wsrp-wsia@lists.oasis-open.org>
> 06/20/2002 11:36 Subject: RE: [wsrp-interfaces] Re: [wsrp-wsia]: Updated alternative
> AM API
>
>
>
>
> Mike,
>
> An example would be a situation where the Consumer sets some transient
> data (properties) specific to the entity/user scope. When the session
> times out, the transient data needs to be restored. One way to implement
> this is to let the Consumer know, and have the Consumer re-instate the
> state by setting the property values again.
>
> Eilon
>
> -----Original Message-----
> From: Michael Freedman [mailto:Michael.Freedman@oracle.com]
> Sent: Thursday, June 20, 2002 10:51 AM
> Cc: interfaces; wsrp-wsia
> Subject: [wsrp-interfaces] Re: [wsrp-wsia]: Updated alternative API
>
> Rich,
> Thanks for the comments/questions. On (2) I have been meaning to
> ask you about the WSIA use case that needs the consumer to be aware that
> the producer session has timed-out. I have some ideas on "solving" this
> with the model I propose but could do a better job if I had a more
> thorough understanding of what is needed and why. Can you explain?
> -Mike-
>
> Rich Thompson wrote:
>
> > Mike, your proposal raises a variety of questions it will be good to
> > work through as a group. A large one for me relates to proposing that
> > the Consumer generate the session key. I see several pros and cons:
> >
> > Pros:
> > - This become implicit session creation with predefined session
> > sharing. As such it minimizes roundtrips while enabling sharing.
> >
> > Cons:
> > - Pushes complexity related to (re)creation of shared sessions from
> > Consumer to Producer. I'm not objecting, but we need to explicitly
> > recognize this.
> > - Sessions can be destroyed and recreated without Consumer knowledge.
>
> > This involves a major state change and the more advanced WSIA use
> > cases definitely have the Consumer interested in state changes. Having
>
> > the design hide such changes will cause major problems later.
> >
> > Any thoughts on how the second con can be mitigated?
> >
> >
> > Michael Freedman
> > <Michael.Freedman@ To: interfaces
> <wsrp-interfaces@lists.oasis-open.org>,
> > oracle.com> wsrp-wsia
> <wsrp-wsia@lists.oasis-open.org>
> > cc:
> > 06/17/2002 04:16 Subject: [wsrp-wsia]:
> Updated alternative API
> > PM
> >
> >
> >
> > The following is an updated version (attached) of the counter-proposal
>
> > to draft 0.1.2 I sent last week. The main changes are the session as
> > well as the entity references are created/sent by the consumer. There
>
> > is also a new reference for an entity session -- the session
> > conversation with a specific entity. Finally, I have simplified the
> > method signature defining a single ConsumerCtx parameter to hold all
> > the
> > (potential) references. There are still alot of details to put in
> here
> > so we have a consistent understanding but I though you would like an
> > early view. While waiting for these details the key to looking at
> this
> > is to think in terms of the consumer vs. the producer. This API
> doesn't
> > represent (many) abstractions as concrete objects in the producer.
> > Rather, most abstractions are seen as elements/scopes defined by the
> > consumer that are passed by reference to the producer. The Producer
> is
> > thus freed to represent themselves internally anyway they want to --
> > merely needing to build a mechanism that maps from these references to
> > their implementation.
> > -Mike-
> > The following is an updated version of the counter-proposal to draft
> 0.1.2
> > I sent last week. The main changes are the session as well as the
> entity
> > references are created/sent by the consumer. There is also a new
> reference
> > for an entity session -- the session conversation with a specific
> entity.
> > Finally, I have simplified the method signature defining a single
> > ConsumerCtx parameter to hold all the (potential) references. There
> are
> > still alot of details to put in here so we have a consistent
> understanding
> > but I though you would like an early view. While waiting for these
> details
> > the key to looking at this is to think in terms of the consumer vs.
> the
> > producer. This API doesn't represent (many) abstractions as concrete
> > objects in the producer. Rather, most abstractions are seen as
> > elements/scopes defined by the consumer that are passed by reference
> to the
> > producer. The Producer is thus freed to represent themselves
> internally
> > anyway they want to -- merely needing to build a mechanism that maps
> from
> > these references to their implementation.
> >
> > As background here are the terms and their defintions I am using:
> >
> > client = an end user
> >
> > consumer = an intemediary responsible for the aggregation and
> control
> > of heterogeneous producer services, responsible for the
> interaction
> > between
> > the client and the producer services placed on the clients
> > application interface.
> >
> > producer = a container of producer services. the WSIA/WSRP
> > compliant service. As consumers are anticipated to be
> aggregators, a
> > producer
> > represents 1 or more entity types.
> >
> > producer service = the WSIA/WSRP compliant service ( aka.
> > portlet )
> >
> > entity type = a specific identifyable consumable function of a
> > producer. Producers publish its entity types to consumers.
> > Consumers reference entity
> > types to address its producer requests.
> >
> > entity = a consumers particular usage of an entity type.
> Consumers
> > are anticipated to be aggregators, including aggregating
> multiple
> > distinct
> > instances or producer's entity type. The entity represents each
> of
> > these uses. From a producer perspective, the entity identifies
> a
> > particular consumer
> > usage. Producers will typically use this ID as a key to per
> usage
> > state.
> >
> > reference: A reference is an ID passed from the consumer to the
> > producer to identify something known to consumer but maintained
> by
> > the producer.
> >
> > persistence reference: A reference to persistent state managed
> by
> > the producer. Typically, a consumer will maintain a persistence
> > reference for
> > entities.
> >
> > conversation reference: A conversation reference is an ID that
> > represents a particular (type of) conversation between the
> consumer
> > and the producer.
> > There are 4 converstation IDs: consumer to producer
> (application),
> > thread of a consumer to a producer (session), consumer to an
> entity
> > (entity), and
> > thread of a consumer to an entity (entity session).
> >
> > application reference: A conversation between a consumer and a
> > producer. This conversation spans all consumer runtime use and
> all
> > producer
> > entities of this consumer. For convenience [in making this
> unique],
> > this ID is derived from the consumerID created by the producer
> > during
> >
> > regristration.
> >
> > session reference: A subconversation within an application
> > conversation between a consumer and a producer. As such it is a
> > shared scope between
> > all entities within a given producer that a consumer chooses to
> group
> > together. This can be all the entities of the producer, a
> subset of
> > entities, and
> > even at the extreme one session per entity. Typically, a
> > consumer/producer sessions scope will be tied to a session
> maintained
> > between the client and
> > the consumer.
> >
> > entity reference: A conversation between a consumer and a
> particular
> > instance of an entity [type].
> >
> > entity session reference: A conversation within a session with
> a
> > particular instance of an entity [type]
> >
> > API:
> > ConsumerRef registerConsumer(ConsumerProperties consumer);
> >
> > void updateConsumer(ConsumerCtx ctx, ConsumerRef consumer,
> > ConsumerProperties consumerData);
> >
> > deregisterConsumer(ConsumerCtx, ctx, ConsumerRef consumer)
> >
> > PersistenceRef createPersistenceRef(ConsumerCtx ctx,
> > PersistenceType type, PersistentProperty[] values);
> >
> > PersistenceRef destroyPersistenceRef(ConsumerCtx ctx,
> > PersistenceRef ref, boolean cascade);
> >
> > FragmentResponse getFragment(ConsumerCtx ctx,
> FragmentRequestData
> > parameters);
> >
> > void endScope(ConsumerCtx ctx, Scope scope); // scope is
> > application,
> >
> > session, entity, or entitySession
> >
> > .... [aka performAction, describe, setProperties, getProperties]
> >
> > Data:
> > Note: we can break this into two or more (heirarchical) data objects
> > if we need/feel it works better in the API/
> >
> > public class ConsumerCtx
> > {
> > private ConsumerRef consumerId;
> > private UserIdentify user;
> > private SessionRef sessionId;
> > private EntityRef entityId;
> > private String entityType;
> > private EntitySessionRef entitySessionId;
> > private PersistenceRef persistenceId; // passed if portlet
> > maintains data
> > private PersistenceProperties persistenceData; // passed if
> > consumer does
> > private PreambleData updateData; // update the included session
> or
> > // persistent data before generating the fragment;
> > }
> >
> > public class FragmentRequestData
> > {
> > private String charSet;
> > private String markupType;
> > private String locale;
> > private Boolean secureClientCommunications;
> > private Property[] headers;
> > private Property[] parameters;
> > private DeviceInfo clientDevice;
> > private Mode producerMode;
> > }
> >
> > public class FragmentResponse
> > {
> > Property[] responseProperties;
> > String fragment;
> > PersistentProperty[] values;
> > }
> >
> > Quick overview of usage:
> > The producer creates two types of IDs. One to represent a registered
> > consumer and one to reference a persistent record it maintains (on
> > request by the consumer). The later is not needed/used if the
> > consumer manages the producers persistent itself (or the producer does
>
> > not support persistence). The consumer ID is expected to be unique for
>
> > all consumers of this producer. The consumer subsequently uses this
> > ID (or one derived from it) as the ConsumerRef in all subsequent calls
>
> > to identify the caller and to allow the producer to tie itself to this
>
> > consumer. The persistentRef is passed to all calls where an entity is
>
> > referenced.
> >
> > A conversation might go like this:
> >
> > Note: In this example a session represents a per user conversation
> > between a consumer and a producer. In this situation a SessionRef is
> > sent by the consumer to the producer for every call below where the
> > consumer is running within the context of a user. I.e. a consumer can
>
> > choose not to send sessionRefs when it doesn't know/can't identify the
>
> > user (aka the Public user). Question: is not sending the sessionRef
> > when there is no known conetxt okay? or do we force the consumer to
> > always find/have a context?
> >
> > Operation: Portal locates and registers a portlet service.
> > Action: Consumer calls registerConsumer() to register itself with the
>
> > service. It also calls describe() to get entity information from the
> > producer.
> > Result: Because this is the first call received by the producer since
>
> > it has started running, the producer initializes its application scope
>
> > -- acquiring resources at the application level [It can choose to
> > defer until an operation needs application data]. Additionally, if a
> > sessionRef is passed, the producer may choose to [if it needs session
> > data at this point] to initialize sessionscope. The consumer receives
> > a ConsumerRef from the producer that it maintains persistently.
> >
> > Operation: As a consequence of registration, the portal creates an
> > entity instance for each entity type in its portlet repository
> > (toolbox).
> > Action: Portal calls createPersistentRef() for each entity letting the
> > entity set its default values.
> > Result: The consumer (portal) receives a persistent ref that it
> associates
> > with the instance it created in the toolbox.
> >
> > Operation: Portal developer customizes the portlets settings in the
> > toolbox.
> > Action: Portal calls getFragment with an entityRef it manufactuers to
>
> > represent the toolbox instance, the persistenceRef it received from
> > createPersistenceRef, mode of Edit -- plus of course the consumerRef,
>
> > sessionRef, and the entitySessionRef.
> > Result: Producer/portlet uses this information to present a screen to
> > the developer for customizing its settings.
> >
> > Operation: End-user creates a portlet on a page from a templaet in the
>
> > toolbox.
> > Action: Portal calls createPersistentRef() to create a new reference
> > for the page instance. (The persistenceRef of the toolbox instance is
>
> > passed so the values can be inherited.) After this completes, the
> > Portal calls
> > getFragment() on passing the new persistenceRef, a new entityRef (for
> this
> > new instance), etc.
> > Result: Producer/portlet uses this information to present its "show"
> > screen to the user.
> >
> > -Mike-
> >
> > ----------------------------------------------------------------
> > 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