[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [wsrp] Soliciting a Discussion around Transient Entities
I think we have to choose between having the Consumer generate a key for
the entity+session and the current draft where the Producer generates all
such references & the Consumer ends up needing to manage a dual key as
having the possibility for both raises the complexity of the protocol
significantly.Two difficulties come to mind if we have the Consumer
generate a single key rather than managing a dual key:
1) This raises the difficulty for the Producer significantly. The current
draft has the Producer generating a reference that it will use to lookup
the entity or session in a later invocation. This allows implementations to
be as simple (ie. may be reasonable for a Producer that does not support
persistence) as a global counter and a Hashtable. If the Consumer gets to
pass the key, the Producer must now treat this as a dual key (Consumer +
Consumer generated key) in order to guarantee uniqueness. Effectively this
has just pushed the dual key management issue out to the Producer (where it
is more likely to result in improper implementations).
2) The specification should not make writing web applications as simple
Consumers difficult (this is likely more of a WSIA requirement). The base
demo of wsxl that we published on alphaWorks is an example of a aggregating
Consumer with no persistence. Hopefully it illustrates that the concept of
a simple Consumer can be easily exploited to build a web app from
components and add value either by the aggregation or through coordinating
changes in the state of the aggregated components.
Michael Freedman
<Michael.Freedman@ To: wsia@lists.oasis-open, wsrp@lists.oasis-open.org
oracle.com> cc:
Subject: Re: [wsrp] Soliciting a Discussion around Transient
06/11/2002 05:43 Entities
PM
Rich,
I think we could eliminate the dual key management issue (for portals)
if we view transient entities as "keys" that
identify a unique runtime consumer instance of a portlet/entity. In such
circumstance we could have the consumer
define/provide this vs. the current proposal that it is producer generated.
Its easy to imagine that a consumer could
write an algorithm that allows its to reconstruct such and ID vs.
remember/manage them. Of course this assumes the
consumer has some persistent representation of its structure. This is
common for most (all?) portals. If we merely
have a transient consumer then it would have to rely/manage the dual keys.
-Mike-
Rich Thompson wrote:
> I think this is a reasonable description. One of the downsides to the
first
> approach (OO oriented) is that is requires a particular scoping of
sessions
> and transient entities (namely one would pass a session into the
> createTransientEntity call). A downside of the second approach (web-app
> oriented) is that Consumers are required to manage the complexity of dual
> keys. This downside becomes an advantage in a common portal scenario
where
> a page may look to present the output of 10+ distinct entityTypes to
> 40,000+ users. Managing dual keys (web-app approach) results in 40,010
> references to manage while the single reference style (OO approach)
results
> in 400,000 references.
>
> If we choose the complexity of managing dual keys, I do think Charlie's
> suggestion of publishing all properties as logically belonging to the
> entity even if the entity chooses to store them in the session will be
> important in keeping the complexity manageable for the more advanced WSIA
> use cases.
>
>
> Eilon Reshef
> <eilon.reshef@webc To:
wsia@lists.oasis-open, wsrp@lists.oasis-open.org
> ollage.com> cc:
> Subject: [wsrp]
Soliciting a Discussion around Transient Entities
> 06/11/2002 03:20
> PM
>
>
>
> Hi,
>
> Following today's joint committee call, I would like to start a
> discussion around the transient entities issue to try to make progress,
> despite the natural difficulty to do it over e-mail.
>
> Here are my thoughts:
>
> Entities are Producer objects with which the run-time interactions
> logically occur. Namely, each invocation of performAction and
> getFragment must pass an entity handle so that the Producer would
> associate it with the relevant logical object.
>
> Persistent entities are pre-configured objects that are stored by the
> Producer.
>
> Transient entities are temporary copies of persistent entities that are
> supplied to enable the Consumer to use entities without the need to
> de-allocate them. One example I used in a previous e-mail is a page that
> has multiple copies of a map service, each with its own dynamic
> configuration data.
>
> Entities are always explicitly created by the Consumer.
>
> I think that the confusion lies in two areas (I hope that I am quoting
> people right, if not, please excuse me).
>
> Some people (Gil, Ravi) suggested that if we require the Consumer to
> create a transient entity each time it uses a remote portlet, then there
> is no need for a session object. This is because this transient entity
> can encode the session id. Others (Mike) claimed that this results in
> inefficiencies because the Consumer would have to maintain handles to
> transient entities which it doesn't really need.
>
> I think that the source of this confusion is the background. Requiring a
> transient handle is very natural in object-oriented thinking, where
> persistent entities (classes) are "instantiated" into transient entities
> (objects). Not requiring a transient handle is very natural in Web
> architecture thinking, where a single servlet (or a single entity) can
> serve multiple requests - whether that entity is persistent or even if
> it is transient.
>
> If we take the second approach and follow the Web architecture line of
> thinking, then (as Mike suggested) transient entities may be created
> arbitrarily by the Consumer for scoping purposes, and hence may span
> multiple users. That prevents them from providing a superset of sessions
> even if performance wasn't a consideration. This is not to say that it
> isn't likely that transient entities will be created on a per-user basis
> (just like persistent ones), only that it's completely arbitrary.
>
> It seems that we need to decide between the two options.
>
> If we take the second approach (the Web architecture one), then the
> transient entity concept is completely orthogonal to the concept of a
> session, which is a scope that allows the Producer to store data across
> portlets (and within an individual portlet, if no transient entities are
> used). The main lingering question around sessions is the mechanism
> around them. The mechanism proposed in the latest draft relies on
> explicit creation of sessions to support the entire functionality set,
> but this needs to be discussed further.
>
> Does this description make sense? Any observations from the debating
> group (Mike, Ravi, Carsten, Gil, Rich, ...)?
>
> ----------------------------------------------------------------
> 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