[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsrf] Modelling sessions
Hi Savas, Interesting question. My 2 cents: In your scenario, I think it is ok to model both the session and the database as WS-Resources. They are both stateful resources and can get their own reference. When times comes to send messages, you have to ask yourself "what resource is this message for?". If it is a "start logging" or a "stop logging" message then clearly the message is going to the "session" WS-Resource. If the message is to say "drop the database" or "add this in the database" then clearly the target is the database WS-Resource. The key is that each message is meant for one and only one WS-Resource (let's leave aside for now things like collections are they are not part of the base model). So, in your example the message is intended for the database WS-Resource and so should carry the necessary headers, described by the reference for the database WS-Resource. The fact that this message exchange is part of a session and should be logged is metadata. The fact that another WS-Resource exists (the session WS-Resource) that is related to this meta-data is irrelevant to what goes in the "drop the database" message. So, at first view, what your use case brings to mind for me is the need for better metadata support on WS-Resources. Not the needed to address two WS-Resources at once. With some metadata support on WS-Resource, the way your example can be addressed is to have the interface of the database WS-Resource express the following policy: "I can participate in interactions that are WS-Context qualified". The invoker will look at the reference to the database WS-Resource and find out from this reference what header to put in the message (in your example <databaseId>DatabaseA</databaseId>). It will also find the policy statement and know, from the policy statement and internal knowledge of current sessions, how to indicate which session is used (<context><sessionId>123</sessionId></context>). As a separate matter, there might be a WS-Resource out there which allows you to manage the session used in the previous interaction (for example turn logging on/off). But for the sake of the previous interaction, the fact that such a WS-Resource exists is irrelevant. Regards, William > -----Original Message----- > From: Savas Parastatidis [mailto:Savas.Parastatidis@newcastle.ac.uk] > Sent: Tuesday, May 25, 2004 1:31 PM > To: wsrf@lists.oasis-open.org > Cc: Sastry Malladi; Simon Laws > Subject: [wsrf] Modelling sessions > > > 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 > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]