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

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:] 
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-