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

[Andreas Savva]

Hi,

A S McGough wrote:
> Hi All,
> 
> 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 think this simple scenario would not require calling the EPS; the JM
would send a request to the CSG directly and use the first result. This
possible interaction is mentioned in OGSA 1.0 (3.4.6.2). Btw, I didn't
write this text so the people who did should comment further if the
original intention was different.

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

If this one does turn into an argument it should be taken to the BES
and/or JSDL lists instead.

Andreas


> steve..
> 
> 
> Andreas Savva wrote:
>> Ravi,
>>
>> I believe the CSG suggestion is primarily for the RSS-WG to focus on
>> just the normative description of the EPS interface first and not to try
>> to do both CSG and EPS. CSG could still be done at a later point. I
>> think we did not go as far as saying that CSG should be removed from the
>> EMS architecture.
>>
>> But it is probably true that the need for the CSG/EPS division is not
>> clear in the EMS roadmap scenarios. So I would suggest that you review
>> the proposed EMS roadmap scenarios (doc in gridforge ogsa root folder; I
>> can send you a url if you can't find it) and propose a scenario that
>> does draw the CSG/EPS distinction out.
>>
>> Andreas
>>
>> Subramaniam, Ravi wrote:
>>   
>>> Hi Charles,
>>>
>>> Thanks for the clarification on the decision. 
>>>
>>> I am not sure why one would have to have policy in the domain of EPS
>>> only. As far as I know, policy can be in multiple domains and
>>> partitioned at multiple levels and/or hierarchically. This suggests to
>>> me that one may partition policy in the CSG domain, EPS domain or any
>>> such domain as one chooses. One would expect that these policy
>>> frameworks be consistent but I don't see why they need to be
>>> concentrated in one place.
>>>
>>> Second, I don't understand the motivation behind the "redo much of the
>>> work". I don't see why this would be the case. It has less to do with
>>> the types of services rather than the limitations of implementation. In
>>> the case one cannot determine an algorithm that can have distributed
>>> decision/processing or if there is some sticky performance metric then
>>> one can design a software component that provides both services but
>>> leverages the "tight implementation composition" in realizing that
>>> algorithm. This again brings me back to the point of software component
>>> versus services.
>>>
>>> Thanks!
>>>
>>> Ravi
>>>
...

-- 
Andreas Savva
Fujitsu Laboratories Ltd