Marvin: I think one decision to make is whether BES services are homogeneous or not. I think Donal is advocating homogeneity. However, I do not think this is the main source of complexity. In either case, I agree with you that JSDL ought to be usable as a core syntax for describing the "resources available from a BES instance" as well as the "resources required for an activity". As you describe it, this is sort of a "class ad" in the Condor sense of the word. The problem comes from trying to advertise a resource that can handle multiple jobs simultaneously. The tricky part is that this is not just "nodes free", but must be intersected with policies such as maximum job size. Should there be a vocabulary for listing the total free resources and the job sizing policies directly? Or should the advertisement list a set of jobs that can be supported simultaneously, e.g. I publish 512 nodes as quanity 4 128-node job availability slots? The latter is easier to match, but probably doesn't work in the simple case because of combinatoric problem of grouping jobs which are not maximal. How does a user know that they can have quantity 8 64-node jobs or not? Also, I am ignoring the very real problem of capturing per-user policies. I do not think it is as simple as returning a customized response for the authenticating client. How is middleware supposed to layer on top of BES here? How does a meta-scheduler know whether quantity 8 64-node jobs can be accepted for one user? For 8 distinct users? Does a (shared) meta-scheduler now need to make separate queries for every client? How does it understand the interference of multiple user jobs? I think there is really a need for a composite availability view so such metaschedulers can reasonably think about a tentative future, in which they try to subdivide and claim parts of the BES resource for multiple jobs. Can this be handled with a declarative advertisement, or does it require some transactional dialogue? The transactional approach seems too tightly coupled to me, i.e. I should be able to compute a sensible candidate plan before I start negotiating. If we say all of this is too "researchy" for standardization, then I am not sure what the standard will really support. Perhaps the best approach is the first one I mentioned, where relatively raw data is exposed on several extensible axes (subject to authorization checks): overall resource pool descriptions, job sizing policies, user rights information, etc. The simple users may only receive a simple subset of this information which requires minimal transformation to tell them what they can submit. The middleware clients receive more elaborate data (if trusted) and can do more elaborate transformation of the data to help their planning. The only alternative I can imagine, right now, would be a very elaborate resource description language utilizing the JSDL "range value" concept to expose some core policy limits, as well as a number of extensions to express overall constraints which define the outer bounds of the combinatoric solution space. This DOES seem pretty "researchy" to me... but maybe someone else sees a more appealing middle ground? karl -- Karl Czajkowski karlcz@univa.com