[Pgi-wg] OGF PGI - Dependency diagram of existing specifications

[Andrew Grimshaw]

Etienne et al,

First, I will re-do the "realization" document based on comments and my own
forgetfulness. 

With respect to Etienne's email, a few comments.

You wrote
> I am quite sure that WS-Addressing and WS-Naming are NOT requirements,
> and I do NOT know at all how useful these specifications are for us.
>
I agree about WS-Naming. But if we are going to use web services - then
WS-Addressing is a must. WS-Addressing EPRs are how you "point" to web
service endpoints.

> As I already wrote in my mail dated 13 May 2009, I understand RNS as
> 'syntactic sugar' very useful for the end user, but belonging to a
> higher level (presentation) layer, and NOT required for PGI.
>

RNS is not presentation layer. It is naming layer that is human readable.
RNS is simply the top layer in a classic three layer distributed systems
naming scheme. We can argue about whether it is something we should use ...
but we will end up using something like it no matter what, humans and XML
were not meant for each other.




> -----Original Message-----
> From: Etienne URBAH [mailto:urbah at lal.in2p3.fr]
> Sent: Tuesday, May 19, 2009 1:06 PM
> To: david.wallom at oerc.ox.ac.uk; Andrew GRIMSHAW;
> aleksandr.konstantinov at fys.uio.no; pgi-wg at ogf.org
> Cc: lodygens at lal.in2p3.fr; edges-na3 at mail.edges-grid.eu
> Subject: Re: OGF PGI - Dependency diagram of existing specifications
> 
> David, Andrew, Aleksander and All,
> 
> Concerning the document 'GES Realization via Existing Specifications' :
> 
> I do NOT know if Aleksandr is kidding, but I agree with Andrew :
> RNS is NOT a requirement.
> 
> 
> Requirements are :
> 
> -  Compatible AUTHN credentials, and compatible AUTHZ credentials
> (covered in another thread, but NOT to be forgotten),
> 
> -  GLUE 2 to reference grid entities,
> 
> -  A well defined States and Transitions model (State Machine) for jobs,
> with precise semantics,
> 
> -  Some BES specification to define user operations on jobs, job states
> and job transitions, with precise semantics,
> 
> -  Some JSDL specification permitting the user to describe job
> requirements, data staging and job execution.
> 
> 
> I think that HPC-BP and HPC-BP FSE are useful recommendations permitting
> implementation, as described by Andrew, but I suppose that they are NOT
> requirements.
> 
> I am quite sure that WS-Addressing and WS-Naming are NOT requirements,
> and I do NOT know at all how useful these specifications are for us.
> 
> As I already wrote in my mail dated 13 May 2009, I understand RNS as
> 'syntactic sugar' very useful for the end user, but belonging to a
> higher level (presentation) layer, and NOT required for PGI.
> 
> 
> Finally, we need a diagram of dependencies between the different
> specifications which Andrew proposes.  So I would ask :
> 
> -  David to send to the PGI mailing list the slides 26, 27 and 28 of the
> presentation 'Standardisation: Recent progress review and best-practices
> sharing: Middleware Track' which he performed at the 6th
> e-Infrastructure Concertation Meeting in Lyon on 24 November 2008 (or
> improved versions).
> 
> -  Andrew to present a diagram of dependencies between the different
> specifications he proposes, indicating which ones are really required.
> He can take as example the above mentioned slides.
> 
> 
> Thanks in advance to David and Andrew for their help.
> 
> 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 Sat, 16 May 2009, Aleksandr Konstantinov wrote:
> > On Friday 15 May 2009 16:54, Andrew Grimshaw wrote:
> >> Aleksandr,
> >> RNS is not a requirement. It shows up in my "GES Realization via
> Existing
> >> Specifications" as a means to meet the requirements. I personally think
> it
> >> is a good idea and allows us to work with an existing code base and
> access
> >> layer. Listing a directory of things is pretty common.
> >
> > Looks like a good idea for me (personally). I think You should make one
> more logical step
> > and suggest to drop BES. No kidding. As You explained usage of RNS
> diring last telecon
> > it can do anything BES does. One simply has to provide some data
> transmission
> > capability to trasfer bigger chunks of data to/from nodes (not sure
> about term) presented
> > by RNS. And that could be same ByteIO proposed by You or even simpler -
> HTTP(S) which
> > is already used as underlying protocol of SOAP anyway.
> >
> > Actally we are using similar approach in ARC (production version) except
> that it uses
> > GridFTP (and hence TVFS) instead of RNS.
> >
> > Concerning "work with an existing code" I'm not sure. I doubt many of
> participating
> > projects have an implementation of RNS. And those developed probably
> won't be very
> > reusable in different environment. Do You have an implementation for
> libxml2?
> > On another hand AFAIR RNS is not a complex interface and wouldn't take
> much effort to
> > implement.
> >
> >
> > A.K.
> >
> >
> >
> >> A
> >>
> >>> -----Original Message-----
> >>> From: pgi-wg-bounces at ogf.org [mailto:pgi-wg-bounces at ogf.org] On Behalf
> Of
> >>> Aleksandr Konstantinov
> >>> Sent: Friday, May 15, 2009 9:32 AM
> >>> To: pgi-wg at ogf.org
> >>> Subject: Re: [Pgi-wg] Promised document
> >>>
> >>> On Friday 15 May 2009 13:10, David Wallom wrote:
> >>>> Hi All,
> >>>>
> >>>> Can we first agree (on the list, possibly with a doodle vote) that
> >>>> the requirements described in Andrews document were accurate.
> >>>> At this first stage please ignore the implementation, just are the
> >>>> requirements correct and if not what changes are required.
> >>> Is RNS requirement or implementation?
> >>>
> >>> A.K.
> >>>
> >>>
> >>>> David