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: Re: [ogsi-wg] RE: [ws-caf] WS-Resource Framework

Jeffrey, after having read through the WS-R specifications, I fail to see
any subtle or not-so-subtle distinction. Maybe this is due to
misundertanding of WS-R on my part, or perhaps a misundertanding of
WS-Context on yours, but I'd like to explore the perceived mismatch.

Whilst it is true that the types of context to which you refer allow for an
interoperable understanding between client and server, I think that misses
the real point of WS-Context in general: to allow the unambiguous
correlation of a set of messages sent to a (set of) endpoints in an
implementation (or context specific) manner; the endpoint may use that
context to associate a specific state to itself prior to performing any work
that may be implied by the receipt of those messages.

I think we're agreed that context goes beyond transactions, but if you take
transactions for a second, let's look at the X/Open XA specification and
particularly how a type of context is used within that. Within XA,
transactions are identified by XIDs and a given resource manager
(essentially the entity that controls the way in which data is transacted to
a back-end database) may multiplex across many different transaction
instances. So, for example, in the C API for XA, there is a struct
(xa_switch_t), that has operations for preparing, committing, rolling back
etc. transactions and each of those operations takes an XID to identify the
transaction (state) on which it should operate: only one instance of the
struct exists. So, you could have an XA service that receives messages to
commit (say) a transaction and the context for that message would be an XID
that the service uses to determine which state instance to manipulate.

What I hope I've illustrated is that context isn't just used to tie together
endpoints for interoperability: it can be used to unambiguously identify
stateful instances in precisely the same way that is shown in the example
pattern from the ModelingState (page 12). Or did I miss something?

In fact, if we look at the schema from that example:


the same thing can be achieved using context (in pseudo-code):

<wsctx:context>C</wsctx:context>   <--- appears in the header block


The endpoint that receives both message types has to parse the message and
determine the circumstances in which it can be used, i.e., in this case the
state to which it should be applied. The only difference I can see is that
in WS-R, the context for the message is embedded in the endpoint reference,
whereas in WS-Context it's in the header. But something (whether you call it
an interceptor, XML processor handle, or whatever) has to pick apart the

You say that there's nothing extra needed in terms of a handler over and
above what's already in WS-Addressing, but isn't that just saying that
because you leverage something that has handlers, you don't have to redefine

And in both cases it can be just as opaque to client and service.

Although your interpretation of how WS-Context *may* be used is certainly
correct, the fact is that we've seen many different use cases for context
that show the general notion of a context should not be limited to a
specific use case. Identifying state at an endpoint is possible by a
correlation id (e.g., a cookie), and in fact state can be encoded within a
context for purely stateless services.

I think as Savas started to elucidate, identification of stateful instances
via context also appears to be a lot easier when you have mutliple services
in the same interaction. With context, the invoker of a set of services
would typically selects the relevant context id that represents a specific
set of stateful services and all of the services see the same context id and
map that to whatever state is appropriate for that interaction. It would
appear from the WS-R documents that in a similar scenario, each stateful
service generates a different resourceID that somehow the invoker would need
to tie together into a collaborative effort. What I mean by this is that the
invoker of those multiple stateful services would need to remember each of
the resourceIDs (or rather their unique EndpointReference). That seems like
a rather heavyweight approach and one which appears to have scaling

You also mention that the WS-R "context" is only produced by the service,
rather than by the client in WS-Context. However, that's wrong - the context
does not have to be produced by the client in WS-Context and in fact can be
augmented by each service. So, a "blank" context could be received by a
service that then operates on some state which the client needs to
unambiguously identify later, and in which case the service can add the
state identification to the context that flows back to the client (or
recipient of the response).

It may be that the model outlined in the WS-R documents for representing
stateful instances is more ideal for the Grid environments in which it has
evolved. But in that case, it's worth pointing out that a generic notion of
context can also support that. WS-Context has an explicit (though optional)
context element for identifying the endpoints that are participating in an

So, in conclusion, I may be totally off-base here in my understanding of the
WS-R specifications, but I don't see a distinction between them and what
WS-Context is attempting to achieve. If you take a very restrictive view of
what context is, then I can understand why you may think there are
differences. However, we haven't taken that restrictive view. Maybe its
approaching the same problem from different ends of the spectrum and in
which case I'd echo Eric's original question about whether some level of
convergence makes sense.

All the best,


Mark Little,
Chief Architect, Transactions,
Arjuna Technologies Ltd.

