This is a static archive of the previous Open Grid Forum GridForge content management system saved from host forge.ogf.org file /sf/go/projects.ggf-editor/discussion.rec_ws_naming_specification.topc4057 at Sun, 06 Nov 2022 09:02:56 GMT SourceForge : Post

Project Home

Tracker

Documents

Tasks

Source Code

Discussions

File Releases

Wiki

Project Admin
Project: Editor     Discussion > REC:WS-Naming Specification > Should not use [MetaData] to identify resources > List of Posts
Forum Topic - Should not use [MetaData] to identify resources: (5 Items)
View:  as 
 
 
Should not use [MetaData] to identify resources
It is in fact contained in the Web Services Addressing 1.0 specification itself:

[[The Architecture of the World Wide Web, Volume One [AoWWW] recommends [AoWWW, Section 2] the use of URIs to identify 
resources. Using abstract properties of an EPR other than [destination] to identify resources is contrary to this 
recommendation. In certain circumstances, such a use of additional properties may be convenient or beneficial; however, 
when building systems, the benefits or convenience of identifying a resource using reference parameters should be 
carefully weighed against the benefits of identifying a resource solely by URI as explained in [AoWWW, Section 2.1] of 
the Web Architecture.]]

http://www.w3.org/TR/ws-addr-core/#resourceidentification

Noah Mendelsohn, from the TAG, mentioned WS-Naming as a bad example during a workshop last February.

Philippe Le Hegaret, W3C Architecture Domain Leader
Re: Should not use [MetaData] to identify resources
1) The WS-Naming[1] Endpoint Identifier (EPI) is a URI, actually IRI. This is consistent with the Architecture of the 
World Wide Web, Volume One [2] Section 2, which recommends the use of URIs to identify resources.

2) One option provided by WS-Naming Section 4.3 mandates that the wsa:Address field (mapped to the [destination] when 
appearing in the message) possess the properties of an EPI, e.g. uniqueness in space and time WS-Naming Section 4.1. 
This is a stronger requirement than normally placed on the wsa:Address but strongly aligned with the goals of the AoWWW 
Section 2.2.

3) The presence of IRIs in both the wsa:Address and the EPI in the EPR amounts to the association of aliases for the 
resource. Aliases are indeed discouraged by the AoWWW Section 2.3.1, which reads.

"Although there are benefits (such as naming flexibility) to URI aliases, there are also costs. URI aliases are harmful 
when they divide the Web of related resources. A corollary of Metcalfe's Principle (the "network effect") is that the 
value of a given resource can be measured by the number and value of other resources in its network neighborhood, that 
is, the resources that link to it."

The impact on the "network effect" caused by the two aliases is mitigated by the explicit association of these aliases 
in the EPR.

Actually, the aim of WS Naming is to prevent the creation of multiple aliases of equal (heavy) weight. The EPI is 
intended as the single, persistent identifier of the resource. In WS Naming the wsa:Address is the (temporary) 
destination of a messages intended for the resource identified by the EPI. Use cases of the WS-Naming working group 
identify the unavoidable mobility of resources. The limitation that the wsa:Address of a resource is (in most general 
practice) both the identity and the message destination means that, in the presence of mobility, aliases are inevitable.
 It is one of the aims of WS-Naming to provide for persistent, unique identifiers for mobile resources.

4) Note that WS-Naming says nothing about the use of ReferenceParamenters for identification, a practice we discourage, 
as it splits the notion of identifier across two fields in the EPR.

I hope this clarifies the position of the WS-Naming working group.

[1] WS-Naming Public Comment Draft
http://www.ogf.org/Public_Comment_Docs/Documents/Jan-2007/draft-ogf-ws-naming-spec-006.pdf

[2] AoWWW
http://www.w3.org/TR/webarch/
or
http://www.w3.org/TR/2004/REC-webarch-20041215/


[3] WS-Addressing
http://www.w3.org/TR/ws-addr-core/
or
http://www.w3.org/TR/2006/REC-ws-addr-core-20060509/
Re: Should not use [MetaData] to identify resources
On Fri, 2007-05-11 at 10:08 +0100, David Snelling wrote:
> > Response:
> > 
> > 1) The WS-Naming[1] Endpoint Identifier (EPI) is a URI, actually IRI.  
> > This is consistent with the Architecture of the World Wide Web,  
> > Volume One [2] Section 2, which recommends the use of URIs to  
> > identify resources.

