OGSA EMC BoF on Simple job submission

Tom, Are OGSA EMC people aware of the most recent SAGA-RG work? Would SAGA-RG people like to engage OGSA EMC and possibly co-sponsor a Simple job submission WG? This could be a nice opportunity to tie in the classic API and the WSDL approach. One thing to consider: Do we really need APIs in SRM, APME, and now in ARCH areas? Hrabri ---- from "[ogsa-wg] Proposed agenda for Feb. 7th call" mail by Hiro ------- 4) Simple job submission BoF preparation (30 min) From the minutes of Jan. 19 call.
- There is a plan to do an EM-related BoF. Stacey should know about it but it is not the job of the OGSA-WG to tell her---the proposed-chairs should do it. Preparation has not progressed to that point yet so Andrew as Area Director will take care of it.
Action: Andrew as Area director to send an email to the directors of the relevant Area (SRM: Bill, Stephen) to let them know of the proposed BoF; also to Stacey to reserve a slot.
- Andrew mentioned that on the Data call there was a discussion for a similar BoF for Data.
-Hrabri

Hi Hrabri,
Are OGSA EMC people aware of the most recent SAGA-RG work?
Chris Smith from Platform, who's been putting together the job stuff for the Strawman is also involved in the OGSA EMS.
Would SAGA-RG people like to engage OGSA EMC and possibly co-sponsor a Simple job submission WG? This could be a nice opportunity to tie in the classic API and the WSDL approach.
I'm not sure how relevent this would be, unless you are thinking of a direct mapping of the SAGA API into WSDL, which may not make sense, and would probably constrain the new group too much, however we should certainly make sure we have some people at the BoF.
One thing to consider: Do we really need APIs in SRM, APME, and now in ARCH areas?
I'm not sure I understand this question ? We have APIs for the functional areas we identified from our use cases. Tom
Hrabri
---- from "[ogsa-wg] Proposed agenda for Feb. 7th call" mail by Hiro -------
4) Simple job submission BoF preparation (30 min) From the minutes of Jan. 19 call.
- There is a plan to do an EM-related BoF. Stacey should know about it but it is not the job of the OGSA-WG to tell her---the proposed-chairs should do it. Preparation has not progressed to that point yet so Andrew as Area Director will take care of it.
Action: Andrew as Area director to send an email to the directors of the relevant Area (SRM: Bill, Stephen) to let them know of the proposed BoF; also to Stacey to reserve a slot.
- Andrew mentioned that on the Data call there was a discussion for a similar BoF for Data.
-Hrabri

On Feb 8, 2005, at 8:46 AM, Tom Goodale wrote:
Would SAGA-RG people like to engage OGSA EMC and possibly co-sponsor a Simple job submission WG? This could be a nice opportunity to tie in the classic API and the WSDL approach.
I'm not sure how relevent this would be, unless you are thinking of a direct mapping of the SAGA API into WSDL, which may not make sense, and would probably constrain the new group too much, however we should certainly make sure we have some people at the BoF.
Well, this should be cause for further discussion. The application programmer point of view on this will be "I don't really care what's underneath as long as it does what I ask of it when I call the right subroutine". So the WSDL mapping is more on the implementation side of things. That being said, having a working implementation is quite important. So it may be very interesting to pursue as a path to implementation (albeit not the only path). I think the concern on the SAGA side is that the WSDL interface will be adjusted to accommodate the semantics defined by the application use cases rather than the other way around. But this sounds pretty reasonable to me.
One thing to consider: Do we really need APIs in SRM, APME, and now in ARCH areas?
I'm not sure I understand this question ? We have APIs for the functional areas we identified from our use cases.
Just to echo this part of Tom's note, the API's are driven by the use cases. The use cases thus far didn't describe any good SRM applications (or at least SRM-like requirements were not described in enough detail for us to act upon). It could just be that the apps people are so bogged down in remote file access issues that they don't realize they need good Storage Resource Management systems yet. If we get some well described SRM, APME, or ARCH use cases, that will motivate development of APIs in those areas. (its not that those areas are not important) -john
participants (3)
-
John Shalf
-
Rajic, Hrabri
-
Tom Goodale