From: Sastry Malladi
[mailto:sastry.malladi@oracle.com]
Sent: Tuesday, January 27, 2004 11:09
PM
To: Savas Parastatidis;
ogsi-wg@gridforum.org; ws-caf@lists.oasis-open.org
Subject: Re: [ogsi-wg] RE:
[ws-caf] WS-Resource Framework
Let me jump in, if I may, and make the following
observations.
There are two problems we are dealing with here.
1. How to do stateful interations with a resource, front-ended by a web service
2. How to identify a resource front-ended by a web service.
As I see it, these are two different, but equally important issues. Let me
explain a bit further
on what (1) and (2) mean.
By 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.
But 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 service.
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
sent across in headers, if that information is available somewhere. This
sending of
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
ResourceProperties/Description document,
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 solution.
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
any standards body)
Savas Parastatidis wrote:
Hey all,
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
couldn't
have been achieved with WS-RF. If you look at the paper that Savas et
al.
produced many months ago, doesn't that map to precisely the same
goals,
but
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
often :-)
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
interactions.
- 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
ideas: http://www.neresc.ac.uk/ws-gaf/AboutWSGAFApplication.html.
Best regards,
.savas.