I have done more thinking since my initial publish. I like your idea
of moving the session reference to the consumer. I think it makes
for a simpler more straightforward API. I will try and get out an
updated draft today. On you questions:
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.
-Mike-
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-----
From: Michael Freedman [mailto:]
Sent: Thursday, June 13, 2002
9:34 PM
To: ;
; ;
Subject: Re: [wsrp-wsia] Re:
[wsia][wsrp][wsrp-wsia joint interfaces]: Analternative
Rich Thompson writes, "I see little value and a lot of downside to requiring
the Producer to manage a dual key."
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/producer
This 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/producer
This 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 entity
Finally, 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.
-Mike-
