[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsrf] Modelling sessions
Folks,
I reply to Savas' mail, but this applies to William's and Jim's as well.
First, I'd like to thank Savas for a beautiful little use case that helps to
isolate the roles a WS-Resource can take in WS interactions and to highlight
how WSRF interplays with other WS technologies. Savas you are not causing
trouble I assure you. Keep it up.
I fully concur with William's description and would have written it myself,
but he got there first. To possible simplify it a bit we have the following:
1) A database of interest to us.
2) A WS providing functions on the database.
3) A context for controlling a logging function.
Therefore to talk to the database and log it we need the WS address, the
database's resource disambiguator, and the context. The first two form a
WS-Resource and the latter may be a WS-Context thing for example. Therefore
I like Savas' 4th case:
<envelope>
<header>
<context>
...
<sessionId>123</sessionId>
</context>
<databaseId>DatabaseA</databaseId>
</header>
<body>
<drop-database />
</body>
</envelope>
Now let's add an *optional* Web service to manage the context, e.g. in
William's example stop/start logging. Other operations might include
extending the detail or lease on the context. Therefore we add a new thing
to our list.
4) A WS for controlling a context.
Some things to note:
There is no requirement in the WSRF model that 3 and 4 be modelled as a
WS-resource. The WSRF model does not require that every entity be a
WS-Resource. The WS in 4 could simply take the old context as one of its
arguments and return a new one meeting the new requirements.
However, should I choose to model 3 and 4 as a WS-Resource, I get lifetime
management and WSDM style process management for free. Note that this
approach can be added to an existing context provider, since the id used in
the context is independent of the ReferenceProperty used to disambiguate the
context, i.e.
<TheContextsResId>12opaque34</TheContextsResId>
and
<sessionId>123</sessionId>
are different things, although they could be the same if their properties
are similar enough with respect to uniqueness requirements etc.
In specific answer to Jim's mail, I believe that the potential (but
optional) interplay I describe above is nicely layered in the spirit of WS
and quite elegant as well as functional. This kind of discussion is of
course helpful in verifying that WSRF can layer well with other WS concepts,
e.g. in this example WS-Context.
Thanks again to Savas.
On 25/5/04 21:30, "Savas Parastatidis" <Savas.Parastatidis@newcastle.ac.uk>
wrote:
> Dear all,
>
> Sastry Malladi (Oracle), Simon Laws (IBM), and myself have been involved
> in some work for GGF's Data Access and Integration Services (DAIS)
> working group, where we attempted to compare different approaches for
> mapping DAIS-specific requirements to underlying technologies. We
> explored the use of a WS-I only approach, an approach that uses
> WS-Context, and one based on WS-RF. (link:
> http://forge.gridforum.org/projects/dais-wg/document/draft-ggf-dais-mapp
> ings-ggf11/en/1)
>
>
> One of the questions that were raised during this work was how to model
> session-based interactions using WS-RF. I am hoping the members of the
> mailing list could help since we didn't reach a concrete proposal on how
> this could be done...
>
> Here's the problem...
>
> WS-RF is used to model stateful interactions with resources. Each
> message carries some information that identifies the resource behind the
> service which should be the logical receiver of the message. I hope my
> understanding is correct.
>
> Now, imagine a scenario where we want to establish a stateful
> interaction with a service (not the resource) and we want to associate
> some quality of service characteristics to it. Let's say, for example,
> that we want all interactions within the scope of a particular "session"
> to be logged. This would happen irrespective of which resource we are
> accessing.
>
> The problem arises if we attempt to model the session as a WS-Resource
> and at the same time we want to access another WS-Resource within the
> scope of that session. Let's say that we want to drop a database, which
> is modelled as a WS-Resource, and we want to log that action. This
> causes a problem since it's not possible for both resources to be
> addressed within one message.
>
> How do people in this WG recommend we approach this?
>
> There was a suggestion during the discussion we had that WS-RF would be
> used to model the database as a resource but additional mechanisms would
> be used to model the session (e.g., WS-Context). However, why would
> another mechanism be used? Isn't the intention of WS-RF to model all
> "resources" that require lifetime management? Isn't a session such a
> resource?
>
> So, if the solution is to not use WS-RF, then I would say... what's the
> point in defining a common solution when we can't use it in all
> situations? If the solution is to use WS-RF to model the session, then
> we have the problem of needing to address two resources within on
> message.
>
> I'd be grateful for any recommendations from the group.
>
> Here are some pseudo-SOAP messages to help illustrate the problem and
> how it is addressed by the other two approaches I mentioned...
>
> WS-I only
> ---------
> <envelope>
> <body>
> <drop-database>
> <sessionId>123</sessionId>
> <databaseId>DatabaseA</databaseId>
> </drop-database>
> </body>
> </envelope>
>
> WS-Context
> ----------
> <envelope>
> <header>
> <context>
> ...
> <sessionId>123</sessionId>
> </context>
> </header>
> <body>
> <drop-database>
> <databaseId>DatabaseA</databaseId>
> </drop-database>
> </body>
> </envelope>
>
> WS-RF ???
> -----
> <envelope>
> <header>
> <sessionId>123</sessionId>
> <databaseId>DatabaseA</databaseId>
> </header>
> <body>
> <drop-database />
> </body>
> </envelope>
>
> Or
>
> <envelope>
> <header>
> <databaseId>DatabaseA</databaseId>
> </header>
> <body>
> <drop-database>
> <sessionId>123</sessionId>
> </drop-database>
> </body>
> </envelope>
>
> Or
>
> <envelope>
> <header>
> <sessionId>123</sessionId>
> </header>
> <body>
> <drop-database>
> <databaseId>DatabaseA</databaseId>
> </drop-database>
> </body>
> </envelope>
>
> Or
>
> <envelope>
> <header>
> <context>
> ...
> <sessionId>123</sessionId>
> </context>
> <databaseId>DatabaseA</databaseId>
> </header>
> <body>
> <drop-database />
> </body>
> </envelope>
>
> Or
>
> <envelope>
> <header>
> <sessionId>123</sessionId>
> <databaseId>DatabaseA</databaseId>
> </header>
> <body>
> <drop-database />
> </body>
> </envelope>
>
> Of course the last one seems to be completely wrong. However, I can't
> see which of the other ones would be the preferred approach. Is there
> another way I can't think of?
>
> The combination of ws-context and ws-rf comes close to be the preferred
> one but then the question arises on why isn't the session modelled as a
> WS-RF since it has lifetime-related requirements. We could probably come
> up with other situations where a similar situation arises and where
> WS-Context cannot provide us with a solution.
>
>
>
> Please note that it is not in my intention to try and cause problems. I
> am just trying to better understand the proposed approach while hoping
> that this would be a useful discussion to the members of this WG.
>
>
>
> Regards,
> --
> Savas Parastatidis
> http://savas.parastatidis.name
>
--
Take care:
Dr. David Snelling <d.snelling@fle.fujitsu.com>
Fujitsu Laboratories of Europe
Hayes Park Central
Hayes End Road
Hayes, Middlesex UB4 8FE
+44-208-606-4649 (Office)
+44-208-606-4539 (Fax)
+44-7768-807526 (Mobile)
This e-mail has been scanned by Trend InterScan Software. This e-mail (and its attachment(s) if any) is intended for the named addressee(s) only. It may contain information which is privileged and confidential within the meaning of the applicable law. Unauthorised use, copying or disclosure is strictly prohibited and may be unlawful. If you are not the intended recipient please delete this email and contact the sender via email return. Fujitsu Laboratories of Europe Ltd (FLE) does not accept responsibility for changes made to this email after it was sent. The views expressed in this email may not necessarily be the views held by FLE. Unless expressly stated otherwise, this email does not form part of a legally binding contract or agreement between the recipient and Fujitsu Laboratories of Europe Ltd (FLE).
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]