[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: FW: [ogsi-wg] RE: [ws-caf] WS-Resource Framework
Your postman at work again. -- Savas Parastatidis http://savas.parastatidis.name (now blogging) > -----Original Message----- > From: Vambenepe, William N [mailto:vbp@hp.com] > Sent: Monday, January 26, 2004 5:19 AM > To: Mark Little; Jeffrey Frey; Ian Foster > Cc: Newcomer, Eric; ogsi-wg@gridforum.org; Savas Parastatidis; ws- > caf@lists.oasis-open.org > Subject: RE: [ogsi-wg] RE: [ws-caf] WS-Resource Framework > > > Hi Mark, > > I agree with most of what you are writing, but I don't think I made my > main point clear in the first email. > > 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). > > 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. This is what I mean when I say that > WSRF and WS-Context are orthogonal. 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. > > 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. > > 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. > > 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. > > 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. 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". > > 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). > > 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. 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. > > 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. > > 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]