[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 again William, > > I agree with most of what you are writing, but I don't think I made my > main point clear in the first email. Possibly, and thanks for bothering to try again. > First thing, when I say WSRF, I don't mean the "modeling state" white > paper. I mean the white paper plus the specs that come with it. That's > the framework. And actually, I mean the specs more than the white paper > because that's where the normative content is. I see WSRF as providing a > set of features that are useful for a specific, and very common, way of > using Web services. These features are described in the specs (published > and unpublished). I understand, and although the example I took was from the white paper, my comments were based on the whole set of specifications. > What WSRF (in either the white paper or the specs) does not say is: this > specific header has to show up in your messages to ensure correlation. > To the contrary, WS-Context describes a specific header (wsctx:context) > that has to appear in the messages. Sorry, but maybe this is an email problem. What you said in the above two sentences seems to be identical: a header has to show up in messages to ensure correlation; doesn't matter whether this is WS-RF or WS-Context. > This is what I mean when I say that > WSRF and WS-Context are orthogonal. Because of the confusion in your first two sentences, I may still be missing something, but: it seems that whichever way you cut this cake, it's correlation that is happening. The lifecycle events are important too, and they are dealt with within WS-Context as well as far as I can tell. I think 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. > And there are many things that WSRF > (in the different specs that compose the framework) does and WS-Context > does not do, such as access to properties, grouping of resources, etc... > In that sense too, they are orthogonal. I agree that the properties work is a differentiator and that should be a separate discussion. I think so far we've been talking about stateful services and how they can be provided, what currently exists, and whether yet another specification is really needed to accomplish that. If we concentrate solely on statefulness then I haven't seen anything so far that would require another specification in this area. My personal opinion about the properties stuff is that it shouldn't be exposed by the service at all, but that definitely is orthogonal to statefulness. Since the properties and statefulness work don't really need to be closely tied (at least that's the way it appears in the specs.) it would seem like you could ditch WS-ResourceLifetime in favour of WS-Context. And the grouping of resources is something that context is meant to do. > For example, if you put yourself in the shoes of a developer who needs > to expose and access properties of a resource through Web services, you > have two questions to answer (among others): > - what header format am I going to use in my messages to carry the > information identifying what resource I am interested in? > - how am I going to format my request to retrieve a specific property? > WS-Context is one possible answer to the first question. > WS-ResourceProperties (the relevant part of WSRF here) is one possible > answer to the second question. But the way I answer the first question > is irrelevant to the way I answer the second and vice-versa. I could > pick my own, homegrown, correlation header format instead of WS-Context, > it wouldn't change my ability to use WS-ResourceProperties. So they are > orthogonal. Yes, I can see that WS-ResourceProperties is different. We could get into another interesting discussion about whether this is the best way of approaching service-specific properties: like I said, I don't think it is appropriate to expose service meta data directly in the service definition; it doesn't scale for a start; why not just agree on a schema for the meta data and have a getMetaData method if you really want to go that route? Or have a trading service - that works in other distributed environments. Anyway, before we go off on a tangent, if you want to discuss this stuff let's have a separate thread (though I don't think it's relevant to WS-CAF). > > I wrote: > > > 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. > > You replied: > > 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. > > What I say is WS-Context the *specification* doesn't care. Obviously the > developer that uses WS-Context cares. But WS-Context (the spec) just > says "Mr. developer, I'll tell you how to place messages into a context; > what you use that mechanism for (security session, access to stateful > resource, message correlation) is none of my business". So WS-Context > doesn't care about the meaning of the context it allows the sharing of. OK, I see. But precisely why is this an issue? Seems like a sensible way of approaching the same thing to me. > BTW, you are right to correct me when I write: "WS-Context defines a way > to convey, in messages, the fact that some of these messages are related > to one another". Indeed this is technically a bit too restrictive and, > as you pointed out, a WS-Context header can be useful even if it is > carried by only one message. [My wording came from the way we defined > Conversation in WSMF (WSMF, not WSRF, see > http://devresource.hp.com/wsmf/)]. But this really wasn't my point one > way or the other, my point was that, as I wrote above, WS-Context > specifies what correlation header goes in the message and WSRF does not. No, but WSRF defines that the correlation context goes into the address information. Like I said, this is the same thing: it doesn't matter whether the information goes in the header or the address (although I'd prefer the header): it's the fact that the same information is required that's important. So, going back again to this point: the requirement is to be able to unambiguously talk to and reason about a specific service "instance" state, and that state may be fielded by one end-point that manages many different states. Sounds like contextualisation to me. > > I wrote: > > > 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. > > You replied: > > 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). > > I think my words if not easy to parse are logical and not > self-contradicting. I think you overloaded "how" perhaps. > Let me reword it in very concrete terms: > > "WSRF doesn't specify how the messages are correlated" -> "WSRF does not > specify what format your correlation header is in" > > "The only thing it specifies is how to create an endpoint reference that > indicates how the messages are correlated" -> "the only thing it > specifies is how to write an endpoint reference, no matter what > correlation format you use". Yup, it was the fact that you uses "how" and the sentences were almost identical. > > In other words, WSRF does not specify the format used for correlation, > it specifies the format used for addressing. (But WS-Context specifies > the format used for correlation). So your point is that the information about statefulness should go into the address, whereas WS-Context would place it into the header? It's certainly worth a debate. However, I think that dodges the central issue, which is that you still haven't convinced me that WS-Context (or context in general) couldn't have been used instead of inventing yet another specification for the *stateful* aspects of WS-RF. > > You wrote: > > 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. > > Yes they could be used together as use of WSRF requires to chose a > format for correlation header and WS-Context provides such a format. > > WSRF provides a way to expose properties of a resource. WSRF provides a > way to group resources. WSRF provides a way to renew references to > resources. Etc. AFAIK WS-Context does not do that, so I don't see how > WS-Context could be used instead of WSRF. WS-Context can certainly group resources (any number of services can participate within a context) and contains lifecycle events for a context (and hence in this example, any associated state). It's true that currently there is no way to renew a timeout associated with a context in WS-Context, and that's something that would be interesting to examine. And I've already mentioned the properties work. > Remember, the framework is not > just the white paper. All the white paper really says that has any > normative aspect is "use Ws-Addressing for endpoint reference". The rest > is just explanations, this is why it's a white paper, not a spec. The > only overlap I could see is if WS-Context provided an addressing > mechanism to replace WS-Addressing. I am not aware of such a feature in > WS-Context, but I might have missed it. There is an addressing mechanism in WS-Context and we're currently looking at improving this in a way that will be compliant with whatever the open standard becomes. However, we're not looking at embedding stateful information into an address. > As far as removing ReferenceProperties altogether as you suggest, the > WSRF specs need an addressing mechanism. You might not agree with the > choice of WS-Addressing for this, but there is a need for something. It's one thing to say that WS-RF needs an addressing mechanism - I agree with that statement and WS-Addressing seems like a logical choice given the supporters on the specifications. However, it's another to say that the context information necessary to tie together invocations and state has to reside within the endpoint reference element. Let's not confuse the argument any more than it possibly is: there are two separate issues here: (i) addressing, on which I haven't commented (apart from an early comment in a different email on handlers) and (ii) stateful associations, which at its heart isn't related to whether you use WS-Addressing or not. I think that irrespective of whether you use WS-Addressing, you can use WS-Context to replace the endpoint reference element and particularly the ReferenceProperties. So, although it may be wrong to imply that WS-RF can be entirely replaced by WS-Context, it still looks like there is overlap and it's a shame that at least some aspects of the work aren't brought together. Mark. ---- Mark Little, Chief Architect, Transactions, Arjuna Technologies Ltd. www.arjuna.com > > Regards, > > William > > (Savas, your bridging services are very appreciated :-) > > > -----Original Message----- > > From: Mark Little [mailto:mark.little@arjuna.com] > > Sent: Sunday, January 25, 2004 12:56 AM > > To: Vambenepe, William N; 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 > > > > > > > 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]