[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ws-caf] Re: [ogsi-wg] RE: [ws-caf] WS-Resource Framework
Rather than getting into long arguments across multiple lists, perhaps
we could take a moment to consider the benefits and drawbacks to both
approaches -- the use of context to manage state vs. the use of
IOR-like endpoint references -- in a more organized and dispassionate
fashion. I think it would be most helpful to see both viewpoints
juxtaposed against each other, perhaps in a simple table or matrix that
presents insofar as possible an objective summary of the technical
advantage, disadvantage and viability of both approaches.
These new grid specifications seem very much like the OGSI specs with some changes, including better factoring into modular components (good) and replacement of grid-oriented service references with a proprietary vendor model, ws-addressing (good or bad depending on who you work for, perhaps). I think many of the discussions that have previously centered on OGSI are still relevant and can be used to build out a point comparison view of these issues.
Many of us believe that these two groups could be working together productively; it would be best if we can have a collected and structured way to determine if that's possible. I'm hoping we won't argue our way past an opportunity for mutually beneficial collaboration.
Mark Little wrote:
Mark, Either I am failing to articulate my point, or it is not compelling toyou. Jeffrey, quite possibly either of the above is true. Ditto for myself.There are pointers to things and there are contexts in which those things are used.Alternatively, there are things that are used within a certain context and that context implicitly (or explicitly) defines their behaviour and state.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.OK, I understand that, but how is that different to having a standard (non-state specific) endpoint reference and associate the context (WS-RF calls it context too) with the messages that are sent to that endpoint reference? I don't see the technical difference, since both result in the ability to contact and use the same stateful resource. Maybe there is something that I'm missing that is specific to your use case? However, from what Savas has said in the past and recently, maybe not. Any chance you could address Savas' points?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 resourceidentityas part of the service endpoint reference. If it would help eliminate the confusion, I would be happy to stop using the word "context" to expresstheintended semantic of the references properties within a WS-Addressing EPR.I think that might help only in terms of the English text: the point I'm trying to make is that it doesn't matter if you call it a "fluffy white kitten", as far as I can see, it's a context. The model you have defined seems basically CORBA with XML/SOAP. It obviously works, since the OMG has been doing that for years, but is it appropriate to an SOA, and particularly if there is something already in that space that appears to provide the same capability? I thought I showed earlier (and William seemed to agree) that in the examples that appear in WS-RF (the specs as well as the white paper) WS-Context could have been used from the outset. There is no clear benefit from embedding the "object id" (to take a CORBA term) into the IOR (oops, should be WS-Address), when there's a context service. Actually, I'll backtrack on that: there is only one benefit I can see and that is if you only want to use a single resource/state. Like I said in another email, if you want to group together resources into a multi-party/multi-state interaction, then you or the application, will have to manage the individual resources, remember their IDs, what combination of IDs makes sense in what interaction, ... A definite headache if you're even contemplating using more than 2 and possibly hundreds/thousands of states. Of course there are solutions, like trading services, naming services, etc. but these have drawbacks and start to make the "simple" approach much more complex. The alternative, is to contextualise all of the interactions, so that each service can opaquely bind a state to a specific context. Then all you have to remember is the context within which you interacted with the services (obviously you need to remember the services, but hey, you have to do that in the WS-RF approach anyway).If I understand the intent of your transaction example, you would claimthetreatment of the input parameter of a commit operation is another example of an appropriate use of WS-Context.I argued that the use of the XID in conjunction with xa_switch_t (or XAResource in J2EE) can be performed using 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,orif transaction context flows with the message, they would say no.After having written and worked on several transaction systems over the last 20 years, including for HP, I think I qualify as one of those "experienced" individuals, and it's not as clear-cut as you might like others to believe: the example illustrates how multiplexing across the same endpoint (XAResource/xa_switch_t) with some contextual information (the XID) occurs today in the real world; whether that contextual information is shipped as an explicit transaction context in an IOR, for instance, or as an explicit part of a message to the endpoint, is immaterial. As I said in the first email to you: if you want to take a very restrictive view of context as epitomised in a transaction service, then I can see a difference between what you are looking at in WS-RF. However, WS-Context doesn't take such a restrictive view point. Maybe if you read the specification again from a more open perspective you'll begin to see that?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.Again, I think you're reading far too much between the lines here, combined with a restrictive view of context (perhaps based only on transactions?) I didn't mention registration of the commit operation with the transaction at all, did I?If I follow your line of reasoning, then why don't we treat all webservicerequest parameter data as WS-Context elements? If you use the term "context" this broadly and indiscriminately, one might argue that allinputrequired 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.It is certainly possible that for some interaction patterns much more information, such as properties, *could* be embedded within a WS-Context. And this precisely matches at least one of the use cases that we have been asked to support. Check out the TC pages and the public mailing lists and you'll find the examples. If you have such strong views on what WS-Context should and should not do, then maybe you should participate in the WS-Context technical committee? The current intent of WS-Context is to provide a flexible and extensible associative scheme for messages, that can accomodate a number of different use cases. It is certainly not an "indiscriminate" use of the term context. You may also want to check out the OMG's Additional Structuring Mechanisms for the OTS and JSR 95 (a J2EE version of the previous spec) both of which IBM worked on with myself and several others from the WS-CAF team. In both specs there is the notion of a general extended context that contains properties/data/etc that is shipped on invocation requests and is required at the endpoint in order to perform the operation. From what I've been told, I believe that IBM and its customers use this pattern quite a bit. Let me reiterate: WS-Context is intended to support a number of different use cases. Although the notion of shipping state and properties in the context of a message in order that the recipient can then use that information to perform the desired operation is not necessarily a common requirement, it is one that we currently believe that WS-Context should support.And it would not be consistent with the well known and traditional meaning of messageexecutioncontext as it has been used in distributed systems for years.If you believe that context needs to be so restricted, then please get involved in the TC. However, we still seem to be going round in circles. Maybe I can try to summarise where I think we are, and if I'm wrong, please feel free to correct me: you believe that WS-Context should have a very narrow (transaction-type) view of what a context is. In that situation, you would say that it is an inappropriate use of context for the endpoint to tie it to state. Furthermore, the model you prefer for identifying states (or object instances) within a service is essentially similar to CORBA, but with XML and SOAP. whereas, the WS-Context view is that context isn't narrowly defined and that this is a SOA we're dealing with, where services shouldn't necessarly expose their backend implementation choices to the world. Mark. ---- Mark Little, Chief Architect, Transactions, Arjuna Technologies Ltd. www.arjuna.comJeffrey 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: email@example.com |---------+----------------------------> | | "Mark Little" | | | <mark.little@arju| | | na.com> | | | | | | 01/24/2004 06:05 | | | AM | | | | |---------+----------------------------> ------------------------------------------------------------------------------------------------------------------------------------|||| To: Jeffrey Frey/Poughkeepsie/IBM@IBMUS, "Ian Foster"| cc: "Newcomer, Eric" <Eric.Newcomer@iona.com>,| Parastatidis" <Savas.Parastatidis@newcastle.ac.uk>,| 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 foraninteroperable 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 youtaketransactions 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 identifythetransaction (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 anXIDthat 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 casethestate 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 endpointreference,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 statefulinstancesvia context also appears to be a lot easier when you have mutlipleservicesin 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 seemslikea 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 canbeaugmented 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 notionofcontext can also support that. WS-Context has an explicit (thoughoptional)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 viewofwhat 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" <firstname.lastname@example.org> To: "Ian Foster" <email@example.com> Cc: "Newcomer, Eric" <Eric.Newcomer@iona.com>; <firstname.lastname@example.org>; <email@example.com>; "Savas Parastatidis" <Savas.Parastatidis@newcastle.ac.uk>; <firstname.lastname@example.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 wehaveintroduced 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 identifyingthetarget 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: email@example.com |---------+----------------------------> | | Ian Foster | | | <firstname.lastname@example.org| | | 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: <email@example.com>, <firstname.lastname@example.org> | | Subject: Re: [ogsi-wg] RE: [ws-caf] WS-Resource Framework | | | --------------------------------------------------------------------------- ---------------------------------------------------------| Eric: We (the WSRF authors) are very familiar with WS-Context and certainlyagreethat 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 weareseeing 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 Gridapplications(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; email@example.com Subject: RE: [ws-caf] WS-Resource Framework I have the general impression of the OGSA specs as the equivalenceofCORBA. 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 fortheResource Framework. It would be nice to try to converge these things at some point andinsome 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]