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

[Christopher Smith]

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