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

[Frank Siebenlist]

Hi Mark,

Mark McKeown wrote:
> 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)
>   

I'm afraid that my own preference shown through here as life would be 
simple with just IRIs ;-)

...but no, I realize that the ReferenceParameters will be used to carry 
the dispatch info.

In the past I've given a recipe how one could construct an 
identifier/name from the address+refParameters by essentially 
concatenating the Address value with some base64 blob of the 
canonicalized refParameters (or if space is a consideration, append the 
digest value of the refParmeters...)

This transformation essentially would give you the Address value as the 
name when no refParameters are present.

For this to work, the transformation should be standardized such that 
all parties can generate the same IRI-name, and it still requires a 
profile on the uniqueness properties for the combined 
Address+RefParameters for this to be a useful name (URN).


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

I'm advocating that the Address element's IRI can both be used as an 
URN, i.e. just a name/identifier that is not expected to be resolved to 
anything, and an endpoint reference address. (Note that the latter may 
today provide you with a true communication path to your resource but 
tomorrow it may be stale... but profiling shound ensure that it should 
never, ever refer to a different resource)

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

Right, and one alternative would be to use the Address itself as the jobId.

If the job would migrate to another system with a different local jobId, 
it would also have a different Address IRI, and we need a more stable 
job-name to deal with that, which could be an AbstractName, or could be 
through the renewableReference's IRI that can also be viewed as a jobId.
This points out that if the RenewableReference's IRI can be used as a 
name (URN), then this essentially can be used for the exact same purpose 
as the AbstractName.

Regards, Frank.




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

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