Hi Aleksandr,

- I would like to know what do You mean by "contacted". If that implies human user is expected to write EPR by hand to make his/her client to contact some service then I disagree.

I refer to contacted as "accessed from a Grid client" w/o avoiding to create the EPR manually - instead the EPR has an URI in wsa:To and maybe referenceproperties to point to a particular resource instance behind the service interface. Q: Isn't A-REX not also accessible via EPRs? Thanks for clarification, Morris -------------------------------------------------------------------------------- Morris Riedel SW - Engineer Distributed Systems and Grid Computing Division Central Institute of Applied Mathematics Research Centre Juelich Wilhelm-Johnen-Str. 1 D - 52425 Juelich Germany Email: m.riedel@fz-juelich.de Info: http://www.fz-juelich.de/zam/ZAMPeople/riedel Phone: +49 2461 61 - 3651 Fax: +49 2461 61 - 6656 Skype: MorrisRiedel 'We work to improve ourselves and the rest of mankind.' ----- Original Message ----- From: Aleksandr Konstantinov <aleksandr.konstantinov@fys.uio.no> Date: Friday, March 20, 2009 12:40 pm Subject: Re: [Pgi-wg] Sec: Agreement on WS-Naming (ref by strawman)

...

Hi Aleksandr,

...

-IMO the real question is what such EPRs may be used for. If

On Friday 20 March 2009 12:21, Morris Riedel wrote: they planned

...

as

...

-replacements for URLs and *full* such EPR is going to be put into -every SOAP header then I wohuld vote strongly against. But if such EPR is just a way -to describe service (same as corresponding section in Glue -document) and are ony meant to be used in some kind of information system/port -then why not.

Just for clarification: With URLs you refer to the wsa:To element of WS-Addressing correct? If so, they are of course in any SOAP message - or I didn't get your point.

With URL I mean URL which was supposed to identify resource. Now with introduction of EPRs we get another layer of indirection in resource identification. That's alright. But EPRs can also be used to describe resource. And that description part may become lenghty. So if PGI goes for EPR I would like to see it profiled which parts of EPR are expected/needed at which place/moment. If my client application queries for some service with specific capabilities and gets 100kB EPR describing who where and how can contact service that is probably ok. But if for contacting that service my application has to insert that EPR into every SOAP message I would like to know which parts of it I can be safely removed in order to avoid buying dedicated optical link to computing center hosting that service. :)

...

Also, if it would be only to put into a kind of information

system I would

...

vote for crunching the EPR in elements that can be probably better searched for by an query instead of putting information into EPR.

I just have to agree.

...

Here, WS-Naming, provides basically a name of a service while

its EPR might

...

change over time (renewable reference). Also the document refers to trackability of messages once you use WS-Naming (e.g. UUID dependency) - so I expect that this information of WS-Naming EPR additions should be part of any SOAP message. But that's only my interpretation from the document.>

Q: Can we agree that each functional service in the EPR space such as OGSA-BES are contacted with an pure EPR using URIs? We don't consider> accessing a BESService simply with an URI - or do we? I would not vote for that.

I would like to know what do You mean by "contacted". If that implies human user is expected to write EPR by hand to make his/her client to contact some service then I disagree.

A.K. _______________________________________________ Pgi-wg mailing list Pgi-wg@ogf.org http://www.ogf.org/mailman/listinfo/pgi-wg

------------------------------------------------------------------- ------------------------------------------------------------------- Forschungszentrum Juelich GmbH 52425 Juelich Sitz der Gesellschaft: Juelich Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498 Vorsitzende des Aufsichtsrats: MinDir'in Baerbel Brumme-Bothe Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender), Dr. Ulrich Krafft (stellv. Vorsitzender), Prof. Dr. Harald Bolt, Dr. Sebastian M. Schmidt ------------------------------------------------------------------- -------------------------------------------------------------------