February 2007 - saga-rg - lists.ogf.org

Java Language Bindings
by Andre Merzky 08 Mar '07

08 Mar '07

Hi Folx, we had a number of discussions on how to jumpstart the Java language bindings. Let me recap the status of the Java implementation efforts: - Graeme Pound at OMII-UK started on a (complete) Java implementation, but left OMII> The effort is resting, the last version of his work is available at http://argos.e-science.soton.ac.uk/blogs/GeodiseSAGA/ - OMII-UK is funding a (somplete) Java implementation at LSU/VU, which will tentatively (!) start around April - Malcolm Illingworth and colleques at EPCC and the DEISA project have a Java implementation covering Jobs and Files, which is in use (probably the most progressed implementation to date). http://www.ogf.org/OGF19/materials/501/SAGA-DEISA.ppt - Pascal Kleijer from Naregi Japan started another partial implementation, focusing on Jobs, which has some Naregi specifica http://www.ogf.org/OGF19/materials/501/SAGA-Java-NAREGI.ppt - Lately, Gregor Pipan from XLab started, in the frame of the XtreemOS project, to implement the SAGA Job package. Now, the Java bindings in all these implementations are diverging, and we urgently need to synchronize them. Also, If I understand that correctly, all bindings are by now incomplete (mostly by design, focusing on jobs and files), and none is implementing the task model. Also, other parts of the SAGA look and feel (session, monitoring etc) seem mostly missing. As far as I understood the Java speach from earlier discussions, it should be possible to define the Java bindings as a set of Java interfaces and Java abstract classes, which can potentially be used by all implementations. I would propose to procede as follows: - I created a CVS directory for the language bindings (SAGA-RG/SAGA-Bindings) - I added a version of the OMII-UK package from Greame, as zip. (Could someone with Java knowledge please extract those files which are of real interest, and add just those?) - all other implementations listed above should also add their bindings, in whatever format available. -> That should allow us to compare the existing approaches. - Next we should add a normative version, either starting from the version most people like, or starting from scratch. It would be nice if someone (or better more than one actually) would volonteer to lead that project - preferably someone knowledgeable and interested in Java ;-) CVS details are to be found at: http://wiki.cct.lsu.edu/saga/space/CVS+Details If you don't have a CVS login, or don't receive CVS notification emails, please let me know. One final note: one thing we learned while implementing SAGA in C++ is that, although the API is simple, its implementation often is not. That is by design! It is tough, but please try to keep the API (as in language binding) simple, even if that means that the implementation is getting more difficult.... :-) Also, please think of Java newbies as end users, not of Java experts: the target user group are scientists, not computer scientists :-) Cheers, Andre. PS.: Steven: Grames blog has links to his bindings, but the links are dead. I only have an old version of his. Are you able to dig out his latest package (0.4.1)? -- "So much time, so little to do..." -- Garfield

2 1

Fwd (andre@merzky.net): [saga-cvs] "SAGA-RG/Strawman strawman.tex strawman_error.tex strawman_intro.tex strawman_logicalfiles.tex"
by Andre Merzky 02 Mar '07

02 Mar '07

