[ogsa-naming-wg] Re: [ogsa-wg] Abstract names in BES

[Mark McKeown]

Hi Donal,

> > Regarding Chris's desire to be able to pass the LSF jobid
> > back to the client somehow - it could be included in the EPR's
> > Metdata, possibly RDF could be used to mark up the Metadata
> > to indicate that it is a LSF jobid. In this way the Address
> > IRI can be kept opaque.
>
> That would seem to me to be needless disambiguation. Surely it is just
> up to the service that mints the abstract name to understand it; there
> is no inherent need for it to explain what that means to anyone else.

I am not sure I understand your comment - you don't seem to
be disagreeing with me...

Frank wants to use the EPR's wsa:Address IRI as an AbstractName,
Chris wants to send a LSF jobid to the client and the W3C
recommends that IRIs should be opaque. One way to include
the LSF jobid in the EPR is to embed it into the wsa:Address
IRI, this might help make it unique and the client could extract
it from the IRI - however the W3C recommends that IRIs
should be opaque.

To resolve this issue I suggested putting the LSF jobid into
the wsa:Metadata of the EPR, the tooling generally only
looks at this if it knows to look for something. It might
be possible to use RDF to mark up the wsa:Metadata.
The wsa:Metadata can become stale, so retrieving a new version
of the EPR may return different wsa:Metadata (eg a different
LSF jobid). In this way it is possible to keep the EPR
wsa:Address IRI opaque to the client and pass the LSF jobid
back to the client in the EPR (if you really want to pass the
LSF jobid around in the EPR).

So I agree with your statement "Surely it is just
up to the service that mints the abstract name to understand it;
there is no inherent need for it to explain what that means to
anyone else."

Are the names that RNS provides opaque?

>
> > There is an interesting question as
> > to whether sending the LSF jobid back to the client somehow
> > breaks encapsulation - eg if I submit a job, the job is allocated
> > a local jobid, the job is checkpointed, stopped then restarted
> > on a different system with a different local jobid.
>
> I think that just indicates that the abstract job (the one that you're
> talking about) is not the same as the two concrete jobs that implement
> it, and as such would have different names to both of them. On the other
> hand, it would be entirely reasonable to query the abstract job to find
> out what its current (or, indeed, historic) concrete jobs are.

I am not familiar with the levels of abstraction that BES wants
to support, I guess it defines "abstract" and "concrete" jobs?

cheers
Mark

>
> Donal.
>
>