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