[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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. <jaf> Yes. </jaf> 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. > <jaf> Yes. Although I would rephrase this a bit. WS-Context is trying to > provide the mechanism by which additional context is provided for the > execution of the message targeted to a stateful resource. But the state of > the target resource is independent of the state represented by the > additional context. Hmmm, not sure where you got that definition of WS-Context from. It certainly doesn't match my reading of the specifications or associated white paper, and I helped write them. > Further, some types of context are useful for > coordinating across multiple operations or across resources. And some are > scoped to a single operation. It depends on the context being used. For > instance a transaction context typically represents a unit of work within > which operations are executed and coordinated, possibly across different > resources as well. However, a context representing a Locale is not really > coordinating operations. </jaf> Let's get this straight: context isn't being used only in coordination environments. > > 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. <jaf> True. So a > commit across multiple resources must be directed to a transaction manager. > Whereas a transaction scoped to a single RM is often directed at the RM > itself. I tend to think only about coordinated transactions across RMs. So > your point is well taken here. </jaf> > > 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. <jaf> Yes. You > could say that. It is really a use of the WS-Addressing EPR, which is meant > to provide extended capabilities beyond the basic use of a simple URL. > </jaf> 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, > <jaf> Yes, exactly. For instance, If context is passed by reference, rather > than by value, the WS-Context content could consist of a WS-Resource > qualified EPR. </jaf> 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. 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]