[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [wsrp-wsia] Re: [wsia][wsrp][wsrp-wsia joint interfaces]:Analternative
What are scopes? Scopes delineate a conversational lifecycle between a consumer and a producer. Scopes are referenced by IDs. The consumer provides these IDs to the producer so that it may use them as keys to abstractions it may choose to represent to correspond with these scopes. Typically a producer will manage state at these scopes. One of the nice things about this model is that a producer is free to ignore any/all scopes it doesn't have a need for (without cost).
In our model we have the 4 conversations I outlined in my e-mail. The umbrella conversation is the consumer/producer. But within this we have two distinct conversations: consumer thread to producer (session) and consumers instance of producer to producer (entity). For completeness there is the fourth conversation (session/entity).
How are scopes related:
As I said above the consumer / producer conversation is the root scope. I don't think we should consider 2 consumers talking to the same entity. Scopes are about conversations not state per se. If you want a "constant"/shared portlet across consumers then either be stateless (at the entity level) or use persistence to share. This scope is used for sharing data across all portlets regardless of what end user is making the request. Application (global) resources are commonly maintained at this scope. This scope comes into existence the first time a consumer wants to make a request to the producer and goes out of existence when the consumer no longer wants to talk to the producer.
A thread within the consumer /producer is the session scope. This conversation allows a consumer to group producer calls (across entities) into distinct conversations. Generally this is on a per user basis. This allows portlets to share data within a distinct subconversation). This scope comes into existence the first time a consumer talks to a producer on behalf of user (or whatever the consumer is choosing to use to partition the conversation). It goes out of scope when the consumer no longer represents the user.
A consumer to a producer entity. In our world we consumers can aggregate 1 or more "instances" of the same portlet. In so doing the consumer/producer must have a way to distinguish between these "instances". This scope defines the conversation between a consumer and a single entity. A producer/portlet can store portlet (entity) global data at this scope. I.e. portlet resources. It goes out of scope when the consumer no longer wants to talk to this entity.
A thread within a consumer to a producer entity. The difference between this scope and the one above is that the conversation in this scope is tied to the session. It goes out of scope either when the consumer no longer wants to talk to the entity or the session goes out of scope.
As for lifecycle:
The consumer defines the lifecycles. During a conversation, each scope is represented by a scope ID (except for the last which uses the sessionID and entityID together). These IDs are meant to be keys that allow the producer to build corresponding abstractions that manage state. For performance considerations, scopes are initiated implicitly. I.e. there is no InitScope() call. Rather, initialization occurs in the producer the first time it receives the ID. So consumers can effectively manage producers there is a EndScope() call that tells the producer it is safe to clean itself up. As we are running on a connectionless protocol it is expected the producer will also support a timeout mechanism to clean up its resources. This has no effects on the consumer. The consumer neither is informed of these timeouts nor need generate new scope IDs. Producers are expected to reinitialize themselves unbeknownst to the consumer.
As for your final comment:
As a side note, most of the discussion assumes that the Producer creates a session for each (b) scope. However, we should also consider implementations where the Producer creates a session (instead/also) for each (d) scope.
The way this model works is that these are scopes
defined by the consumer referenced by ids. Within this model the
two choices for the session to entity conversation would seem to be:
a) let the producer join the session and entity ref themselves (i.e. use the entity ref as a subkey in the session to partition the session they maintain).
b) have the consumer represent this scope with a distinct reference.
Though I have been thinking/promoting the former
we seem to have two strong camps. Because of this I think the later
is a better solution as it does a better job satisfying both camps.
Eilon Reshef wrote:
Mike,I think your approach provides a nice way to try to break down the problem in a different. It could be a beneficial to try this as an exercise even if we diverge from the efforts of progressing with the spec as it is currently written.I think your approach points out three questions, which seem to be orthogonal.1. What are the scopes?2. How are they related? For example, even the assumption that the entity scope (c) lives within a portal scope (a) is debatable. For example, can the same pre-configured portlet be incorporated into two different portals within the organization?3. What's their lifecycle? For example, who creates them, how are they managed.So far we have spent a considerable time debating (3) without getting an agreement on (1).As a side note, most of the discussion assumes that the Producer creates a session for each (b) scope. However, we should also consider implementations where the Producer creates a session (instead/also) for each (d) scope.Eilon-----Original Message-----Rich Thompson writes, "I see little value and a lot of downside to requiring the Producer to manage a dual key."
From: Michael Freedman [mailto:Michael.Freedman@oracle.com]
Sent: Thursday, June 13, 2002 9:34 PM
To: email@example.com; firstname.lastname@example.org; email@example.com; firstname.lastname@example.org
Subject: Re: [wsrp-wsia] Re: [wsia][wsrp][wsrp-wsia joint interfaces]: Analternative
What I am attempting to do with this proposal is respond to the confusion we seem to have created by introducing "objects" to represent what are fundamentally scopes. If we the "experts" are having trouble understanding things where will that leave our consumers? Additionally, I am trying to ensure the least number of managed references in the situation that a portal is the consumer to ensure maximum scalability.
From a non-OO (web model) perspective consumers interact with producers at four levels/scopes.
a) consumer/producerThis is analogous to "application" scope. It encompasses all of the calls between a consumer and a producer within a given (running) cycle.b) thread within a consumer/producerThis is analogous to "session" scope. It encompasses all the calls between a consumer and a producer that pertain to a specific consumer thread of conversation. Generally, this thread of conversation is tied to client/consumer conversation/session. This scope "lives" within the application scope.c) consumer/producer entity(Ignoring for the moment our interest of producers representing multiple entity types), we want consumers to maintain distinct references to producers. I.e. two instances of the same portlet on a page. To deal with this we have introduced the logical concept "entity". This scope covers all the conversations between the consumer and the logical "entity". This scope also lives within the application scope.d) thread within a consumer/producer entityFinally, as we have defined session scope above, we have a fourth scope which is a conversation within a given session to a logical entity. This scope lives within the session scope.We have said we would like producers to be able to recognize these scopes and if required maintain internal state tied to each level/scope. To support this the consumer must pass on every request enough information so the producer can "key" to information maintained at each scope. As these are arbitrary scope ids, I contend a consumer prefers a protocol that allows it to specify the IDs so that it can have the greatest flexibility to reduce ID management (for itself). I.e. it can choose IDs that don't have to be (separately) maintained at runtime because they can be manufactured from persistent information -- or they already have a suitable key that could be used. From the producer side, it need no longer participate in the manufacture of these IDs, merely utilize these IDs if/where needed to get back to internal state attached at "scope". [Note: this assumes we would go to the extreme view with this model and have the consumer supply the sessionID]
As all of the scopes discussed above live under the umbrella of a single consumer, all we need to do is ensure that the consumer can be uniquely identified. For simplicity this would have to be an ID generated by the producer (i.e. registerConsumer). The good news is this ID lasts a long time (and is generally persisted). Plus there is only one of them per consumer. Given this 1 ID I contend that many consumers will already have existing IDs they can use to pass to the producer to represent the contained scopes. I.e. we can get rid of both the createSession() and createTransientEntity() call. We would still need a call to create persistent data records when persistence is managed by the producer.
The value of all this hopefully is that its a less confusing model. By viewing IDs as "scopes" producers merely choose whether or not they need a given scope or not. Those that don't need session scope ignore the parameter, likewise for entity scope, etc. There should also be value in fewer objects/ids maintained in the consumer.
On the issue of pushing the burden of managing a dual key to the producer, you are correct this is a consequence of this type of design. The burden however is qualitatively different then when the dual key is maintained by the consumer. In the producer case a key must be maintained (as we are mapping to internal state) whether or not the producer or the consumer supplies it. In the consumer (its often the case) that a key could be manufactured from existing state hence key management is only required if the producer generates the key.
As for the complexity of managing a dual key, I don't see it. Either the producer already reflects application level scope in its implementation -- hence the duality is implicitly maintained or it merely concatenates the two keys into a single one. We could even go so far as require the consumer do this concatenation on behalf of the consumer. This is all significantly more lightweight then the burden the draft suggests we place on producers in support of bulk data operations. How can you be concerned about the complexity of dual key management in the producer when you basically require producers to implement multi-threaded "request" dispatchers and response synchronizers? I.e. our implied intent that a bulk operation is run concurrently within the producer.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC