A S McGough wrote:
As one of the people who brought this up in the f2f I thought I should just bring in a few comments. My main issue with the CSG/EPS combination is was one of efficiency. The way it appeared to me was that the EPS will send a request to th CSG to provide a list of "suitable" candidates. Now perhaps the EPS is a dumb one which will just use the first one provided. In which case the time to generate the rest is wasted. Could someone comment/correct me on this? If there is some lazy way to do this then fine.
I've been thinking about the difference between a CSG and an EPS for a while (funnily enough ;-) ) and I believe that the difference between them is that an EPS *is* a CSG that has been specialized for working with candidates that are execution plans. (At the moment, there is no standardized vocabulary for composite jobs - and RSS isn't defining one - so the other way of differentiating ends up with vapourware.) Given that, the main questions then become ones of how to handle efficiency and things like that. Looking at the *abstract* level, the result of a CSG is an ordered set of candidates and the result of an EPS is an ordered set of execution plans (it was decided in Boston that the EPS will not make reservations or take the final decision because that precludes scenarios involving rebooking and gets very messy indeed). The trick then is to come up with a way that allows the efficient processing of such ordered sets, but this is something where we can borrow from other standards; yes, I'm thinking of WS-Enumeration here, but you could have an OrderedSet as a WS-Resource instead, and that would work well too. The key then is for the producers of these ordered sets to implement themselves in such a way that they can do so efficiently, especially when they are producing very large candidate sets, but that is outside the domain of the standard. I've no intention of prescribing an implementation strategy... Given that (which all feels quite workable to me) the major remaining issue is what to put in the Candidate Execution Plan document, and that is something where the things that have been discussed earlier in this thread are greatly valuable. Also note that by keeping the CSG abstract on the nature of the candidate documents, it means that the concept is nicely reusable in other contexts. I do remember Ravi's cases on patch management, and Dave Berry's thoughts on how the CSG is very much like things that are in (or going to be in) the OGSA-D work. It feels like a nice synergy, and I like how it may be possible to reuse things outside EMS.
On a point which was dropped some time ago (not wanting to start an argument by the way), it was queried about why the BES is worrying about data staging when the data groups have better solutions. This is due to the fact that BES is using JSDL which in turn has data staging. This is a consequence of most existing job languages having data staging. As a member of JSDL (and BES) I think we can state that we will be more than happy to depreciate the data staging functionalities in these specs for better systems provided by the data groups as and when appropriate.
As the author of (the first version of) that straw-man, if anyone has anything better to put in place of the noddy data-transfer stuff that is in there, please feel free to make a concrete suggestion. Only real requirement is that it must fit the concept of JSDL as a template document, so substituting a service in there is going to be a bit clunky; though a reference to a service could work, it's probably easier to name the data itself as a resource (using the W3C sense of the "R" word there). You can do an amazing number of things with IRIs after all (data: and cid: being distinctly interesting, though abstract URNs have many possibilities too when you add some kind of resolver, e.g. a replica catalog.) Donal.