[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsrf] Modelling sessions
Savas Parastatidis wrote: >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? > > > This is a serious liability. Perhaps there is a solution that I'm not seeing or aware of? From my perspective, it seems there is a trivial solution: the implied resource pattern should be abandoned in favor of the explict use of schema types to deal with resources in message bodies. Fortunately this is the way web services were meant to work, so it would have the happy side effect of bringing the grid/management specifications that are derived from web services back into alignment with work that is going on in the broader community. I realize this would impact the schedule of the TC, but I suggest it would ultimately accelerate adoption and use since the full spectrum of web services technologies, tools and infrastructure could immediately support the output of the TC. >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]