[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: 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 -
Service - e.g. stock service, weather service.
Container - a container of services.
I suggest we close this terminology issue quickly.
(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:
1. To enable a service to have state that is scoped to the user session.
Example: have the service remember which stock the user wants details on (or who the user is, and whether the user is authenticated).
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.
I suggest we close this issue quickly.
So - to summarize this "short" email (and assuming that the "Session Handle" and "Transient Entity Handle" concepts are OK with everybody) - I suggest:
1. We resolve naming issues of Container-Service/Producer-entity.
2. We resolve whether a Transient Entity Handle is in the scope of the end user session or not.
After that we can start resolving the following issues:
1. Who creates those handles?
2. Is it implicit or explicit creation?
3. Who "destroys" those handles?
4. What is the SOAP endpoint - the service or the container?
And after that we can start to resolve the persistency issue...
Powered by eList eXpress LLC