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

Thanks to Andreas for the notification.

Andreas Savva wrote:
> Even though there were no RSS-WG representatives at the F2F the EMS
> design team also discussed EPS and CSG as part of the EMS Roadmap
> session. Two *suggestions* came out of that session and should be
> discussed at a future joint call or perhaps during a joint session at
> GGF16. I think they fit in the agenda that Donal proposed below.
> 
>>From the minutes:
> - Separation of EPS and CSG is not clearly required – suggest to RSS to
> remove CSG and let them make the call. And clearly define the added
> value of CSG.
> - EPS returns an ordered (by policy) list of (Activity Execution
> Candidates: <JSDL doc; EPR or path of BES container; rank (optional,
> numeric, extensible), CDL, EPR to deployment service, ...>.
> 
> Folder url:
> https://forge.gridforum.org/docman2/ViewCategory.php?group_id=42&category_id=1149&filtertype=basic

I think I favour keeping the CSG as an abstract concept; it looks like
it will be useful for places in the Data architecture (e.g. it's
possibly an abstraction of other things like replica catalogs. Many
thanks to Dave Berry for starting me thinking about these things; it
helped a lot with understanding the difference between a CSG and an
EPS.) It will also be the level at which we describe how to map things
down to stuff like WSRF or WS-Transfer, since it stops us from worrying
about how to actually splat things over the wire in a portable way (i.e.
there are multiple ways of doing it, but writing connectors from one to
another isn't hard).

Looking at the other issue, that of the Activity Execution Candidates, I
rather like much of what is suggested. I'd modify it a bit though:
   AEC <
      JSDL
      BES-EPR
      QoS Terms <
         Price
         Start Time Range[*]
         End Time Range
         etc. (extensible)
      >
      CDL (I don't know what this will look like, but having it is not a
           problem at all; probably easier to not require though, since
           as long as we have extensibility it can go in trivially
           anyway.)
      etc. (extensible)
   >

Just putting the score in isn't so helpful (there's no reasonable
possibility of examining the provenance of the value) especially since
different parties that see the AEC might want to apply different
objective functions.

In a reverse to things I've said in the past, I don't think we should
require the AEC to be implemented as a WS-Agreement template (though one
could be contained within it via extensibility) since that imposes some
very strong restrictions on how the job is subsequently handled. There
probably ought to be provision for the signing of the AEC, since that
enables the receiving party to know the identity of the party legally
responsible for honouring what will be the basis for a contract.

Pricing model must itself be extensible, but lots of useful cases are
easily handled through "fixed amount plus <consumption level>*rate".

Looking more at
https://forge.gridforum.org/projects/ogsa-wg/document/EMS_Roadmap_notes/en/1
I see that there are some thoughts on EPS and things more complex than
an atomic job. That would require some kind of composite activity
description language, the definition of which is outside the scope of
the RSS WG. (In many respects, it doesn't alter all that much anyway.
It's just a more complex replacement for the JSDL chunk.) Similarly for
scheduling parameters or parametric things (well, certainly for sched
parms; I don't understand the parametric world quite so well).

Anything else I've missed?

Donal.
[* Or should this be an expression of estimated delay from submission to
    execution commencement? Sometimes things are best one way, sometimes
    another. StartTime is good for reservation, StartDelay is good for
    immediate-execution or conventional batch queues. ]