Correct, except that this identifier comes in addition to the
[destination] property, which is specifically not recommend in
WS-Addressing section 2.6: "Using abstract properties of an EPR other
than [destination] to identify resources is contrary to this
recommendation".

> > 2) One option provided by WS-Naming Section 4.3 mandates that the  
> > wsa:Address field (mapped to the [destination] when appearing in the  
> > message) possess the properties of an EPI, e.g. uniqueness in space  
> > and time WS-Naming Section 4.1. This is a stronger requirement than  
> > normally placed on the wsa:Address but strongly aligned with the  
> > goals of the AoWWW Section 2.2.

The profile described in section 4.3 is indeed aligned with the
WS-Addressing 1.0 specification, but that's not the case for the profile
in section 4.1, which relies on information included in the metadata
section.

Regards,

Philippe
Re: Should not use [MetaData] to identify resources
Philippe (and others),

A few comments on this thread.

First, keep in mind that we had a set of use cases and requirements that
WS-Addressing alone did not satisfy. Thus, we used the WS-Addressing
extensibility elements.

Second, a "must" requirement for us was that our solution must not break
existing tooling, i.e., an EPR that used WS-Naming extensions must be usable
"as-is" by tools that do not understand the protocol. Given that 
most (all?) current tooling assumes the address field is an http - if you
put some other type of URI in the wsa:address field the tooling will choke
and die.

Third, let's be clear about semantics. Addresses and identities (names) are
two different things. An address tells you how to talk to some thing - not
what the thing is. A named (identified) thing may have many addresses over
time - or in fact many at any given time. This is classic distributed
systems - see all of the projects in the 80's and 90's, Sprite,
Eden/Emerald, Clouds, ..... and so on.  The wsa:address is just that - an
address - not an identifier. We wanted identifiers (abstract names, whatever
you want to call them.) 

Fourth, we wanted to be able to compare two EPR's. Given that the
WS-Addressing specification explicitly states that there is no way to
compare EPR's based on a canonical representation, we embedded meta data
that can be used by WS-Naming aware clients to see if two EPR's refer to the
same entity. Note that in section 2.3 of the WS-Addressing spec,
"This specification provides no concept of endpoint identity and therefore
does not provide any mechanism to determine equality or inequality of EPRs
and does not specify the consequences of their equality or inequality.
However, note that it is possible for other specifications to provide a
comparison function that is applicable within a limited scope." 

We need to determine if two EPR's refer to the same logical endpoint so that
a client can make reasonable decisions regarding caching, whether the "same"
entity was involved in an action, etc.


This is EXACTLY what we have done.

Similarly, also from section 2,
"Flexible and dynamic exchange of endpoint information in tightly coupled
environments where communicating parties share a set of common assumptions
about specific policies or protocols that are used during the interaction."

Fifth. Because one cannot assume that metadata is sent in SOAP headers EPR
minters may choose to duplicate EPI information elsewhere, e.g., in the
reference parameters - or in the wsa:address field itself. 


Note: there is no section 2.6 in 
http://www.w3.org/TR/2005/CR-ws-addr-core-20050817/ws-addr-core.pdf
which is the version of the specification that (a) comes up when I google
WS-Addressing, and (b) was current when we had our last round of discussions
on this.

Andrew
Re: Should not use [MetaData] to identify resources
Hi Andrew,

I agree all of your comments except the final Note.

> Note: there is no section 2.6 in 
> http://www.w3.org/TR/2005/CR-ws-addr-core-20050817/ws-addr-core.pdf
> which is the version of the specification that (a) comes up when I google
> WS-Addressing, and (b) was current when we had our last round of discussions
> on this.

Although your statement is true, the WS-naming specification normatively refers to "9 May 2006" version and it has 
section 2.6.

Hiro Kishimoto

 
 


The Open Grid Forum Contact Webmaster | Report a problem | GridForge Help
This is a static archive of the previous Open Grid Forum GridForge content management system saved from host forge.ogf.org file /sf/go/projects.ggf-editor/discussion.rec_ws_naming_specification.topc4057 at Sun, 06 Nov 2022 09:02:56 GMT