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@univa.com