OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ws-caf message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: FW: [ogsi-wg] RE: [ws-caf] WS-Resource Framework

After Sastry’s request, I am forwarding his message (sorry I didn’t do that earlier. I thought Sastry was subscribed to WS-CAF).


Savas Parastatidis
http://savas.parastatidis.name (now blogging)

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
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
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
- 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,

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]