MHonArc v2.5.2 -->
wsia message
[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
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-
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
Powered by eList eXpress LLC