naming issues resolution process discussion (Re: [ogsa-wg] Proposed agenda for Nov. 16 call)

[Ian Foster]

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