Andrew:
I'm not ignoring you: either I hadn't heard you express the use cases
below (I haven't been on all the calls) or I hadn't internalized you
doing so. I appreciate you taking the time to write them down: this
information is very helpful.
Three comments on the use cases:
1) These use cases, like Chris Smith's, do not imply a need for names
that are "globally unique in time and space." The only
requirement is that names be unique with respect to the scope of the
activities that the user wants to monitor or track. This might seem a
minor point, but I think it's an important one: as Chris pointed out, a
sensible key to use as a name in #1 could be, in some circumstances, e.g.
the LSF jobid. That choice of key is prohibited by the current WS-Name
definition.
2) In use case #1, I think you assume that a notification has the form
"job with epr E has status S." Certainly, if that was the case,
then you'd face the problem of determining which job that EPR referred
to, something that you can't do without the ability to compare EPRs. But
in WS-Notification, at least, when a client subscribes to notifications
it can supply, as the callback address, an EPR to a unique WS-Resource.
So the notification delivers the message "status S" to the
subscription for job with epr E. Thus, there is no need to include a key
in the EPR for the purpose of disambiguation.
3) Use case #2 makes sense to me. I could also do this without an
AbstractName, by passing around an XML structure containing an
application-specific key and the EPR--or, more likely, embedding the EPR
in a larger application-specific structure that I have created for other
purposes. But clearly an AbstractName could usefully be applied
here.
Ian.
At 12:03 PM 11/16/2005 -0500, Andrew Grimshaw wrote:
Ian,
I did give a scenario
you just chose to ignore it. Here are two:
1) As a client of BES I
want to be able to keep track of the activities I start. Suppose I have
one hundred going. I want to build a data structure that keys off of the
activity. Id like the handle I get back from the BES container (which is
basically acting like a factory) to have a keyin it I can use so that
when I get notifications about the activity, or some other services wants
to talk about the activity I have some way to associate and search for
the activity information I am keeping.
2) Using the WS-name
(specifically the abstract name) to correlate information flows about an
activity. (This is the example I have used several times.)
The requirement in both
cases is to be able to identify when two EPRs refer to the same
activity.
Andrew
From: Ian Foster
[mailto:foster@mcs.anl.gov]
Sent: Wednesday, November 16, 2005 9:33 AM
To: Hiro Kishimoto; Andrew Grimshaw; Tom Maguire; Frank
Siebenlist; Smith Chris; Mark Morgan
Cc: Savva Andreas
Subject: Re: naming issues resolution process discussion (Re:
[ogsa-wg] Proposed agenda for Nov. 16 call)
Hiro:
Ahead of the call, I'd like to raise the question again of what
application requirements motivate the use of WS-Names in BES. I asked
this on the last call, and my question wasn't answered. I asked the
question again via email, and Chris replied with what turned out to be a
requirement for something different than WS-Names. I think it would be
really helpful to have a list of requirements as a basis for
discussion.
Ian.