RE: [wsrp-wsia] Re: [wsia][wsrp][wsrp-wsia joint interfaces]:Analternative

[Eilon Reshef <eilon.reshef@webcollage.com>]

Title: Message

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:Michael.Freedman@oracle.com]
Sent: Thursday, June 13, 2002 9:34 PM
To: wsia@lists.oasis-open.org; wsrp@lists.oasis-open.org; wsrp-interfaces@lists.oasis-open.org; wsrp-wsia@lists.oasis-open.org
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-