----- Original Message ----- 
From: "Jeffrey Frey" <jafrey@us.ibm.com>
To: "Ian Foster" <foster@mcs.anl.gov>
Cc: "Newcomer, Eric" <Eric.Newcomer@iona.com>; <ogsi-wg@gridforum.org>;
<owner-ogsi-wg@gridforum.org>; "Savas Parastatidis"
<Savas.Parastatidis@newcastle.ac.uk>; <ws-caf@lists.oasis-open.org>
Sent: Friday, January 23, 2004 6:11 PM
Subject: Re: [ogsi-wg] RE: [ws-caf] WS-Resource Framework

I agree with Ian. There is a subtle but important distinction. Context, as
referred to in WS-Context, is explicitly declared and meant to facilitate
an interoperable understanding between the client and the service. For
example, a transactional unit of work is something that can be established
by the client and sent to the service in a well known context that
accompanies the message to the web service. The same is true for contexts
that represent security function, etc. This is not the same as what we have
introduced with the WS-Resource. There is no need to declare the
WS-Resource context for interoperability reasons. The WS-Resource "context"
is not produced by the client. It is produced and consumed by the service.
It is carried in the EPR as an opaque construct to the client. There is no
need for the client to interpret or inspect the contents of the reference
properties. In fact, there is no additional "context" handler required at
all on the client side of the interaction other than what is already
generically specified in the WS-Addressing specification. So, while I can
understand that this appears to be the same at an abstract level of
understanding, we did not intend the identity of the resource as it is
treated in the EPR to be interpreted as "context" in the same way other
usage context is produced and consumed across the web service interaction
with the client.

In addition, while we know some have an aversion to the treatment of the
stateful resource as a "first class" addressable entity or as the implied
target of the interaction from the client., some do not. And if your view
is that the resource is the "target" of the message interchange from the
client the service, our view is that it should be treated as distinct from
other execution contexts which exist not for the purpose of identifying the
target of the message exchange, but to provide additional control over how
the target of the message exchange is to be treated. WS-Context should be
used to facilitate the contextual usage of the target of the message, not
the target of the message itself.

Jeffrey Frey

IBM Distinguished Engineer
OnDemand System Architecture and Design
Phone: 845-435-3067  Tie: 8-295-3067  Cell: 914-456-6556
Notes: Jeffrey Frey/Poughkeepsie/IBM@IBMUS
Internet: jafrey@us.ibm.com

|         |           Ian Foster       |
|         |           <foster@mcs.anl.g|
|         |           ov>              |
|         |           Sent by:         |
|         |           owner-ogsi-wg@gri|
|         |           dforum.org       |
|         |                            |
|         |                            |
|         |           01/22/2004 05:34 |
|         |           PM               |
|         |                            |

  |       To:       "Savas Parastatidis"
<Savas.Parastatidis@newcastle.ac.uk>, "Newcomer, Eric"
<Eric.Newcomer@iona.com>               |
  |       cc:       <ws-caf@lists.oasis-open.org>, <ogsi-wg@gridforum.org>
  |       Subject:  Re: [ogsi-wg] RE: [ws-caf] WS-Resource Framework



We (the WSRF authors) are very familiar with WS-Context and certainly agree
that it has an important role to play.

However, we also believe that there are important situations in which
stateful resources need to be identified and managed as first-class
entities: thus WS-Resource Framework. Thus the enthusiastic response we are
seeing to the proposal from the IBM and HP Web services teams, as well as
many others.


At 10:06 PM 1/22/2004 +0000, Savas Parastatidis wrote:

      Dear Eric,

      I agree with your comments. In fact, back in August 2003 we used
      WS-Context as an example of how stateful interactions and/or
      distributed units of work could be modelled. This was part of our
      proposals for a WSA-friendly framework for building Grid applications


      Savas Parastatidis

      From: Newcomer, Eric [mailto:Eric.Newcomer@iona.com]
      Sent: Thursday, January 22, 2004 6:28 PM
      To: Mark Little; Savas Parastatidis; ws-caf@lists.oasis-open.org
      Subject: RE: [ws-caf] WS-Resource Framework

      I have the general impression of the OGSA specs as the equivalence of

      On the topic of the WS-Resource Framework in particular, I've looked
      through the specs and I think WS-Context could have been used, and
      it's unfortunate it wasn't.  I suppose the Resource Framework effort
      grew out of the Grid work however so it has a completely independent

      I also agree that I can't see a practical difference between context
      management in transactions and the context management defined for the
      Resource Framework.

      It would be nice to try to converge these things at some point and in
      some organization - is that OASIS?

Ian Foster                    www.mcs.anl.gov/~foster
Math & Computer Science Div.  Dept of Computer Science
Argonne National Laboratory   The University of Chicago
Argonne, IL 60439, U.S.A.     Chicago, IL 60637, U.S.A.
Tel: 630 252 4619             Fax: 630 252 1997
        Globus Alliance, www.globus.org

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