Hi, I am sorry I missed today's call (combination of a partial conflict and the old habit of expecting the call at 3:00-5:00 Pacific). I may be missing something that has already been covered. Apologies for any redundant discussion. I thought that BES is a focus on the container and not the jobs. It is a job execution environment but the abstract names (if any) should be generated before the request reaches the BES container since the job factory is in the job manager or some such entity. I am not seeing the connection between abstract names for jobs and BES. An abstract name for a container makes sense in this context. In this case, a job id may not be appropriate. I would expect that abstract names have a form that is independent of the type of resource or entity that is referred to by this abstract name. The specific aspects that are determined by type would have to be in the payload. As I was typing this, I saw Mike's email. I would agree that something like a GUID would be appropriate. Alternatively a URI that is parameterized in a domain/application manner may also work (this may accommodate the job id requirement that Chris mentions below while having a similar form for other resources/entities too). Abstract names would be unique (as we all know) but I would expect have a validity lifecycle attached to them (could be as simple as at Time to Live possibly embedded in the name). I would not expect that these are for ever persistent and available but may be driven by policy. Expecting otherwise may put a big burden on the implementation. Is the abstract name an optional or required in all cases (whether embedded in the EPR or not i.e. resolved)? I would vote for it to be optional since in some instances generating the name may not be necessary. An example is an ephemeral job (i.e. < 15 - 30 sec for the lifetime). We have many of these jobs in our environment and these are the ones that really stress our schedulers in many of our production pools. The effort to generate and assign and manage abstract name may not be worth the overhead here. An EPR is all that we may have (hopefully the simplest and really necessary parts in the EPR). Thanks! Ravi ________________________________ From: owner-ogsa-wg@ggf.org [mailto:owner-ogsa-wg@ggf.org] On Behalf Of Christopher Smith Sent: Wednesday, November 09, 2005 5:38 PM To: Ian Foster; ogsa-wg@ggf.org; ogsa-naming-wg@ggf.org; OGSA-BES-wg@ggf.org Subject: [ogsa-wg] Re: [ogsa-bes-wg] Abstract names in BES 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.