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@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@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@mcs.anl.gov The Globus Alliance - Argonne National Laboratory