RE: [ogsa-wg] Once upon a time or two ...
There are many issues in this discussion that I don't understand , and this seems a key one. Perhaps the participants could read the following and set me straight? The W3C guidelines on the use of URIs (and hence, I presume, IRIs) is that each resource should be identified by a different URI. URIs can be compared. URIs should not be reused to refer to different resources. I don't know whether these guidelines are adhered to in practice, but on paper they seem to provide the uniqueness and comparison functionality that we require. The problem seems to be that WS-Addressing (or perhaps just some uses of it, e.g. some implementations of WSRF) breaks this nice system, by using the URI to name the access mechanism (the web service) rather than the resource being addressed. Frank has suggested on a couple of occasions that we specify how a unique address can be reconstructed from the wsa:to field and the parameters. Given this step, I would assume that the scenario that Frank considers here would not be permitted:
An EPR-minter can decide to create a new EPR for a resource and reuse an Address that was used for an other resource before.
So, I have many questions: 1. Is the above characterisation an accurate rendition of the W3C position on URIs and IRIs? 2. Do we want stricter limits than the W3C? 3. Can we profile WS-A as Frank suggests? 4. If (3 and not(2)), does that satisfy our requirements? Another advantage of URIs is that publishers are permitted to use their structure to pass back server-specified information and clients are permitted to parse URIs to extract this information. So an LSF system could include the job-id in a certain part of the URI and clients can extract it as necessary. (Although one could argue whether that was any neater than adding a specific XML field). Best wishes, Dave.
-----Original Message----- From: owner-ogsa-wg@ggf.org [mailto:owner-ogsa-wg@ggf.org] On Behalf Of David Snelling Sent: 18 November 2005 15:12 To: Frank Siebenlist Cc: ogsa-wg; ogsa-naming-wg@ggf.org Subject: [ogsa-wg] Once upon a time or two ...
Folks,
Once up on a time or two Frank wrote:
Without the proper uniqueness guarantees for the wsa:Address, the use of ws-naming's AbstractName is meaningless.
The EPR with an embedded AbstractName essentially describes a binding between the Address and the AbstractName. One could argue that this binding is a bit of a flaky assertion without any way to specify time-validity or issuer. As a result, one can not see from an EPR alone when it was issued or whether it is still valid or not.
This would yield the undesirable situation that you would have two EPRs with identical Addresses and two different AbstractNames associated with different resources, and the client would have no way to see which one of the EPRs is valid...
For example, if I have two EPRs with the same Address, where one EPR includes an AbstractName that identifies MyBankAccount and the other includes an AbstractName identifying YourBankAccount, then one of us will not be happy with that situation...
In order to avoid this ambiguity, we need the guarantee from the EPR-minter that Address values will not be reused for different resources: for all times, the Address should either refer to that one and only resource, or it should be invalid (and it is allowed to change between those two states). Furthermore, the EPR-minters should ensure that globally unique Addresses are used for a resource such that different EPR-minters do not (accidentally) use the same Address for different resources. The described uniqueness properties of the Address constitutes a required EPR-minter profile for the use of AbstractNames.
This issue has yet to be addressed to my satisfaction. There have been a number of email exchanges in response to it on several occasions, but none of these threads actually deal with the issue.
Put simply, if you don't put globally-unique-in-space-time requirements on your address (GSR in OGSI speak*) then any similar requirements you put on an Abstract Name (GSH in OGSI speak) are wasted.
I believe that answering this issue will help clarify many of the other threads (miss) associated with this issue.
In particular, I believe Frank is right. Therefore, if an EPR is going to be a WS-Name, the wsa:Address MUST have the same uniqueness properties as the Abstract Name. Then if the answer to the question, "Why do this uniqueness stuff twice?", is "I don't know!", then it seems logical to me that a WS-Name is a profiled EPR along the lines proposed by Tom M.
Thoughts?
Historical Footnote:
* Note: OGSI addressed this issue in GSRs by requiring that clients could detect when the GSRs were stale and that services reject them if a client attempted to use them. GSHs had uniqueness constraints placed on them.
--
Take care:
Dr. David Snelling < David . Snelling . UK . Fujitsu . com > Fujitsu Laboratories of Europe Hayes Park Central Hayes End Road Hayes, Middlesex UB4 8FE
+44-208-606-4649 (Office) +44-208-606-4539 (Fax) +44-7768-807526 (Mobile)
Hi Dave, snipped
Another advantage of URIs is that publishers are permitted to use their structure to pass back server-specified information and clients are permitted to parse URIs to extract this information. So an LSF system could include the job-id in a certain part of the URI and clients can extract it as necessary. (Although one could argue whether that was any neater than adding a specific XML field).
WebArch[1] recommends that URIs should be opaque to the client - if a resource provider encourages a client to reason about his URIs a coupling is created between the client and the resource provider - equivalent to one of Adam Bosworth's shared secrets[2]. The resource provider is tied to an approach to creating URIs that may not be appropriate in the long term. cheers Mark [1] http://www.w3.org/TR/webarch/ [2] http://www.acmqueue.com/modules.php?name=Content&pa=showpage&pid=337&page=1
Best wishes,
Dave.
-----Original Message----- From: owner-ogsa-wg@ggf.org [mailto:owner-ogsa-wg@ggf.org] On Behalf Of David Snelling Sent: 18 November 2005 15:12 To: Frank Siebenlist Cc: ogsa-wg; ogsa-naming-wg@ggf.org Subject: [ogsa-wg] Once upon a time or two ...
Folks,
Once up on a time or two Frank wrote:
Without the proper uniqueness guarantees for the wsa:Address, the use of ws-naming's AbstractName is meaningless.
The EPR with an embedded AbstractName essentially describes a binding between the Address and the AbstractName. One could argue that this binding is a bit of a flaky assertion without any way to specify time-validity or issuer. As a result, one can not see from an EPR alone when it was issued or whether it is still valid or not.
This would yield the undesirable situation that you would have two EPRs with identical Addresses and two different AbstractNames associated with different resources, and the client would have no way to see which one of the EPRs is valid...
For example, if I have two EPRs with the same Address, where one EPR includes an AbstractName that identifies MyBankAccount and the other includes an AbstractName identifying YourBankAccount, then one of us will not be happy with that situation...
In order to avoid this ambiguity, we need the guarantee from the EPR-minter that Address values will not be reused for different resources: for all times, the Address should either refer to that one and only resource, or it should be invalid (and it is allowed to change between those two states). Furthermore, the EPR-minters should ensure that globally unique Addresses are used for a resource such that different EPR-minters do not (accidentally) use the same Address for different resources. The described uniqueness properties of the Address constitutes a required EPR-minter profile for the use of AbstractNames.
This issue has yet to be addressed to my satisfaction. There have been a number of email exchanges in response to it on several occasions, but none of these threads actually deal with the issue.
Put simply, if you don't put globally-unique-in-space-time requirements on your address (GSR in OGSI speak*) then any similar requirements you put on an Abstract Name (GSH in OGSI speak) are wasted.
I believe that answering this issue will help clarify many of the other threads (miss) associated with this issue.
In particular, I believe Frank is right. Therefore, if an EPR is going to be a WS-Name, the wsa:Address MUST have the same uniqueness properties as the Abstract Name. Then if the answer to the question, "Why do this uniqueness stuff twice?", is "I don't know!", then it seems logical to me that a WS-Name is a profiled EPR along the lines proposed by Tom M.
Thoughts?
Historical Footnote:
* Note: OGSI addressed this issue in GSRs by requiring that clients could detect when the GSRs were stale and that services reject them if a client attempted to use them. GSHs had uniqueness constraints placed on them.
--
Take care:
Dr. David Snelling < David . Snelling . UK . Fujitsu . com > Fujitsu Laboratories of Europe Hayes Park Central Hayes End Road Hayes, Middlesex UB4 8FE
+44-208-606-4649 (Office) +44-208-606-4539 (Fax) +44-7768-807526 (Mobile)
Dave, et al. On 22 Nov 2005, at 10:09, Dave Berry wrote:
The W3C guidelines on the use of URIs (and hence, I presume, IRIs) is that each resource should be identified by a different URI. URIs can be compared. URIs should not be reused to refer to different resources.
I don't know whether these guidelines are adhered to in practice, but on paper they seem to provide the uniqueness and comparison functionality that we require.
I found two perspectives on this. 1) In general these guidelines are adhered to in the WS world, but only because I think there is little experience with WS-Addressing. 2) The other perspective hinges on reversing the definition, i.e. a resource is that which is referred to by a URI. In this case the guidance is always adhered to automatically. Example: A search engine that gives localized results based on the IP address of the requester. In this case the W3C Arch line would be that the 'resource' is the same in all cases, but the address has an impact on the 'representation' that the requester sees of the 'resource'. The requester however perceives that they are different resources. Example: An EPR which relies on ReferenceParameters to disambiguate the the WS-Resource would, under (2) above, be interpreted as follows. The 'resource' would be the WS endpoint addressed by the was:Address. The 'WS-Resource' and the 'resource' are in this case different things. All the many WS-Resources accessed through the same endpoint are part of the same 'resource'. The problem is that the description of a WS-Resource and and a 'resource' (W3C Arch) are very similar, so the inconsistency is something to live/cope with.
The problem seems to be that WS-Addressing (or perhaps just some uses of it, e.g. some implementations of WSRF) breaks this nice system, by using the URI to name the access mechanism (the web service) rather than the resource being addressed. Frank has suggested on a couple of occasions that we specify how a unique address can be reconstructed from the wsa:to field and the parameters. Given this step, I would assume that the scenario that Frank considers here would not be permitted:
An EPR-minter can decide to create a new EPR for a resource and reuse an Address that was used for an other resource before.
So, I have many questions:
1. Is the above characterisation an accurate rendition of the W3C position on URIs and IRIs?
See above. It might help or merely confuse further.
2. Do we want stricter limits than the W3C?
The current use made of EPRs by some WSRF implementations is probably a bit loose as opposed to strict wrt the use of RPs to identify WS-Resources.
3. Can we profile WS-A as Frank suggests?
I don't think it is that easy, see earlier mails where RPs may or may not be used to disambiguate. We would probably need to define a named <ogsa:Disambiguator/> element it order to implement Frank's proposal safely, but I've not delved deeply into that yet.
4. If (3 and not(2)), does that satisfy our requirements?
Possibly, but subject to the above issues. -- Take care: Dr. David Snelling < David . Snelling . UK . Fujitsu . com > Fujitsu Laboratories of Europe Hayes Park Central Hayes End Road Hayes, Middlesex UB4 8FE +44-208-606-4649 (Office) +44-208-606-4539 (Fax) +44-7768-807526 (Mobile)
participants (3)
-
Dave Berry -
David Snelling -
Mark McKeown