[ogsa-bes-wg] Re: [ogsa-wg] Abstract names in BES

[Ian Foster]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/ogsa-wg/attachments/20051110/c190d65c/attachment.htm