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