Re: [Pgi-wg] Sec: Agreement on WS-Naming (ref by strawman)

Right, but if I have an EPR obtained from UNICORE-BES (wsa:To + referenceproperties) that a client of ARC can't handle it rightly would break our desired interop by maybe just using wsa:To URIs... ...it seems like we have a lot wheels to work on...one after another. Let's not give up - at least the right set of people are this time together in the group representing the right middleware assembly... I'm delighted to join the call soon... In CET is currently 3:30 p.m. Take care, 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: Duane Merrill <dgm4d@virginia.edu> Date: Friday, March 20, 2009 3:22 pm Subject: Re: [Pgi-wg] Sec: Agreement on WS-Naming (ref by strawman)
So I see a demand that we discuss if our services are contacted with WS-Addressing or not.
In case this thread turns into a referendum on the merits of WS- Addressing,I would like to point out that that the Basic Execution Service (BES) spec incorporates EPRs into its interface.
So, if PGI has apsirations to discuss anything that resembles BES, supportfor WS-Addressing would be a Good Idea if for no other other reason that to not have to completely re-invent the BES wheel (again).
-Duane
------------------------------------------------------------------- ------------------------------------------------------------------- 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 ------------------------------------------------------------------- -------------------------------------------------------------------

On Fri, Mar 20, 2009 at 10:30 AM, <m.riedel@fz-juelich.de> wrote:
but if I have an EPR obtained from UNICORE-BES (wsa:To + referenceproperties) that a client of ARC can't handle it rightly would break our desired interop by maybe just using wsa:To URIs...
The beauty of WS-Addressing is that reference parameters are opaque. As a client, *you don't need to know* how to handle them. And as a service, you don't need to know how to handle any other service's reference parameters either. Only your own (and only then if you decide to have them.) -Duane

On Friday 20 March 2009 16:30, you wrote:
Right,
but if I have an EPR obtained from UNICORE-BES (wsa:To + referenceproperties) that a client of ARC can't handle it rightly would break our desired interop by maybe just using wsa:To URIs...
EPRs produced by UNOCORE-BES are handled by ARC clients properly - according to BES specs. That is like opaque blob. BES does not specify that EPR representing BES activity is meant for contacting BES service. It is only meant to identify activity. Of course maybe this is not that BES people mean. But this is that they wrote. A.K.
...it seems like we have a lot wheels to work on...one after another.
Let's not give up - at least the right set of people are this time together in the group representing the right middleware assembly...
I'm delighted to join the call soon...
In CET is currently 3:30 p.m.
Take care, 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: Duane Merrill <dgm4d@virginia.edu> Date: Friday, March 20, 2009 3:22 pm Subject: Re: [Pgi-wg] Sec: Agreement on WS-Naming (ref by strawman)
So I see a demand that we discuss if our services are contacted with WS-Addressing or not.
In case this thread turns into a referendum on the merits of WS- Addressing,I would like to point out that that the Basic Execution Service (BES) spec incorporates EPRs into its interface.
So, if PGI has apsirations to discuss anything that resembles BES, supportfor WS-Addressing would be a Good Idea if for no other other reason that to not have to completely re-invent the BES wheel (again).
-Duane
------------------------------------------------------------------- ------------------------------------------------------------------- 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 ------------------------------------------------------------------- -------------------------------------------------------------------

EPRs produced by UNOCORE-BES are handled by ARC clients properly - according to BES specs. That is like opaque blob. BES does not specify that EPR representing BES activity is meant for contacting BES service. It is only meant to identify activity. Of course maybe this is not that BES people mean. But this is that they wrote.
Exactly. EPRs generated by a service during the create activity operation are only supposed to have meaning to that service - to identify the activity. Given a URL from an information service and information on the security profile(s) supported by that service you could formulate an EPR suitable for contacting the BES to create an activity. They resulting activity EPR should then be treated as opaque. Steven
participants (4)
-
Aleksandr Konstantinov
-
Duane Merrill
-
m.riedel@fz-juelich.de
-
Steven Newhouse