Hi Folx, we started to address the public comments in the SAGA API CVS. We have to deliver a annotated version of the document to the editor. In order to simplify this, we created a number of latex macros for annotation. A short description is included below - if you edit the document, please use these. Thanks, Andre. ----- Forwarded message from Andre Merzky <andre(a)merzky.net> ----- > To: saga-cvs(a)cct.lsu.edu > From: Andre Merzky <andre(a)merzky.net> > Subject: [saga-cvs] "SAGA-RG/Strawman strawman.tex strawman_error.tex > strawman_intro.tex strawman_logicalfiles.tex" > > Update of /projects/SAGA-RG/Strawman > In directory asylum.cct.lsu.edu:/tmp/cvs-serv9678 > > Modified Files: > --------------- > strawman.tex strawman_error.tex strawman_intro.tex > strawman_logicalfiles.tex > > Log Message: > ------------ > Start to add marker for text changes. We need to re-submit the doc with changes > marked... please use: > > \XN{new text} > -> mark text as new > > \XX{old text}{new text} > -> mark text as changed from old to new > > \XL[lnum] > -> mark the last 'lnum' lines as changed > > In verbatim mode, use '!', '+' and '-' in the FIRST column, e.g. > > > \begin{myspec} > > ! package file > { > - class saga::file inherits saga::ns_entry > + class saga::file inherits saga::namespace_entry > ... > } > > \end{myspec} > > > No need to mark small typo corrections, everything else SHOULD be marked. > > Cheers, Andre. > > _______________________________________________ > saga-cvs mailing list > saga-cvs(a)cct.lsu.edu > https://mail.cct.lsu.edu/mailman/listinfo/saga-cvs ----- End forwarded message ----- -- "So much time, so little to do..." -- Garfield

1 1

Java Bindings
by Pascal Kleijer 25 Feb '07

25 Feb '07

As a follow-up of our SAGA sessions at OGF 19, here is one way on how to proceed with the SAGA Java Bindings and in fact with some other language bindings as well. Now this is to open the discussion and I don't want to impose the concept. So all of you that have interest in the Java binding please let your voice be heard. We have seen that each implementation of SAGA going on is not necessary standardized and not complete. The SAGA specification stipulates that partial is possible and each language bindings can introduce its specific flavor. That isn't the best way to get a standard around the corner. Java is a powerful language that allows a high level of abstraction. SAGA should follow a path similar to what has been done with, for example, XML: org.w3c.dom, org.xml.sax and JAXP. That means that SAGA: - Must have a complete abstract API based on façade Interfaces, - Minimize the number of concrete classes to Exceptions, Error and Factories (or Service Provider Interfaces - SPI), - Allow multiple vendor implementations in the back. For example multiple XML parsers can be installed at the same time. - Have a mechanisms to use one or more implementation at the same time, the user can choose one explicitly or not, - If one implementation does not support a specific section of the specification, a safe fall back mechanism should allow another implementation to be used transparently. The general SAGA API should have a common namespace like: org.ogf.saga. Specific implementation can be anything like nl.vu.saga. If the SAGA API façade is available and stabilized it could/should be submitted to the Java Community Process to become an official Java specification for Grid applications through the JSR (Java Specification Request). Pascal Kleijer k-pasukaru(a)ap.jp.nec.com

2 1

public comments...
by Andre Merzky 25 Feb '07

25 Feb '07

Hi folx, we started to address the public comments for the SAGA Core API. For that, a tracker was created at http://forge.ogf.org/short/saga-core-wg/public Out of 113 tracker items, we already addressed 100. The remaining 13 are marked 'Pending', and need some feedback from the group. We'd appreciate if you could comment on them, or go ahead and fix those in the spec, if you feel consensus has been reached. There are a couple of additional comments which don't have a tracker item as of yet - they will get added over the next couple of days. Amongst those are rather big ones, like the security AD feedback. So: more work to come :-) Cheers, Andre. PS.: due to fixes and changes, the page number used in the public comments are usually 1 or 2 pages off (to small usually). -- "So much time, so little to do..." -- Garfield

1 0

Fwd (andre@merzky.net): Re: JSDL - SAGA
by 'Andre Merzky' 20 Feb '07

20 Feb '07

