agree with most of what you said. I would state the problems we are attempting
to solve a little differently:
do you associate a context with a set of messages exchanged by stateless Web
do you interact with stateful resources by using a stateless Web
WS-Context does a good job at defining how to exchange information in
messages such that a context can be established for the processing of those
WS-ResourceProperties does a good job at specifying a standard pattern
for allowing a Web service to represent several resources and their changing
states. The implied resource pattern indicates which resource you are
interacting with from any given message.
Let me jump in, if I may, and make
the following observations.
There are two problems we are dealing with
1. How to do stateful interations with a resource, front-ended by a
2. How to identify a resource front-ended by a web
As I see it, these are two different, but equally important
issues. Let me explain a bit further
on what (1) and (2) mean.
stateful interactions, what I mean is that, when a service receives a message,
it needs to be able to
figure out whether this message is related to (or
associated with) any previous messages(s) and if so,
process this message
in the context of the previous messages. If not, this message is on its own
and could be
processed differently without any previous context. At an
implementation level, we could use WS-Context
and send some kind of a
"session id" and referenced to all the involved participant, in
the message header in the form
of a context. This way, the service or
resource can maintain and associate a "conversational" state.
before we can send messages to a service, we need to identify and locate the
service. This could just be
a URL or some construct that has the service
address as well as a resource identity. As an example,
lets say there
is a BankAccountService and there is a URL using which you can connect to this
However, an "account number" needs to be specified to identify
which account you are dealing with.
Now this "account number" can be passed
as a parameter to your service operations or it can be implicitly
across in headers, if that information is available somewhere. This
the identity can still be done, at an implementation level,
using WS-Context, as an example. However, it needs
to be specified
somewhere. I'd ideally like it to be specified in a the
but I'll get to that point later
in another email.
So from this point of view, I see no conflicts
between WS-Context and "declaring" identities of the resources. I think
it will be good
if WSRF specs normatively specify a WS-Context
header that is used to send/receive resource identities
(note that the
identity itself can still be declared elsewhere - either in
the EPR or resource properties document), so we
have an interoperable
Having said that, we still have an issue with the use of
WS-Addressing as it is currently not a standard (i.e, not submitted to
Savas Parastatidis wrote:
Since Mark asked for my comment...
I'm still waiting to see what the real differentiator is in the useage
pattern, the interaction pattern, or whatever that means that this
have been achieved with WS-RF. If you look at the paper that Savas et
produced many months ago, doesn't that map to precisely the same
using WS-Context at the core? Hopefully Savas can comment on this too.
[...] (lots of [...])
Mark, I agree with your arguments (I know... that doesn't happen very
In our paper all those months ago we wanted to present a way to do
stateful interactions in a service-oriented fashion. WS-Context provided
us with the means to do just that. We wanted to model stateful
_interactions_ through message correlation.
There are many ways for doing this:
- BPEL uses properties from application messages to model stateful
- One could use information in the messages to explicitly correlate
messages (e.g., order numbers explicitly sent as "arguments" to
operations) (similar to the above really).
- One could overload the semantics of a service and introduce "service
instances" (the OGSI approach and we know how that ended).
- Or, contextualisation could be used. WS-Context was the only
specification at the time explicitly talking about contextualisation
(and still the only one as far as I know).
Your choice of any of the above methods is application-specific. If you
want to model stateful interactions with a particular resource, you
could do it with any of the above ways. The WS-RF authors decided to use
WS-Addressing, which is fine. It means that parts of a WS-Address
structure will have to travel as headers in a message. It's a form of
contextualisation. However, it's not different from WS-Context which
scales better to multiple participant interactions. I can't see how this
could be done with WS-Resources.
Could WS-RF have used WS-Context? Sure! No doubt about that.
I would welcome an effort by the two communities to bridge their
differences. Until then... let's build some applications to test the