OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrp message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


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



By arbitrarily placing some questions on hold, one can easily walk into an
architecture that is not deployable on todays infrastructure. An example of
this is that we have already explored attempting to make the WSDL service
endpoint the 'service' (to use the terms you picked) when the actual web
service invocations must be first handled by the 'container' (this is the
WSRP case). The answer to that exploration was a quite firm "no". The
implications of this include needing to indicate the target 'service'
(hence the transientEntityHandle). The desire that has been expressed for
permitting 'services' within a 'container' to share stateful information
through a shared session (as is available using todays web application
model) has led to a separate definition of a session. While it is clear
that a session should be scoped to an end-user, there have been good
arguments put forward for scoping the transientEntity to the Consumer
(though this would also allow the Consumer the choice to scope it to the
end-user).


                                                                                                                    
                      Gil Tayar                                                                                     
                      <Gil.Tayar@webcol        To:       "'wsia@lists.oasis-open.org'" <wsia@lists.oasis-open.org>, 
                      lage.com>                 "'wsrp@lists.oasis-open.org'" <wsrp@lists.oasis-open.org>           
                                               cc:                                                                  
                      06/06/2002 06:33         Subject:  RE: [wsia] [wsrp] [wsrp-wsia joint interfaces]             
                      AM                        sessions/entities                                                   
                                                                                                                    
                                                                                                                    
                                                                                                                    



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: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>










[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC