[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. 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. 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]