wsrf message

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.