[ogsa-rss-wg] On the Difference between a CSG and an EPS

[Soonwook Hwang]

Donal, I am glad that you have brought out this issue.
I think that it's very important to distinguish between
the two, and I was trying to understand what you meant
by "EPS is kind of a specialization of CSG." I guess
based on that argument, you were trying to explain 
the difference between the two, but frankly, I am not
sure about what you were trying to mean about the difference.
Would you explain one more time about the difference? Why 
is it that it's quite a change from what we've regarded the
CSG/EPS dichotomy in the past? I really would like to understand
the point you are trying to make.

In my opinion, the key difference between EPS and CSG is that
as the acronym indicates, CSG serves as generating a set of
candidate resources with no particular order between the 
members. EPS is the one in charge of putting them in order
using some kind of ranking function that is given by JM.
This would mean that CSG doesn't have to take a ranking
function (i.e., some kind of selection policy) as its input
and EPS is the one that needs a ranking function. In this way,
we might be able to come up with a very simple and uniform CSG 
regardless of a type of jobs that RSS might have to deal with. 
The uniform CSG is supposed to deal with only an atomic job.
In other words, regardless of whether it's atomic jobs or composite 
jobs that RSS deals with, when it comes to CSG, it always takes
a job description document (e.g., JSDL) of an atomic job and 
perform matchmaking using the description of the job's resource 
requirement specified in the job description document.

In case of composite jobs coming into RSS for scheduling, 
we could assume that the composite situation (whether
interdependency or co-allocation) is handled by services (e.g.,
JM) other than CSG. That way, we could get the definition of
CSG specification done soon and move on toward working on
EPS specification.

Regards,
Soonwook

> -----Original Message-----
> From: owner-ogsa-rss-wg at ggf.org [mailto:owner-ogsa-rss-wg at ggf.org] On
Behalf
> Of Donal K. Fellows
> Sent: Monday, January 09, 2006 9:00 PM
> To: ogsa-rss-wg at ggf.org
> Subject: [ogsa-rss-wg] On the Difference between a CSG and an EPS
> 
> Hi everyone!
> 
> I've been thinking about what constitutes a CSG or an EPS. Given that
> the EPS does not make any commitments (i.e. actually reserve anything)
> it seems that they are remarkably similar services, in that each takes a
> description of something that needs to be done, and returns a set
> (ordered by some "goodness" metric) of ways to achieve that goal. Now
> I've tried thinking about the difference in terms of the CSG dealing
> with atomic jobs and the EPS dealing with composite jobs (i.e. workflows
> in some sense) but that's in many ways a false dichotomy since the
> degree to which a job is atomic merely depends on how abstract your view
> of the system is. But that would mean that it is very difficult to
> really distinguish between what we actually mean by by a CSG and an EPS.
> 
> Having thought about this for a while, it strikes me that the key
> difference between a CSG and an EPS is that a CSG can be used as part of
> doing things other than execution planning (I believe there's an OGSA
> use-case for patch management, and the OGSA-D people seem to want a
> service that sounds very much like a CSG but which is specialized to
> their needs; there are probably other cases I've forgotten). But if an
> EPS is like a CSG but a CSG is more general, then that must mean that an
> EPS is a _specialization_ of a CSG! This would mean that the definition
> of a CSG encompasses the protocol used (i.e. that it is a "task
> description to ordered-set-of-ways-of-doing-the-task mapping service",
> and the ways of handling the efficient transfer of such potentially
> large sets and embedding in things WSRF, WS-Transfer, REST, etc) and
> that when it comes to the details of an EPS, we are instead talking
> about how do we describe the task (is pure JSDL enough?) and the
> candidates (maybe a WS-Ag template wrapped around something, but we'd
> need to specify what goes inside).
> 
> I'm still thinking through the meaning of all this (it is after all
> quite a change from how we've regarded the CSG/EPS dichotomy in the
> past) but my hunch is that this will allow us to move forward much
> faster to the description of useful service specifications (in part
> because it allows us to ignore most of the workflow difficulties). But
> I'd *really* welcome feedback on these ideas now. In particular, am I
> going off in entirely the wrong direction? :-)
> 
> Donal.
>