Hi Frank, A number of points/questions... By advocating using the Address element of the EPR as the AbstractName are you saying that ReferenceParameters should NOT be used to map messages to backend resources? (Two WSRF EPRs can have the same Address element but use ReferenceParameters to map to different WSRF resources) The Address is an IRI, ie it can be a URN. It has never been clear to me how EPR's that use URNs in the Address element should be used, though people seem quite keen on them. Either the client can somehow map the URN to a physical network location or it can get another service to resolve the URN to a physical network location - are you adovcating using URNs as the Address element? Regarding Chris's desire to be able to pass the LSF jobid back to the client somehow - it could be included in the EPR's Metdata, possibly RDF could be used to mark up the Metadata to indicate that it is a LSF jobid. In this way the Address IRI can be kept opaque. There is an interesting question as to whether sending the LSF jobid back to the client somehow breaks encapsulation - eg if I submit a job, the job is allocated a local jobid, the job is checkpointed, stopped then restarted on a different system with a different local jobid. cheers Mark
Hi Michael,
As I argued in my reply to Chris, you should be able to use the actual EPR's Address for this purpose if you consider it as a simple identifier instead of an endpoint reference, and if you ensure that it has the right uniqueness properties.
-Frank.
Michael Behrens wrote:
Just some of my thoughts/ideas on the topic.... I view abstract names simply as resource GUIDs which could be persistent, shared, and referenced over time (meaning the abstract name will never change).
Within BES, I would like to use them in particular for items which are long lived, such as references to an Application Archive in ACS within a job description. I would expect that the abstract name would survive over a long period of time as machines fail, IPs are re-issued, domain name changes, etc. One could construct a job using the simpler abstract name, save that job (JSDL, etc), and at some time later request the job to execute and the ACS archive could be found, assuming it still exits (in which case the audit logs might be examined for references to that abstract name).
I was also curious about the use of them with regard to policy documents (security and agreement) because even if the service host changes, those abstract names are static and therefore would not make the policy documents obsolete.
Ian Foster wrote:
I found the call today very helpful.
One thing that I wanted to get clarification on is the requirement that motivates a desire for "abstract names" in BES.
I've heard one, which is that some entity may be handed two or more references (EPRs) to jobs, and want to know which of these are (not) unique.
Are there others?
Regards -- Ian.
-- Michael Behrens R2AD, LLC (571) 594-3008 (cell) *new* (703) 714-0442 (land)
-- Frank Siebenlist franks@mcs.anl.gov The Globus Alliance - Argonne National Laboratory