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

[Frank Siebenlist]

Embedding the jobId in the EPR's Address' URI was not meant to be 
interpreted by the clients, but was meant to give it the same uniqueness 
properties ans the jobId itself.

If that is the case, then the job's Address becomes an alternative name 
for the job - forget the fact that it is also used as a network end 
point: it's just another jobId by itself.

The mapping of the jobId to the job's Address value is resolvable at the 
manager that created the Address (it has to be).

Now the only thing that bothers me is your insistence that some 
warm-body has to be able to "remember" them... isn't it enough to be 
able to easily copy and paste them ?
(note that IDs that are forever globally unique and such are *always* 
"impossible" to remember... so I'm not even sure if that is a realistic 
requirement... unless you have yet another not so abstract name in mind 
with less uniqueness properties).

It's a little difficult to go into details as the use case is somewhat 
sketchy... but the main idea that I wanted to introduce is to treat the 
Address value also as an identifier for the resource.

Regards, Frank.



Christopher Smith wrote:
> I haven't thought too much about it, but it would probably be something like
> the abstract name being the jobid (maybe plus the submit time for some time
> uniqueness if desired). I could then possibly use this to resolve to an EPR
> if needed. The jobid is used for both WS and non-WS interfaces, so that it's
> easier for clients (i.e. people) to remember them and pass them around.
>
> So, say someone gets an email from LSF about the job, which contains the LSF
> jobid, they can then use their portal (which uses the WS interface) to get
> more information.
>
> As for embedding in the EPR's address, I thought that it was not supposed to
> be "interpreted" by the people that they are handed to. :-)
>
>
> Of course, as I mentioned, this could also easily be done by embedding this
> information in the payload of some SOAP messages.
>
> -- Chris
>
>
>
> On 9/11/05 18:24, "Frank Siebenlist" <franks at mcs.anl.gov> wrote:
>
>   
>> Hi Chris,
>>
>> Could you expand a little on the scenario and use case?
>>
>> Will the job id be the abstract name itself or embedded in it?
>>
>> What kind of resolution is needed and when?
>> (jobId=>EPR?)
>>
>> Could the jobId be embedded inside of the EPR's address?
>>
>> Thanks, Frank.
>>
>>
>> Christopher Smith wrote:
>>     
>>> For a mapping of BES to LSF, I would put something like a job id in
>>> the abstract name, so that it could be used outside the web services
>>> world (say with a CLI). Sure, it could be put in the payload of
>>> messages, or retrieved via some explicit call, but it seems reasonable
>>> to use the abstract name for this.
>>>
>>> -- Chris
>>>
>>>
>>>
>>> On 9/11/05 17:28, "Ian Foster" <foster at mcs.anl.gov> 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.
>>>
>>>
>>>
>>>       
>
>   

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