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

[Mark McKeown]

Hi Frank,
         A number of points/questions...

By advocating using the Address element of the EPR as the
AbstractName are you saying that ReferenceParameters should
NOT be used to map messages to backend resources?
(Two WSRF EPRs can have the same Address element but use
ReferenceParameters to map to different WSRF resources)

The Address is an IRI, ie it can be a URN. It has never
been clear to me how EPR's that use URNs in the Address
element should be used, though people seem quite keen on them.
Either the client can somehow map the URN to a physical
network location or it can get another service to resolve
the URN to a physical network location - are you adovcating
using URNs as the Address element?

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. 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.

cheers
Mark


> Hi Michael,
>
> As I argued in my reply to Chris, you should be able to use the actual
> EPR's Address for this purpose if you consider it as a simple identifier
> instead of an endpoint reference, and if you ensure that it has the
> right uniqueness properties.
>
> -Frank.
>
>
> Michael Behrens wrote:
> > Just some of my thoughts/ideas on the topic....
> > I view abstract names simply as resource GUIDs which could be
> > persistent, shared, and referenced over time (meaning the abstract
> > name will never change).
> >
> > Within BES, I would like to use them in particular for items which are
> > long lived, such as references to an Application Archive in ACS within
> > a job description.  I would expect that the abstract name would
> > survive over a long period of time as machines fail, IPs are
> > re-issued, domain name changes, etc.
> > One could construct a job using the simpler abstract name, save that
> > job (JSDL, etc), and at some time later request the job to execute and
> > the ACS archive could be found, assuming it still exits (in which case
> > the audit logs might be examined for references to that abstract name).
> >
> > I was also curious about the use of them with regard to policy
> > documents (security and agreement) because even if the service host
> > changes, those abstract names are static and therefore would not make
> > the policy documents obsolete.
> >
> > Ian Foster wrote:
> >> I found the call today very helpful.
> >>
> >> One thing that I wanted to get clarification on is the requirement
> >> that motivates a desire for "abstract names" in BES.
> >>
> >> I've heard one, which is that some entity may be handed two or more
> >> references (EPRs) to jobs, and want to know which of these are (not)
> >> unique.
> >>
> >> Are there others?
> >>
> >> Regards -- Ian.
> >>
> >
> > --
> > Michael Behrens
> > R2AD, LLC
> > (571) 594-3008 (cell) *new*
> > (703) 714-0442 (land)
> >
>
> --
> Frank Siebenlist               franks at mcs.anl.gov
> The Globus Alliance - Argonne National Laboratory
>
>