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