Chris: I understand your use case. Let me summarize my understanding of where I think we are: Andrew has argued that BES should mandate the use of WS-Names, which are required to have the property of being globally unique in time and space. I asked about the use cases that motivated this requirement, and you replied with a use case in which you want names, but you explicitly do NOT want to be obliged that these names have the global uniqueness property. (As you point out, all you care about is that the names be unique within the context of your LSF system.) That's a perfectly fine use case, but we need to be clear that the names that you propose are NOT WS-Names according to the WS-Naming definition. Thus, if BES was written to require WS-Names, you'd have to include two name fields in your EPR: the WS-Name globally unique address field, and a second field for your LSF jobid. Two further comments: 1) Your use case illustrates exactly why I am not in favor of the WS-Name requirement for BES. As your example illustrates, different situations demand different sorts of names, with different scopes and semantics. No one approach can meet all requirements. Indeed, in most cases I suspect this WS-Name field will be passed around and never used. 2) This exchange also suggests to me that there may be some lack of clarity in the requirements that motivate this aspect of the BES design. Ian. At 04:57 PM 11/10/2005 -0800, Christopher Smith wrote:

...

I'm concerned that the following two notions may be inconsistent:

a) WS-Names should be globally unique (Andrew)

b) The WS-Name can be used to pass a LSF jobid (Chris)

Or is Chris proposing that LSF be changed to generate its jobids with whatever scheme WS-Naming proposes to ensure global uniqueness? (If it doesn't, then I don't think that Chris can guarantee that the names that LSF generates and the names that someone else generates will not collide.)

For me, these names are all about context. Within an LSF environment (including an LSF multicluster environment), the LSF jobid is sufficient, and generating another globally unique identifier doesn't really add much value.

If I'm in a context where I'm dealing with multiple systems that will be providing me EPRs for interacting with "jobs", then I'll need a higher level software layer to shield me from the lower level details, and here globally unique (well ... at least contextual globally unique) identifiers are required, and add more value.

So let's circle back on this discussion for a moment. You asked for some use cases for the use of abstract names, and I provided one (perhaps you don't agree with my usage of abstract names, but that's this side discussion).

This use case is one that we see all the time. Imagine an application "workbench" (e.g. something like Fluent or Sybyl), that exports a special BES service to run and manage domain specific jobs through its own "gateway" to LSF. Imagine then, if you will, a higher level job "viewer" interface that then produces another EPR for watching jobs (maybe so I can aggregate my job views from multiple workbenches). A job submitted through the workbench is viewable through the viewer, but they have different EPRs. The LSF jobid in this case is the abstract name that let's me know they are the same thing. And this jobid is as unique as it needs to be within this context. If I embed this identity information in the EPR, then how do the two gateways share this information? How can they if they are hosted at different SOAP endpoints?

-- Chris

_______________________________________________________________ Ian Foster www.mcs.anl.gov/~foster Math & Computer Science Div. Dept of Computer Science Argonne National Laboratory The University of Chicago Argonne, IL 60439, U.S.A. Chicago, IL 60637, U.S.A. Tel: 630 252 4619 Fax: 630 252 1997 Globus Alliance, www.globus.org