OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrp-wsia message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: RE: [wsrp-wsia] Creating an issue - RuntimeContext


Lets consider the worst case: The Producer only supports shared sessions, 
the Consumer has two instances of the same entityHandle on a page and does 
not send an entityInstanceKey. While not likely the only implementation 
choice, the Producer could detect this and generate the equivalent of an 
entityInstanceKey and return this as a sessionID. This does involve 
looking in 2 places for the key before deciding to generate a new one, but 
allows the Producer to work when the Consumer is not supplying something 
the Producer has chosen to depend on.

If the Producer also supports private sessions, it gets much easier as the 
private session can hold the key for access into the shared session.

Rich Thompson




Eilon Reshef <eilon.reshef@webcollage.com>
12/18/2002 11:51 AM
 
        To:     wsrp-wsia@lists.oasis-open.org
        cc: 
        Subject:        RE: [wsrp-wsia] Creating an issue - RuntimeContext


I'm still trying to understand the interoperability aspect of this.
 
Supposed a Consumer puts two entities on a page.
 
If those two entities are different (one is a stock portlet and the other 
is a weather portlet), then this is not an issue.
 
If those two are two "instances" of the same entity and don't share a 
session, they run independently so then this is not an issue.
 
If those two "instance" are of the same entity and do share a session, 
then the Producer may use this instanceKey to differentiate between the 
data of the two... is this correct? If that's the case, if the Producer 
MAY do this, how does the Consumer know whether it should allow/support 
such a scenario, and how is interoperability guaranteed in such a case?
 
 
-----Original Message-----
From: Rich Thompson [mailto:richt2@us.ibm.com] 
Sent: Wednesday, December 18, 2002 8:50 AM
To: wsrp-wsia@lists.oasis-open.org
Subject: RE: [wsrp-wsia] Creating an issue - RuntimeContext

My understanding is that this uniqueness is per Consumer. 
Rich Thompson 



Eilon Reshef <eilon.reshef@webcollage.com> 
12/17/2002 04:32 PM 
  
        To:     wsrp-wsia@lists.oasis-open.org 
        cc: 
        Subject:        RE: [wsrp-wsia] Creating an issue - RuntimeContext 


It's unclear to me from the text below in what context the uniqueness 
applies. It this per user? per page? 
-----Original Message----- 
From: Rich Thompson [mailto:richt2@us.ibm.com] 
Sent: Tuesday, December 17, 2002 10:58 AM 
To: wsrp-wsia@lists.oasis-open.org 
Subject: Re: [wsrp-wsia] Creating an issue - RuntimeContext 
This text in the draft has been modified based on recent decisions to: 
entityInstanceKey: A unique, opaque string the Consumer MAY supply as a 
reference to this use of the entity. This reference MAY be used by the 
entity to properly separate data for multiple instances of the entity 
within any Producer-defined data sharing mechanisms. Since this reference 
may be used as such a key, its length MUST be less than 256 bytes and 
Consumers SHOULD keep it as short as possible. 
There has also been a suggestion to add a note that a Producer could use 
this as a reference in place of generating a sessionID and that such a use 

will likely have a positive impact on the Consumer's performance. 
Rich Thompson 


Subbu Allamaraju <subbu@bea.com> 
12/17/2002 10:06 AM 
 
        To:     wsrp-wsia@lists.oasis-open.org 
        cc: 
        Subject:        [wsrp-wsia] Creating an issue - RuntimeContext 
Topic: RuntimeContext 
Class: Minor Technical 
Title: Intent and scope of uniqueness of the entityInstanceID in the 
RuntimeContext 
Document Section: 5.1.2 
Description: 
What is the intent of entityInstanceID in RuntimeContext? The spec is 
unclear about the difference between the producer-generated entityHandle 
and consumer-generated entityInstanceID. It appears that the producer 
will have to use both entityHandle and entityInstanceID to uniquely 
associate data with an entity. However, for producers not offering 
registration, the consumer generated entityInstanceID (along with 
entityHandle) is not adequate for guaranteeing uniqueness on the 
producer end. 
Regards, 
Subbu 
---------------------------------------------------------------- 
To subscribe or unsubscribe from this elist use the subscription 
manager: <http://lists.oasis-open.org/ob/adm.pl> 

---------------------------------------------------------------- 
To subscribe or unsubscribe from this elist use the subscription 
manager: <http://lists.oasis-open.org/ob/adm.pl> 

---------------------------------------------------------------- 
To subscribe or unsubscribe from this elist use the subscription 
manager: <http://lists.oasis-open.org/ob/adm.pl> 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC