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
Etienne, 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