
13 May
2009
13 May
'09
10:33 a.m.
Andrew, Concerning the PGI Execution Service : Thank you very much for your precisions about issues of compatibility and implementability, with interop examples. I hope that they will permit the chairs to take the best decisions. Still : - For BES, official recommendation GDF.108 does NOT contain the 'Running:Stage-in' and 'Running:Stage-out' states. So we have to decide which basis we take for BES : - Either OFFICIAL recommendation GDF.108, which I suppose is the one for which you mention existing implementations. Then we would have to modify / upgrade / improve / extend / profile it, in order to introduce the new states. - Or a DRAFT already containing the necessary states (for example v38, for which I have given a link), for which I am doubting there is any existing implementation and interop test. Then we would have to begin by validating this DRAFT thoroughly. Can you give your position on this subject ? - I understand RNS as 'syntactic sugar' very useful for the end user, but belonging to a high level (presentation) layer. Is RNS really required for implementing Execution Service inside PGI, as belonging to a low level layer ? - I am NOT entirely sure that the links which I have given for the 'existing specifications and mechanisms' are accurate. Can you check them, and clearly validate them or correct them ? Thank you in advance for your answers. Best regards. ----------------------------------------------------- Etienne URBAH LAL, Univ Paris-Sud, IN2P3/CNRS Bat 200 91898 ORSAY France Tel: +33 1 64 46 84 87 Skype: etienne.urbah Mob: +33 6 22 30 53 27 mailto:urbah@lal.in2p3.fr ----------------------------------------------------- On Tue, 12 May 2009, Andrew Grimshaw wrote: > Etienne, > >> In order for your document to be really useful, we all have to carefully >> check if all 'existing specifications and mechanisms' referred by your >> document are : >> - compatible between each other, >> - really implementable, >> - at an affordable cost. > Let's start with WS-Addressing. There are tons of WS-Addressing > implementations out there. Most (all?) WS stacks implement it. The biggest > question is whether 1.0 or 1.1. (I think I have the version right). > There have been MANY interops with this just as OGF, since HPC-BP is based > on this, as is ByteIO, BES, RNS, and many others. Just with the HPC-BP there > have been over 10 interoperable implementations over the course of SC 08 and > 09. > > Ditto for BES. > > With respect to the OGSA-BES specification. The 1.0 that is out there is > GFD.108. The v27 document I was referring to is an earlier draft of the spec > that had things in it that are exactly what was specified in the > "requirements", specifically the "pending" state and an elucidation of the > sub states. Most of the document versions of BES are available in gridforge, > http://forge.gridforum.org/sf/docman/do/listDocuments/projects.ogsa-bes-wg/d > ocman.root.current_drafts?_pagenum=1. 27 is not there, but 26 and 28 are, > those three are all pretty similar. 27 is just the first one I opened on my > hard-drive that had "pending". > > Further, I have had an implementation of BES as a homework in my graduate OS > class. A simple implementation (e.g., fork/exec) is really pretty easy. > > ByteIO has also interop'd (if we can turn that into a word. See the > experiences document. It too is about as easy a spec as you can imagine. It > is basically a wrapper around POSIX files. The only think complicated about > it is implementing the OPTIONAL attachments mechanism which is a performance > optimization (using attachments to the SOAP messages avoids painfully slow > XML serialization of data blocks). > > RNS there has been less interoperability, Sarnowska reported on an interop > between Genesis II and SNARL/SABLE (RNS/ByteIO on top of glite logical > files) at the last OGF. RNS is pretty easy. It is a table with two entries, > a string "key" and an XML element that has an EPR and XML-any inside. > Basically it supports insert, list, delete. It is a trivial port-type to > implement. > > HPC-BP and HPC-FSE have been implemented and interop'd by a number of > groups. HPC-BP over 10, FSE I have not counted, the WG co-chairs would be > able to answer that better than me. We've implemented it, Platform has too, > am not sure about gridSAM. > > JSDL has been implemented by anybody who has implemented BES (or HPC-BP). > XML parsing is never for the faint of heart, but I had two undergraduate > class projects that involved parsing JSDL documents ... how hard can it be? > > For all of these "at an affordable cost" is hard to quantify. I would say > that a really good, robust to all sorts of failures, implementation of BES > is the hardest > > Compatibility is always a challenge, that is why we have interoperability > events. > > > A > >> -----Original Message----- >> From: Etienne URBAH [mailto:urbah@lal.in2p3.fr] >> Sent: Tuesday, May 12, 2009 2:23 PM >> To: Andrew GRIMSHAW >> Cc: pgi-wg@ogf.org; lodygens@lal.in2p3.fr; edges-na3@mail.edges-grid.eu >> Subject: Re: PGI Execution Service - Realization via existing >> specifications >> >> Andrew, >> >> Concerning the PGI Execution Service : >> >> Thank you very much for your 'GES Realization via Existing >> Specifications.doc' proposal, which targets 'as small a specification as >> possible and attempt to use existing specifications and mechanisms when >> it makes sense.' >> >> In order for your document to be really useful, we all have to carefully >> check if all 'existing specifications and mechanisms' referred by your >> document are : >> - compatible between each other, >> - really implementable, >> - at an affordable cost. >> >> In order to ease this checks, I propose below links for the 'existing >> specifications and mechanisms referred by your document', and I ask you >> to : >> - verify if my links are accurate, >> - provide the accurate links inside the next version of your document. >> >> WS-Addressing : >> http://www.w3.org/Submission/2004/SUBM-ws-addressing-20040810/ >> >> WS-Naming : http://www.ogf.org/documents/GFD.109.pdf >> >> OGSA-WSRF-BSP : http://www.ogf.org/documents/GFD.138.pdf >> TO BE VERIFIED >> >> JSDL : http://www.ogf.org/documents/GFD.136.pdf >> >> OGSA-BES : ATTENTION, you are NOT referring to recommendation >> GDF.108, but on 17 April 2009, you sent us DRAFT v32 >> 'ogsa-bes-v32.doc', and you are now referring to >> DRAFT v27, which has NO link inside >> http://forge.gridforum.org/sf/docman/do/listDocuments/projects.ogsa-bes- >> wg/docman.root.current_drafts >> Could we use DRAFT v38, which is Version 3 at >> http://forge.gridforum.org/sf/go/doc15062?nav=1 ? >> >> HPC-BP : http://www.ogf.org/documents/GFD.114.pdf >> >> HPC-BP FSE : http://www.ogf.org/documents/GFD.135.pdf >> >> RNS : http://www.ogf.org/documents/GFD.101.pdf >> >> >> Thank you in advance. >> >> Best regards. >> >> ----------------------------------------------------- >> Etienne URBAH LAL, Univ Paris-Sud, IN2P3/CNRS >> Bat 200 91898 ORSAY France >> Tel: +33 1 64 46 84 87 Skype: etienne.urbah >> Mob: +33 6 22 30 53 27 mailto:urbah@lal.in2p3.fr >> ----------------------------------------------------- >> >> >> On Tue, 12 May 2009, Andrew Grimshaw wrote: >>> Colleagues, >>> >>> Last week I promised to deliver a document for discussion tomorrow on >>> how to use existing specification (and profiles on those specifications) >>> to realize the requirements in the April 29 draft GES info document. >>> Attached is a word file that sketches out the solution. The document is >>> not intended to be published - it is to organize a discussion and give >>> you insight into my proposed solution to the requirements. >>> >>> I have also carefully read the GES document and have a number of >>> comments on that as well. I will be sending it later today or tomorrow. >>> My comments on the GES are not necessary to understand the "realization" >>> document. I also encourage you to read the ISV primer. >>> >>> Andrew > > >