Dear All: In an effort to move forward this debate about "OGSA plumbing", I thought I'd attempt to describe the different positions that I've seen expressed. Perhaps people can read this quickly, and provide feedback as to where I have not captured things correctly. I'll be happy to collate responses sent directly to me and forward them, if there is interest. CONTEXT The context is that OGSA-WG needs to develop some low-level specifications, such as execution management services, that require modeling interactions that involve server-side state. E.g., in the following pseudo-code example, we request the creation of a "job": send "create(jsdl-specification)" to job-factory-web-service receive "job-handle" from job-factory-web-service I think that everyone accept that this sort of interaction is needed. (Let me know if not.) Where people differ in their views is with respect to what the "job-handle" should be and how we should represent operations on the job. I've heard three views expressed, as follows. OPTIONS 1) (WSRF) The job handle is an EPR to a WS-Resource, in which case the case the WSRF operations can be used to get status and delete: send "GetResourceProperty(status)" to job-handle send "Destroy" to job-handle In addition, one will probably also want to be able to send requests to the job-factory, which is straightforward as there is no strong encapsulation in WSRF. E.g.: send "destroy(all-jobs-owned-by-ian)" to job-factory-web-service This approach exploits the standardized syntax and semantics for the various operations (GetResourceProperty, Destroy, etc.) defined by the WSRF/WSN specifications. 2) (WS-Transfer) The job-handle is an EPR to a WS-Transfer resource, in which case the appropriate WS-Transfer operations can be used to get status and delete. send "Get" to job-handle send "Delete" to job-handle Assuming that there is no strong encapsulation in WS-Transfer either, one can also contact the job-factory directly when required: send "destroy(jobs-owned-by-ian)" to job-factory This approach exploits the syntax and semantics for the various operations (GetResourceProperty, Destroy, etc.) defined by the WS-Transfer specification. #2 is very similar to #1. One can argue the pros and cons of the two approaches. I'm concerned that you have to return the whole resource state, not just a single component (e.g., the status field). But that's a relatively minor issue. 3) (Job id) The job-handle is a job-factory-specific string, and we define job-factory-specific operations for manipulating the job, e.g.: send "check-job-status(job-handle)" to job-factory send "terminate-job(job-handle)" to job-factory #3 is very similar to #1 and #2: the message sent over the wire in each case contains the same information (operation name + Web service address + job-id-info). What is different about #3 is that you have to manage this job-handle separately from the job-factory EPR. Also, you don't use the standardized WSRF/WSN operations. Have I captured all of the options that people think we should be considering? WHAT OGSA-WG SHOULD DO Given this characterization, I'd also be interested in people's views as to how OGSA-WG should proceed when considering specifications that involve this sort of interaction pattern. The majority of active participants OGSA-WG participants seem to favor option #1, but I've also heard people argue in favor of approaches #2 and #3. Tony Hey proposed, I think, that we should define specifications like job management in terms of some more abstract interface that can then be mapped to each of the approaches above, as desired. Frank Seibenlist observed that we can use WSRF/WSN as such an abstract interface: given an interface defined in terms of WSRF/WSN specifications, one can derive, via straightforward transformations, a concrete specification in the style of approach #2 or #3. Regards -- Ian.