RE: [ogsa-wg] RE: GRIDtoday Edition: Tony Hey: 'Challenging Times for GGF & Standards'

-----Original Message----- From: owner-ogsa-wg@ggf.org [mailto:owner-ogsa-wg@ggf.org] On Behalf Of Ian Foster Sent: 03 March 2005 15:03 * Interactions with multiple resources: I think that's a red herring. E.g., a job factory can return EPRs to WS-Resources representing jobs, thus allowing individual jobs to be monitored and controlled, if needed. The factory can also maintain a service group representing all jobs, and then support operations that allow a client to "destroy all jobs that match a certain pattern" (for example). It's not an either/or. I'd like to drill down on this issue, because to me it seems a rare technical question amongst a sea of WS-FUD. Tony has presented the case in abstract. DAIS raised a concrete example some months ago. The question, as I understand it, is how to send a single message to multiple resources held by a given service using WSRF. (The supposition is that you know that these resources are accessible via the same service). I've had two possible patterns suggested to me that address this question : 1. Pass multiple EPRs to an operation on the service 2. Use a service group To take these in turn, the first pattern is worth highlighting because some critics of WSRF assume that the only way to use an EPR is to call an operation on it directly. Of course this isn't true; you can actually pass EPRs as arguments to another operation if that suits your needs. The second pattern provides a single operation on a group of resources. At first glance this seems to have the downside that the server controls which resources are in the set, rather than the client passing in a list. However, Ian's comment above suggests that the service group can provide a mechanism that allows operations to be invoked on subsets of the resources. I don't know enough about service groups to comment, except that this seems a reasonable solution. I would appreciate seeing these patterns explored in more depth - possibly in a face to face meeting next week? From the above, it certainly seems that the technical concern that Tony articulated can be addressed. Dave.

On Mar 10, Dave Berry loaded a tape reading: ...
The second pattern provides a single operation on a group of resources. At first glance this seems to have the downside that the server controls which resources are in the set, rather than the client passing in a list. However, Ian's comment above suggests that the service group can provide a mechanism that allows operations to be invoked on subsets of the resources. I don't know enough about service groups to comment, except that this seems a reasonable solution.
Yes, I agree with this sentiment. You would still be modeling a domain-specific operation that takes some more abstract "resource set expression" in its input, but the service group captures the scope over which the expression is evaluated. I think this scoping is important for two reasons: 1) Other service group mechanisms MAY be used to dynamically manage the set of resources that are within scope of these aggregate expressions, so you get nice composability of function. Of course, the contents of a service group MAY also simply "emerge" as the domain-specific introspection on some other processes/state. 2) It is unreasonable to think of one message operating on arbitrary resources from the whole Internet (picked "at random" by the client). The reason the resources are in scope is because they have some significant relationship to each other, as captured in the service group's domain-specific membership semantics. karl -- Karl Czajkowski karlcz@univa.com
participants (2)
-
Dave Berry
-
Karl Czajkowski