OASIS Web Services Interactive Applications TC

 View Only

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

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

    Posted 06-06-2002 08:40
     MHonArc v2.5.2 -->
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    

    wsia 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