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

[Morris Riedel]

Hi Aleksandr,

>-IMO the real question is what such EPRs may be used for. If they planned
as
>-replacements for URLs and *full* such EPR is going to be put into
>-every SOAP header then I would 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.

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.

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.


Take care,
Morris


>------Original Message-----
>-From: pgi-wg-bounces at ogf.org [mailto:pgi-wg-bounces at ogf.org] On Behalf Of
>-Aleksandr Konstantinov
>-Sent: Friday, March 20, 2009 9:10 AM
>-To: pgi-wg at ogf.org
>-Subject: Re: [Pgi-wg] Sec: Agreement on WS-Naming (ref by strawman)
>-
>-On Friday 20 March 2009 02:42, m.riedel at fz-juelich.de wrote:
>-> Hi security folks,
>->
>->   in preparation of tomorrow I scanned the WS-Naming spec (GFD109) since
there
>-was an optional (MAY) dependency in the strawman doc of it.
>->
>-> ### Goal:
>->
>-> (a)
>-> We are discussing the WS-Naming specification...
>->
>-> (b)
>-> ... because we want to survey what's is adoption status is in production
setups is
>-and what impacts might occur when implementing it...
>->
>-> (c)
>-> ... in order to find out if the WS-Naming dependency makes sense for PGI
in
>-general and for our security setup in particular.
>->
>->
>-> ### Bottom line of spec contents
>->
>-> # Defines an Endpoint Identifier Profile -> WS-A add-ons
>-> # WS Address Endpoint identifier Profile -> WS-A add-ons
>-> # Endpoint Resolvers Profiles -> portType
>->
>->
>-> ### Possible Conclusions:
>->
>-> # (A) As discussed earlier, this is yet another profile that increases
the size of an
>-EPR significantly -> while one spec adoption might not be critical,
adopting WS-
>-Naming together with OGF Sec Addressing and VO lists in WS-MetaData
elements
>-of EPRs might be together a 'just too big' EPR to be realistic - apart
from the
>-functionality of the necessary resolvers in particular for WS-Naming.
Bottom line:
>-Too much for the EPR - rather covered by an appropriate information
service
>-
>-
>-IMO the real question is what such EPRs may be used for. If they planned
as
>-replacements for URLs and *full* such EPR is going to be put into
>-every SOAP header then I would 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.
>-
>->
>->
>-> ### Questions:
>->
>-> # (A) Which middleware platform is adopting it currently and has precise
plans to
>-adopt it in the near future. We can list for now GENESIS-II adopting it
while I know
>-that UNICORE does not and has no precise plans for it now - what about
others like
>-gLite, ARC, or NAREGI?
>-
>-ARC adopted EPR in development trunk but not using it for anything more
than
>-enhanced URL. We currently have no plans to adopt it for any other
purposes.
>-
>->
>-> # (B) Is GLUE covering partly the information of getting endpoints for
unique
>-names or something similiar like renewable references?
>->
>->
>-> The discussion before the TelCon might increase our progress...
>->
>->
>-> Your co-chair,
>-> 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 at 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.'
>->
>->
>->
>-> -------------------------------------------------------------------
>-> -------------------------------------------------------------------
>-> 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
>-> -------------------------------------------------------------------
>-> -------------------------------------------------------------------
>-> _______________________________________________
>-> Pgi-wg mailing list
>-> Pgi-wg at ogf.org
>-> http://www.ogf.org/mailman/listinfo/pgi-wg
>->
>-_______________________________________________
>-Pgi-wg mailing list
>-Pgi-wg at ogf.org
>-http://www.ogf.org/mailman/listinfo/pgi-wg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3550 bytes
Desc: not available
Url : http://www.ogf.org/pipermail/pgi-wg/attachments/20090320/af7e1ff8/attachment.bin