Hi group(s), a couple of us had a recent discussion (f2f and email) about JSDL and SAGA. The question is: should we support JSDL fully on API level? E.g., should we allow the application programmer to specify/use JSDL documents for job creation? The reasons for doing that are compelling: JSDL is one of the most acknowledged standards in OGF, and the number of backends supporting JSDL is rapidly increasing it seems. Supporting JSDL directly would allow to interface with other tools using JSDL, and would allow to reuse JSDL documents where these are already available. Well, I have however some problems with that approach, which are outlined in the cited email below. Do you guys have any other thoughts, and what solution would you prefer? Cheers, Andre. ----- Forwarded message from 'Andre Merzky' <andre(a)merzky.net> ----- > From: 'Andre Merzky' <andre(a)merzky.net> > To: Shantenu Jha <sjha(a)cct.lsu.edu> > Cc: Hartmut Kaiser <hkaiser(a)cct.lsu.edu>, > 'Thilo Kielmann' <kielmann(a)cs.vu.nl>, > 'Andre Merzky' <andre(a)merzky.net> > Subject: Re: JSDL - SAGA > > Hartmut and I discussed that somewhat last week. So he > knows I am not wholehartedly for that option. SAGA is > supposed to abstract the low level details, not to expose > them. > > JSDL is going to define a number of extensions now. Some of > these extensions are very useful for us, others not. > Mostly, they will be more complex than JSDL itself. > > Are we going to support the extensions? Which? All/some? > How to select? What error do we report on unsupported > extensions? Do we mandate that extensions are supported by > the backends? Which? > > Even w/o extensions: is the job description updated after an > JSDL attrib is set? What about those attribs which are not > JSDL keys? Assume an implementation which implements the > existing SAGA job description keys: MUST it support complete > JSDL now? What error whould it report? > > These are probably all solvable problems, and I do agree > that there are advantages, i.e. the re-use of existing JSDL > documents. Anyway, IMHO we should be careful, consider if > we really have enough use cases etc. Also, a free function > jsdl_to_job_description may do the trick, w/o complicating > the job package itself. > > Cheers, Andre. > Another point I'd like to raise is: if HPC profile bekomes a widely accepted OGF standard, do we support it directly, too? Or OGSA-Workflow? Where to stop, and where is the 'S' in that approach? Andre. > Quoting [Shantenu Jha] >> >> What little I know, I think so to. >> >> >> Quoting [Hartmut Kaiser] >>> >>> Agree 100% >>> The easiest way is probably just to add a attribute in the job description >>> taking the whole JSDL. >>> >> >> Quoting [Thilo Kielmann] >>> >>> Yes! >>> >>> >>> Quoting [Shantenu Jha] >>>> >>>> Shouldn't we ensure that SAGA consumes JSDL w/o any >>>> problem/changes? >>>> -- "So much time, so little to do..." -- Garfield

7 10

Fwd (replogle@ogf.org): [gf-chairs] OGF20 Group Session Scheduling is now open
by Andre Merzky 16 Feb '07

16 Feb '07

Hi Folx, OGF-19 is just a couple of days in the past, up comes OGF-20! It is certain that session space will be tight in Manchester - so we need to decide/plan ahead very soon... Lets gather agenda items for 10 days, then we should be able to apply for sessions by end of next week... Cheers, Andre. ----- Forwarded message from Joel Replogle <replogle(a)ogf.org> ----- > To: gf-chairs(a)ggf.org > From: Joel Replogle <replogle(a)ogf.org> > Subject: [gf-chairs] OGF20 Group Session Scheduling is now open > > OGF Chairs - > > Group Session Scheduling is now open for the next OGF event, OGF20! > OGF20 will be held in the Manchester International Convention Center, > Manchester UK from May 7-11, 2007. > > To request a group session for your WG/RG/CG or a BoF session, please > go to the following page for Group Session Requesting instructions > and the link to the request form: > http://www.ogf.org/OGF20/events_chairinfo.php > > The scheduling deadlines are: > > Session Requests: > - Deadline for session requests for a CG, WG or RG is 16 March, 2007. > - Deadline for AD Hoc/Charter Discussion BOFs is 16 March, 2007. > Draft Documents: > - Deadline for submitting working drafts is 6 April, 2007. > > We anticipate that the schedule will be finalized by the end of March. > > Thanks, > > Joel > > ------------------------------------------------------------------------ > ----------- > Joel Replogle - Manager of Standards, Open Grid Forum > replogle(a)ogf.org http://www.ogf.org -- "So much time, so little to do..." -- Garfield

