[ogsa-wg] BES query

[Karl Czajkowski]

On Sep 15, Andrew Grimshaw modulated:
...
> As an aside I want to re-iterate that I am not proposing that WS-Names be
> mandatory for all OGSA interactions - only that they be used were
> appropriate - i.e., were one can reasonably assume that clients may need to
> be able to know if to endpoints are the same. I would argue that BES fits
> this description.
> 
> Andrew
> 

Thanks, Andrew.  This seems a good stepping point to raise the
"architectural" issue that came up on a prior BES call and I think (?)
precipitated this discussion.

I have no real issues w/ the idea of abstract names, although I do
think some of the details raised by Frank are interesting. E.g. should
"abstract name" be a syntax in EPRs or actually more of a design
pattern that could be encoded through a number of different EPR
extensions.  In some sense, all that matters is that a client can
recognize that an EPR uses *any* of the "key" encodings that it
understands, at which point comparison is possible.  This seems to be
no more or less onerous than having to handle extensible ("arbitrary")
content inside an AbstractName element.

What concerns me is the continued polarity on the whole concept of the
abstract name pattern. My worry is that abstract naming is a poison
pill that will hurt adoption of BES. I disagree only with the
importance you place on abstract naming for job management... I agree
it can be a nice convenience.

I know from experience w/ WS-GRAM that we can do job management
without abstract names, by leaving identity tracking to the client(s)
of the service.  Basically, we just store and forward whole EPRs.  At
the same time, our GT4 WSRF implementation does embed resource
identity in the EPR and we could trivially copy it into an
AbstractName field or use a method like Frank advocates to just
highlight, "hey, feel free to compare such and such in this EPR."

The only place, to my knowledge, that we currently looks inside EPRs
is actually in a vile hack to mint them from partial addressing
parameters to our command-line tool... a hack I am certainly not
advocating for interop. :-)


karl

-- 
Karl Czajkowski
karlcz at univa.com