[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [no subject]
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]