[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [wsrp] Soliciting a Discussion around Transient Entities
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, ...)?
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC