[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ogsi-wg] RE: [ws-caf] WS-Resource Framework
> Hi Mark, Hi William. I think we're still talking about precisely the same thing and as I said in the earlier email it seems like you've got a very restrictive viewpoint for what WS-Context does. If you consider the wider meaning of context (and that's the meaning that WS-Context takes) then they aren't orthogonal at all, and my earlier email illustrates that. (At least I thought it did.) As I said in that email, whilst it is true that context can be used to correlate messages sent to individual web services in a "message A should be performed in a way related to message B and C via ctx id X", it's also true that the context can be used in a "message A should be performed related to your prior state X, which by the way so will messages B and C". If you actually look at the WS-Context spec. and schema you'll see that the context definition itself doesn't have to mention B and C at all (the default one doesn't). It really is up to the recipient of the context (the service) to determine how to use the information in the header. A single service endpoint can multiplex over an arbitrary number of "back-end" state instances using the information within the context. (And this isn't even revisiting the argument of how an application might use the context to group multiple endpoints/states into the same interaction, ensuring consistent state manipulation across all of them for that specific interaction instance). I hate to use the word context in the following sentence because it'll probably lead to confusion so I'll * it to make sure we understand it's the English term I'm using: the WS-Context information is used to place messages into *context* (circumstance, relation, meaning); it's not limited to what you may be assuming in terms of a security context or transaction context (though even there I showed that there is an exact mapping to the pattern shown in the WS-R document). And this way of using context isn't just a happy coincidence - it's one intended use pattern from the requirements we obtained by talking to Web services vendors and users. So I need to reiterate this point: WS-Context and WS-R are not orthogonal as far as I can see. Now maybe you're argument is that WS-Context is too general? If so, come on over to the OASIS WS-CAF technical committee where we'd love to have your interaction. > > To a large extent WS-Context and WSRF are orthogonal. WS-Context defines > a way to convey, in messages, the fact that some of these messages are > related to one another. WS-Context doesn't care about what this means. I don't understand why you say that WS-Context doesn't care about what the information means. Are you saying that the sender of a WS-R message cares about the endpoint data in a different manner? The sender of a WS-Context enhanced message would do just the same thing. In both instances the sender needs to know a priori that the recipient is the right "instance"; it does this by defining some "meaning information" in the message being sent; whether that is as additional information in the address (akin to a CORBA object identity asWS-R seems to do) or related to the message (as WS-Context does) is a matter or pattern only, but they both require the recipient end-point to understand what that information is and how to use it. > I > agree with you that nothing in WS-Context prevents this correlation > mechanism to be used to express the fact that the messages are > correlated for the purpose of expressing that their processing should > apply to a specific resource. > > WSRF doesn't specify how the messages are correlated. The only thing it > specifies is how to create an endpoint reference that indicates how the > messages are correlated. This sentence doesn't seem to parse. The reason I'm confused here is you say that WS-R doesn't say how messages are correlated only how the messages are correlated? Do you mean it only provides a means of correlation at the service? If so, I've also shown how that pattern applies in WS-Context. Correlation is correlation - it doesn't really matter how you cut it (unless for political reasons). > Nothing in WSRF prevents WS-Context headers to > be used for correlation. Quoting from your email: > > > <wsa:EndpointRefrence> > > <wsa:Address> > > http://.... > > </wsa:Address> > > <wsa:ReferenceProperties> > > <tns:resourceID>C</tns:resourceID> > > </wsa:ReferenceProperties> > > </wsa:EndpointReference> > > > > the same thing can be achieved using context (in pseudo-code): > > > > <wsctx:context>C</wsctx:context> <--- appears in the header block > > > > <wsa:Address> > > http:// > > </wsa:Address> > > Nothing prevents tns:resourceID from being wsctx:context in the endpoint > reference: > > <wsa:EndpointReference> > <wsa:Address> > http://.... > </wsa:Address> > <wsa:ReferenceProperties> > <wsctx:context>C</wsctx:context> > </wsa:ReferenceProperties> > </wsa:EndpointReference> But you could just remove the ReferenceProperties altogether. You seem to be arguing that WS-R and WS-Context could be used *together*, whereas what I'm saying (and what others have also said) is that WS-Context could be used *instead* of WS-R. > > > 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 there is no requirement that the endpoint reference be sent in the > message. According to WS-Addressing, the address information is used by > the sender but what needs to be in the message is the content of > wsa:ReferenceProperties, using the ways specified by the binding. Which, > for SOAP means as a SOAP header. So the message would look like a > perfectly compliant WS-Context message, carrying a WS-Context header. And precisely how is this different from what WS-Context does and the example I gave? I'm sorry, but you seem to be arguing for the fact that WS-Context can be used here instead. > > WSRF is not about how to correlate messages, it is about providing > useful features (like properties and lifecycle) when message correlation > is used to express access to a resource through a Web service. And context is related to lifecycle and properties. As I said in an email to Ian, I think this is something that can't really be argued from a technical perspective: as far as I can see, there is no reason why WS-Context (or context in general, in the case where the WS-R partners for some reason didn't want to get involved in an open standard aproach like WS-Context) could not have been used here. However, I'm still more than willing to continue the discussion in case there is something I (or you) have missed that might just be that important element of differentiation. BTW, when we were part of HP Middleware, we worked with IBM on something called the Additional Structuring Mechanisms for the OTS (CORBA based), which could have been used to solve a similar requirement to WS-R but using a pattern more closely aligned to WS-Context & WS-CF. So I don't really believe that this is a technical matter. Thanks for the response, Mark. ---- Mark Little, Chief Architect, Transactions, Arjuna Technologies Ltd. > > Regards, > > William > > -- > William Vambenepe > Hewlett-Packard > > > > -----Original Message----- > > From: Mark Little [mailto:mark.little@arjuna.com] > > Sent: Saturday, January 24, 2004 3:05 AM > > To: Jeffrey Frey; Ian Foster > > Cc: Newcomer, Eric; ogsi-wg@gridforum.org; > > owner-ogsi-wg@gridforum.org; Savas Parastatidis; > > ws-caf@lists.oasis-open.org > > 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: > > > > <wsa:EndpointRefrence> > > <wsa:Address> > > http://.... > > </wsa:Address> > > <wsa:ReferenceProperties> > > <tns:resourceID>C</tns:resourceID> > > </wsa:ReferenceProperties> > > </wsa:EndpointReference> > > > > the same thing can be achieved using context (in pseudo-code): > > > > <wsctx:context>C</wsctx:context> <--- appears in the header block > > > > <wsa:Address> > > http:// > > </wsa:Address> > > > > 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 > > message. > > > > 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 > > them? > > > > 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 > > problems. > > > > 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 > > interaction. > > > > 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. > > > > ---- > > 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 > > | > > | > > | > > > > >------------------------------------------------------------- > > -------------- > > ---------------------------------------------------------| > > > > > > > > > > Eric: > > > > 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. > > > > Ian. > > > > 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 > > (http://www.neresc.ac.uk/ws-gaf). > > > > > > > > Regards, > > > > -- > > Savas Parastatidis > > http://savas.parastatidis.name > > > > > > 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 > > CORBA. > > > > > > > > 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 > > origin. > > > > > > > > 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]