Re: [wsrf] Modelling sessions

[Sastry Malladi <sastry.malladi@oracle.com>]

Thomas Freund wrote:

> Savas & all,
>
> Reading the referenced article 
> http://forge.gridforum.org/projects/dais-wg/document/draft-ggf-dais-mappings-ggf11/en/1
> by Savas, Sasty & Simon it is clear what you are is citing scenario 2, 
> 'Sessions'. However, the article clearly points out that a range of 
> possibilities exist (i.e. after all the WS-* standards are meant to be 
> composable). So scenario 2 in the article illustrates that a.) 
> sessions & resources can be represented entirely using WS-RF (5.2.3.1) 
> or b.) sessions can be represented using either WS-I or WS-Context 
> along with a WS-RF resource (5.2.3.2)
>
> The article makes no value judgement. It also apparent from some of 
> the responses that others have repeated this message (that depending 
> on the requirements) a vendor has the flexibility to implement in any 
> fashion he choose.
>
This document is meant to be an informational document that explains the 
various alternatives and hopefully in the process, the pros and cons
of each of the approaches is either apparant or at least will fuel such 
a discussion. Keeping this in mind, and per our initial goal of the article,
we didn't explicitly add any recommendations there. That could perhaps 
be done in a seperate article.

Speaking of modelling sessions using WS-RF, we haven't dwelled into this 
much in the document, although section 5.2.3 may have
mentioned that it is possible to do sessions using RF, but the way it is 
done (or suggested) is using WS-Context and NOT using a WS-Resource.
This is touched upon in summary section (section 6)  in the table under 
the item "Stateful interactions with data services".
But I think the feedback that I take is that this information may not be 
clear from reading the document and we need to make it clearer.


> I believe the important thing here is to emphasis that this is not an 
> either/or proposition (i.e. the answer it's not necessarily all 
> WS-I/WS-Context nor is it all WS-ResourceFramework).
>
> My preference for scenario 2 would be to model sessions as 
> WS-I/WS-Context and stateful resources using WS-RF. It follows a 
> 'pattern' which we are very familiar. However I'm not sure that answer 
> necessarily satisfies everyone & certain it does not apply to every 
> scenario (or as I said before that one pattern does not necessarily 
> 'fits all' situations).
>
> Regards,
> Tom
>
> "Savas Parastatidis" <Savas.Parastatidis@newcastle.ac.uk>
>
>
>                         "Savas Parastatidis"
>                         <Savas.Parastatidis@newcastle.ac.uk>
>
>                         05/27/2004 06:37 AM
>
> 	
>
> To
> 	
> "David Snelling" <d.snelling@fle.fujitsu.com>, 
> <wsrf@lists.oasis-open.org>
>
> cc
> 	
> "Sastry Malladi" <sastry.malladi@oracle.com>, "Simon Laws" 
> <simon_laws@uk.ibm.com>
>
> Subject
> 	
> RE: [wsrf] Modelling sessions
>
> 	
>
>
> All,
>
> Thanks for all your replies. I have quite a few follow-on questions but
> I will try to send them few at a time so we all get the chance to think
> about the issues. (Sorry Dave, you shouldn't have encouraged me :-)
>
>
> From the replies I now understand that a session-based interaction with
> a data access service does not have to be modelled as a WS-Resource. It
> was suggested by William and David that WS-RF could be used to model the
> session for management purposes. As others have pointed out, however,
> this is unlikely to be the case because the WS-Context specification,
> since it defines a protocol, it describes its own lifetime requirements
> and means for management. The WS-Context spec knows the exact
> requirements for lifetime management, it provides a solution that fits
> well with the model, and it's unambiguous.
>
> However, the suggestion that the session could be modelled as a
> WS-Resource for management purposes has another drawback. The "session"
> is an application-specific concept; in this case, it is a stateful
> interaction with a data access service. We use WS-Context to model a
> session as an external-to-the-service entity. Each service has its own
> understanding of what the session means to it even though the same
> context is used.
>
> Here's an example of what I mean...
>
> Let's say that we now have 2 data access services. We say that our
> context models a session in which all messages are logged. What the
> services will do when they receive that context, it's up to them.
>
> We could send these two messages to the two services...
>
> To service1
> --------
> <envelope>
>  <header>
>    <context>
>      ...
>      <sessionId>Session123</sessionId>
>      <logging>true</logging>
>    </context>
>  </header>
>  <body>
>    <drop-database>databaseA</drop-database>
>  </body>
> </envelope>
>
> To service2
> -----------
> <envelope>
>  <header>
>    <context>
>      ...
>      <sessionId>Session123</sessionId>
>      <logging>true</logging>
>    </context>
>  </header>
>  <body>
>    <drop-database>databaseB</drop-database>
>  </body>
> </envelope>
>
>
> As you can see, the context is the same. What each service does with
> regards to the session (modelled by the transmission of the context),
> it's up to the service. So, one could imagine a message only to service
> 2 like this...
>
> <envelope>
>  <header>
>    <context>
>      ...
>      <sessionId>Session123</sessionId>
>      <logging>true</logging>
>    </context>
>  </header>
>  <body>
>    <end-session />
>  </body>
> </envelope>
>
> Now, the <end-session> message is not related to WS-Context. Instead, it
> says to the application logic not to do anything application-specific
> with regards to the current context from now on (I hope I am not
> misunderstanding the use of context... I am sure the WS-Context people
> will correct me if I do). The context has not been destroyed. In fact,
> it may still be used with service1. However, as far as service2 is
> concerned, there is no association between the session (the
> application-specific concept) and the context (the conceptually external
> entity that models the stateful interaction).
>
> What this means is that we have, again, a lifetime-related operation. It
> is clear, however, that WS-Resource Lifetime cannot be used because the
> semantics of the message (the application payload) are only understood
> by the service logic.
>
>
> Furthermore, David agreed that this message
>
> <envelope>
>  <header>
>    <context>
>      ...
>      <sessionId>123</sessionId>
>    </context>
>    <databaseId>DatabaseA</databaseId>
>  </header>
>  <body>
>    <drop-database />
>  </body>
> </envelope>
>
> would be the way to go with WS-RF. But wait a minute (no one picked on
> that)... If DatabaseA is modelled as a WS-Resource, why isn't the
> <drop-database> a WS-Resource Lifetime message? After all, we are
> destroying the database, which is modelled as a resource. I think that's
> another example whether WS-RF wouldn't be used.
>
>
>
> Finally, with the WS-I or WS-Context approaches, it's very easy to say
> this...
>
> <body>
>  <drop-database>
>    <databaseId>databaseA</databaseId>
>    <databaseId>databaseB</databaseId>
>  </drop-database>
> </body>
>
> If both databases were modelled as WS-Resources what would the message
> be? Would I have to send two messages, as it would be the case with any
> other object-based technology?
>
>
> I hope you treat these questions as a way to investigate and better
> understand the applicability of WS-RF and its conceptual model and not
> as more fuel to a religious argument.
>
> Regards,
> .savas.
>
>
>