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