[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsrf] Modelling sessions
Hi Savas, As you pointed out in your follow-up email, if you don't want the request to be made as part of the session you just don't include the context header. It's then up to the WS-Resource, based on its policy, to decide whether a session id is required for the message to be processed or not. Regarding the choice between using a domain-specific <drop-database/> message or a WS-RL <wsrl:Destroy/> message, the focus of the discussion was on addressing, not on the payload. Without a more complete use case, I don't really have a recommendation between the two. If the drop-database request expects the database to be destroyed and does not imply any other behavior (like backing it up first or doing things in a special way for a symbolic linked database) then using <wsrl:Destroy/> is an option. Which doesn't mean it has to be used. Finally, if you want to drop two databases at once I can see two options. If this is a common operation and most of your interactions are at this level, you might want to address the database server, not the databases themselves. Even when you are using WS-Resources, the designer picks what to model as a resource. The DB server, each DB or even each table. Depends on what works best for your use case. The other option, if you decide to model each DB as Ws-Resource, is to create a service group to contain a set of databases that you manage together. Currently, WS-ServiceGroup does not support invocation of operations on members of the group, but this is something that we are going to need for management (see WSMF Collections). Regards, William > -----Original Message----- > From: Savas Parastatidis [mailto:Savas.Parastatidis@newcastle.ac.uk] > Sent: Thursday, May 27, 2004 4:38 AM > To: David Snelling; wsrf@lists.oasis-open.org > Cc: Sastry Malladi; Simon Laws > 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. > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]