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

[A S McGough]

Donal K. Fellows wrote:
> 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. 
That would work for me, and would make logical sense.

steve..
> (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.
>