3 2

Re: [SAGA-RG] Fwd (replogle@ogf.org): [gf-chairs] OGF20 Group SessionScheduling is now open
by Craig Lee 13 Feb '07

13 Feb '07

All, In terms of vendor adoption, we will probably be asking all the WGs to try to keep track of the known major stakeholders and potential adopters for the standard being developed. We don't want to make a lot of work for anybody, but the active folks in each WG should know the best who these groups and people might be. This would really help a lot. Also, wrt language bindings, e.g., Java, it would really be good to get an idea which bindings the stakeholders and potential adopters really want. The idea of sending a SAGA Java binding through the JSR process is _very attractive_, but we want to make sure there is somebody to catch it when it comes out the other end ;-> Another thought that comes to mind is to make sure that people understand the distinction between Java SAGA and the Java CoG Kit, since that comparison will inevitably be made -- what are the advantages or disadvantages of one over the other? Certainly one is just an API while the other is Java glue-code for things like GridFTP, GRAM, and GSI -- but from an end-user's perspective, why choose one over the other? Could the SAGA API be implemented on top of CoG Kit? (Gregor: Do you have an opinion about all this?) --Craig At 04:44 AM 2/13/2007, Pascal Kleijer wrote: >Hi all, > >I would like to put Language Bindings as one topic on the agenda. Of >course we should split between Java and C, if other bindings pop-up in the >mean time we could add them as well. > >Another topic is the promotion process that SAGA will adopt and the >different plans, schedules, workshop, etc for dissemination. This item if >added, it should be clearly explained to Craig so that his Vendor adoption >track has the necessary information as well. > >Of course the SAGA 2.0 discussion will take its share as well. OK, that >are the thinks on my head right now! > >Best Regards, >Pascal Kleijer > > > Hi Folx, > > > > OGF-19 is just a couple of days in the past, up comes OGF-20! > > It is certain that session space will be tight in Manchester > > - so we need to decide/plan ahead very soon... > > > > Lets gather agenda items for 10 days, then we should be able > > to apply for sessions by end of next week... > > > > Cheers, Andre. > > > > > > ----- Forwarded message from Joel Replogle <replogle(a)ogf.org> ----- > > > > > To: gf-chairs(a)ggf.org > > > From: Joel Replogle <replogle(a)ogf.org> > > > Subject: [gf-chairs] OGF20 Group Session Scheduling is now open > > > > > > OGF Chairs - > > > > > > Group Session Scheduling is now open for the next OGF event, OGF20! > > > OGF20 will be held in the Manchester International Convention Center, > > > Manchester UK from May 7-11, 2007. > > > > > > To request a group session for your WG/RG/CG or a BoF session, please > > > go to the following page for Group Session Requesting instructions > > > and the link to the request form: > > > http://www.ogf.org/OGF20/events_chairinfo.php > > > > > > The scheduling deadlines are: > > > > > > Session Requests: > > > - Deadline for session requests for a CG, WG or RG is 16 March, 2007. > > > - Deadline for AD Hoc/Charter Discussion BOFs is 16 March, 2007. > > > Draft Documents: > > > - Deadline for submitting working drafts is 6 April, 2007. > > > > > > We anticipate that the schedule will be finalized by the end of March. > > > > > > Thanks, > > > > > > Joel > > > > > > ------------------------------------------------------------------------ > > > ----------- > > > Joel Replogle - Manager of Standards, Open Grid Forum > > > replogle(a)ogf.org http://www.ogf.org > > -- > > "So much time, so little to do..." -- Garfield > > -- > > saga-rg mailing list > > saga-rg(a)ogf.org > > http://www.ogf.org/mailman/listinfo/saga-rg > > > >k-pasukaru(a)ap.jp.nec.com >-- > saga-rg mailing list > saga-rg(a)ogf.org > http://www.ogf.org/mailman/listinfo/saga-rg

3 3