RE: [wsia] [wsrp] [wsrp-wsia joint interfaces] sessions/entities

It seems you saved me from writing a very long document summarizing a chat I had with Mike. As you all know, I have this continuous nagging feeling that we are using the same term to mean different things. I think your email nails things down, but I would like to add my refinemenets to it.

In the WSIA world, the Producer is the service the end user. So for example, if I have a stock service and a weather service, then those are two Producers.

In the WSRP world, the Producer is a container of services. So for example, if I have a stock service and a weather service, they may belong to the same Producer, or be part of two different Producers.

To consolidate the two, we have two options - one is to use Producer as the name for the container (WSRP-like) and one is to use the Producer as the name for the service (WSIA-like). To avoid choosing in this email, I will use a neutral terminology -

(I will not enter the discussion of whether the SOAP endpoint is connected to a Service or to a Container, and I hope that others will follow my lead and not discuss it in this thread - in the interest of scoping this discussion).

The question is, what are those terms, and why do we need two "handles" to two types of information (transient entity information and session information) where one can suffice? The answer is in a set of requirements:

2. To enable two services, even if they are of the same type, to have state that is scoped to the user session.

Example: two stock services on the same page, each one displaying information about a different stock.

3. To enable multiple services coming from the same container to share information, again scoped to the user session.

Example: if the stock service read user information (stock portfolio and weather cities) and caches it in memory, let the weather service access that data instead of re-reading it from the database.

4. To enable two services, even if they are of the same type, to have state that is scoped to the Consumer.

Example: I would love an example, but I can't find one.

From here, the definition of Transient entity and session (as defined below) can be refined by defining which requirement it appears to solve. Let's start by defining the two terms:

Session Handle - a handle which the Consumer MUST pass to all operations sent to a specific Container (and all its services). The Session Handle's lifetime is determined by the Consumer, but it SHOULD be in the lifetime of the end user session.

Transient Entity Handle - a handle which the Consumer MUST pass to all operations sent to a specific service (e.g. the two stock portlets in example #2 receive two distinct handles). The Transient Entity Handle's lifetime is possibly in the lifetime of the end user session.

(I do not want to go into the question of who creates what when (i.e. the mechanism of these two handles), and I hope that others will follow my lead and not discuss it in this thread - in the interest of scoping this discussion)

The problematic word in the definitions above is the word "possibly" marked in bold (the only "possibly" word in the Transient Entity Handle definition for those of you that receive text).

If the Transient Entity Handle is in the scope of the end user session, then requirement #1, #2, #3 are obvious - reference data for requirements #1 and #2 via the Transient Entity Handle, and #3 via the Session Handle.

OTOH, this creates a lot of handles that the Consumer has to manage (assuming that there are many services and few containers), and may load a Consumer's resources. Also, #4 must be satisfied via another mechanism.

If the Transient Entity Handle is not in the scope of the end user session, but in the scope of the Consumer, then requirements #1 and #3 are obvious - reference data for requirements #1 and #3 via the Session Handle, and #4 via the Transient Entity Handle. OTOH, requirement #2 is non-obvious and involves divising a schema to aggregate references to #2 information inside the Session Handle, using the Transient Entity Handle. This makes it difficult to write a Service that is oblivious to the fact that it appears in the same page a multiple number of times.

So - to summarize this "short" email (and assuming that the "Session Handle" and "Transient Entity Handle" concepts are OK with everybody) - I suggest:

-----Original Message-----
From: Alan Kropp [mailto:akropp@epicentric.com]
Sent: Thursday, June 06, 2002 02:58
To: wsia@lists.oasis-open.org; wsrp@lists.oasis-open.org
Subject: [wsia] [wsrp] [wsrp-wsia joint interfaces] sessions/entities

Here's my thinking on this topic based on our discussion from Tuesday, and
I'd like to make the plug that we come to consensus on this point soon.

Transient runtime data lives in a session associated with the Producer (WSRP
portlet container). Typically the consumer makes an explicit request to the
Producer to create a session. A producer has the ability to create a
session implicitly, at which point the consumer MUST (MAY?) scope subsequent
requests by including the ID for this implicit session.

An entity is the runtime representation (manifestation?) of a Producer
service (WSRP portlet), and is identified by an opaque reference. The
consumer makes an explicit request to the producer to create an entity, and
makes requests of that entity, possibly scoped to a session (see above), for
markup and/or action routing.

The producer determines how to relate entities to sessions and vice versa.
In the portlet case, the container MAY (and most likely will?) maintain a
single session on behalf of a single consumer's interaction with all
entities under its management. Transient data is 'partitioned' according to
some as-yet unidentified scheme, so that the producer may apply the correct
end-user runtime state as the context for a given request.

Thoughts?

Alan

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

wsia message