[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ogsi-wg] RE: [ws-caf] WS-Resource Framework
> Mark, > > Right, I was trying to put WS-Context in relationship to WS-RF, I did not mean to characterize it generally. I agree it's applications are broader. In the WS-RF world of persistent resources, WS-Context would be used to manage persistent state necessary to coordinate operations on multiple resources, but that's certainly not all it can be used for. Sorry that wasn't clear. > OK, that does make it clearer. Thanks. > Anyway, from all the discussion so far I think the main proposal on the table is to see if it makes sense to define a WS-RF address for referencing a WS-Context structure. I don't detect much consensus around the idea of WS-Context as the basis of WS-RF. > No, neither do I, which is unfortunate. Mark. ---- Mark Little, Chief Architect, Transactions, Arjuna Technologies Ltd. www.arjuna.com > Eric > > -----Original Message----- > From: Mark Little [mailto:mark.little@arjuna.com] > Sent: Wednesday, January 28, 2004 7:23 AM > To: Newcomer, Eric; Jeffrey Frey > Cc: Ian Foster; 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 > > > > Actually I think this helps a lot. If I understand correctly, the WS-RF > was trying to construct a pointer to an instance of a resource managing > persistent state. Whereas WS-Context is trying to create a mechanism for > managing persistent state external to resources, and in some cases used by > the resources in performing coordinated operations. > > > > Eric, I'm not exactly sure that this is just what we're trying to achieve in > WS-Context, but it is certainly one requirement. However, the question > remains: is this the appropriate way of accomplishing this result? From an > end-users perspective, what's the difference between embedding the context > in the end-point reference or associating it with the message sent to that > endpoint? > > I must admit that I'm beginning to think that neither side will agree, so > we'll just have to agree that both mechanisms can be used to achieve the > same thing. > > > On the commit topic -- A commit on a single resource is very different > than a commit across multiple resources, and by definition requires > persistent context outside the scope of a single resource manager. > > > > In any case what it seems like to me now is that WS-RF is an attempt to > define a substitute for the URL based addressing typically used in Web > services, for the specific purpose of addressing a resource. If so, this > would seem to provide a useful bit of context since database and file > sessions are usually scoped to an operating system process or mainframe > region. Although they are sometimes network-addressable there is no > standard format for them. > > > > In this way WS-RF could also be used as a pointer to a WS-Context > instance, in the situation in which the persistent state may have to be > managed externally to a more permanent resource like those WS-RF points to. > > > > It could and I think this is in line with what William described the other > day. > > Mark. > > ---- > Mark Little, > Chief Architect, Transactions, > Arjuna Technologies Ltd. > > www.arjuna.com > > > -----Original Message----- > > From: Jeffrey Frey [mailto:jafrey@us.ibm.com] > > Sent: Tuesday, January 27, 2004 1:01 AM > > To: Mark Little > > Cc: Newcomer, Eric; Ian Foster; 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 > > > > > > > > > > > > > > Mark, > > Either I am failing to articulate my point, or it is not compelling to > you. > > There are pointers to things and there are contexts in which those things > > are used. What we intended to represent with the endpoint reference in > WSRF > > is a structured pointer to a stateful resource. We purposely encapsulate > > the identity of the resource in the endpoint reference so that the EPR > > could be passed and used as a network-wide resource pointer. This > > eliminates the need to treat the pointer to a stateful resource as two or > > more separate components in the programming model, namely the network > > endpoint address of the agent providing access to the resource, and a > > context element needed to further qualify the resource instance at that > > endpoint. This is the primary rationale for treating the resource > identity > > as part of the service endpoint reference. If it would help eliminate the > > confusion, I would be happy to stop using the word "context" to express > the > > intended semantic of the references properties within a WS-Addressing EPR. > > > > If I understand the intent of your transaction example, you would claim > the > > treatment of the input parameter of a commit operation is another example > > of an appropriate use of WS-Context. I argue that the use of the XID to > > identify the stateful resource (transaction state) as the explicit target > > of the commit operation is not same as the treatment of the XID as a > > "transaction context" that accompanies a request message to a database > > targeting a stateful resource (database content) in the database. In both > > examples, the same XID value is used, and it represents the same > > transaction. But in one case it is used to express a contextual use of the > > database content (an appropriate use of WS-Context) and in the other it > > represents the primary target of the request message (Commit) itself. If > > you ask a person experienced in building transaction systems whether a > > commit or rollback message is performed in the context of a transaction, > or > > if transaction context flows with the message, they would say no. There is > > no need to register the execution of the commit operation in the > > transactional unit of work, even though there is a need to identify the > > transaction being committed. These are distinct ideas. > > > > If I follow your line of reasoning, then why don't we treat all web > service > > request parameter data as WS-Context elements? If you use the term > > "context" this broadly and indiscriminately, one might argue that all > input > > required for the execution of a service request is "context" for the > > request. In fact, one could then argue that "context" not only represents > > the content of the request message, but all of the environmental state > > needed, however obtained or provided, in the support of the execution of > > the request. Of course, all of this is "context". But it is not a useful > > way to express or use the notion of WS-Context. And it would not be > > consistent with the well known and traditional meaning of message > execution > > context as it has been used in distributed systems for years. > > > > 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 > > > > > > > > > > |---------+----------------------------> > > | | "Mark Little" | > > | | <mark.little@arju| > > | | na.com> | > > | | | > > | | 01/24/2004 06:05 | > > | | AM | > > | | | > > |---------+----------------------------> > > > >--------------------------------------------------------------------------- > ---------------------------------------------------------| > > | > | > > | To: Jeffrey Frey/Poughkeepsie/IBM@IBMUS, "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> | > > | 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]