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

[Frank Siebenlist]

Christopher Smith wrote:
> On 10/11/05 10:35, "Frank Siebenlist" <franks at mcs.anl.gov> wrote:
>   
>> Mark McKeown wrote:  
>>     
>>>>> 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.
>>>   
>>>       
>> Well, I also believe that it's better to keep the IRIs opaque and was
>> suggesting to use the complete IRI itself as an alternative jobId.
>>
>> Whether that could work depends on the use cases we have to consider...
>>
>>     
> See this is exactly what I want to avoid.
>
> Our customers are used to seeing a regular jobID (now if this is generated
> by a higher level scheduler that understands checkpointing and migration and
> the fact that lower level jobids might change, that's fine). The use this
> jobID within command line tools and web portals to access information about
> their job. The web services interfaces are now an additional interface to
> these others. Why should I bring WS baggage along (in the form of EPRs and
> IRIs as identifiers) when I have one that our users understand already. I
> don't want to have to retool my CLI and other existing interfaces to now
> take some other structured identifier.
>
> The abstract name seems to me like a nice way of providing this identifier
> in the context of the WS interface. Sure, many of the alternative proposals
> would do the trick as well, but I had always been under the assumption that
> clients weren't supposed to interpret the EPR elements.
>   

I can relate to your CLI requirement, but as I've noted before, using an 
AbstractName will not solve your warm-body interface problem as all 
globally forever unique IDs are not user friendly.

If I understand it well, then what you want is to work within the 
context of a CLI interaction such that you can use relatively small 
numbers for jobIDs that only have to be unique within that context. In 
other words, your job#12 today will be different from you job#12 
tomorrow, which requires confinement to context.

You could probably still use AbstractNames and use some naming 
convention to essentially concatenate a contextId and a small numbered 
jobId... and define your own URI-schema for that.

Of course if only you were "allowed" to parse those EPR-Address URIs, 
you could do the same thing ;-)

Regards, Frank.

-- 
Frank Siebenlist               franks at mcs.anl.gov
The Globus Alliance - Argonne National Laboratory