[ogsa-wg] Re: [ogsa-rss-wg] OGSA-RSS Agenda Topic

[Donal K. Fellows]

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.