Alan,
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.
Producer/Service
-------
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).
Transient Entity/Session
--------
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...
Cheers,
Gil
-----Original Message-----
From: Alan Kropp [mailto:]
Sent:
Thursday, June 06, 2002 02:58
To: ;
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>
