[Pgi-wg] PGI Execution Service - Realization via existing specifications
Etienne URBAH
urbah at lal.in2p3.fr
Wed May 13 05:33:57 CDT 2009
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 at 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 at lal.in2p3.fr]
>> Sent: Tuesday, May 12, 2009 2:23 PM
>> To: Andrew GRIMSHAW
>> Cc: pgi-wg at ogf.org; lodygens at lal.in2p3.fr; edges-na3 at 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 at 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
>
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5060 bytes
Desc: S/MIME Cryptographic Signature
Url : http://www.ogf.org/pipermail/pgi-wg/attachments/20090513/95f4be45/attachment-0001.bin
More information about the Pgi-wg
mailing list