Re: Issue i048 - summary of discussion

There is an additional aspect to the comparison of two EPRs:
Extensibility points may define how comparison is made wrt to the 
extensibility point.

Consider the following two EPRs E1 and E2:

E1:
<wsa:EndpointReference>
   <wsa:address>urn:foobar:123</wsa:address>
   <somens:ext>
     <anotherns:foo>123</anotherns:foo>
     <anotherns:bar>abc</anotherns:bar>
   </somens:ext>
</wsa:EndpointReference>

E2:
<wsa:EndpointReference>
   <wsa:address>urn:foobar:123</wsa:address>
   <somens:ext>
     <anotherns:bar>abc</anotherns:bar>
     <anotherns:foo>123</anotherns:foo>
   </somens:ext>
</wsa:EndpointReference>

The extension somens:ext may specify that the order of the children EII 
is not relevant in comparison. If the user of the EPRs understands the 
extension somens:ext, it can conclude that E1 and E2 are in fact the same.

-Anish
--

Yalcinalp, Umit wrote:
> 
> 
>>-----Original Message-----
>>From: public-ws-addressing-request@w3.org 
>>[mailto:public-ws-addressing-request@w3.org] 
>>Sent: Monday, Feb 07, 2005 7:14 AM
>>To: public-ws-addressing@w3.org; public-ws-addressing-request@w3.org
>>Subject: Issue i048 - summary of discussion
>>
>>
>>I took an informal (to judge from its absence in the minutes)  
>>action item
>>to summarize the dicsussion of issue 48. Here is is; please 
>>comment if you
>>think I forgot/mischaracterized any of the main arguments of the
>>discussion:
>>
>>1. New issue [1] is proposed out of the following concerns: 
>>Section 2.3 as
>>modified per resolution of issue 1 has the consequence of requiring two
>>EPRs with the same address field to correspond to endpoints 
>>with identical
>>metadata. Problems and concerns raised about this new 
>>requirements are many
>>[2, 3, 4]:
>>
>>   *. it makes common Web services deployment architectures out of
>>compliance with the WS-Addressing specification. In 
>>particular, it would
>>prevent gateway configurations.
>>   *. it is over-prescriptive and inconsistent with the 
>>general approach
>>of making WS-A a minimum common base able to support on a wide 
>>variety of
>>usages scenarios and more complex protocols (lifecycle or comparison
>>itself).
>>   *. it a brand new restriction no supported by any other 
>>Web services
>>specification.
>>   *. it is an accidental result of a leftover section whose 
>>only purpose
>>was always to distinguish between properties and parameters.
>>
>>The proposal is to remove Section 2.3 of the specification [2].
>>
>>2. Views opposed to this proposal have been expressed. The 
>>major arguments
>>are:
>>
>>  *. removing Section 2.3 would change the semantics of reference
>>parameters to explicitly maintain the URI to metadata 1 to 1 
>>relationship
>>[5].
>>  *. given a gateway configuration, a common network address can be
>>considered to be endowed with the union of the metadata of all services
>>that share that address [6].
>>  *. it is always possible to use different logical addresses for all
>>these services even if they share the same network endpoint [7].
>>
>>Counter-proposal: remove Section 2.3 but rewrite description 
>>of reference
>>parameters to maintain the one to one relationship between URI 
>>address and
>>endpoint metadata,  further clarifying the point by 
>>introducing the term
>>"resource" (as in Web resource) into the WS-A specification to indicate
>>individual Web services [5]. I assume that there is a second implicit
>>counter-proposal of closing the issue w/o change to the spec.
>>
> 
> 
> Here is my take on this matter, followed by a proposal.
> 
> Issue:
> 
> I would like to look at this problem of what we are gaining by providing
> a comparison of endpoint references. From a client's perspective, the
> comparison of endpoints may only be useful if the comparison were to
> indicate interchangeability. This means that given two EPRs, a client
> could toss away one of them iff they are determined to be the same,
> meaning indistinguishable for all practical purposes. 
> 
> Given two EPRs, I believe a client can only determine that they refer to
> the same endpoint at best. We can say nothing more nothing less. 
> 
> I claim that reference parameters may be significant in differentiating
> between two EPRs. Again, I mean EPRs, not to be confused with endpoints.
> I don't mean that reference parameters are significant for
> differentiating endpoints for this discussion. However, they may be for
> distinguishing between EPRs depending on why EPRs were issued in the
> first place. Differentiation of EPRs is only useful in usage, again the
> usage I have in mind is whether two EPRs are interchangeable. 
> 
> We have recently resolved Issue 20, subissue iv [8] and clarified the
> definitions and relationships between EPR, endpoint, and endpoint
> components.  There may be multiple EPRs that refer to a single endpoint.
> This does not mean that the set of EPRs that refer to the same endpoint
> are interchangeable, but these EPRs are aimed to communicate with the
> SAME endpoint. 
> 
> For example: 
> 
> -- Two separate EPRs may be created for two different clients (one
> each). Does this mean that these EPRs are the same, meaning
> interchangeable? Does this mean that an EPR issued for one client can be
> used by another? I claim most likely not, although both EPRs refer to
> the same endpoint. 
> 
> -- An EPR may contain data via reference parameters (again I stress some
> application specific data here, NOT to be confused about metadata about
> the endpoint as consistent with our current understanding!). Assume that
> two EPRs have reference params that differ wrt some data. Does this mean
> that the two EPRs are the same? It depends, and most probably not. For
> example, if an EPR contains a reference param contain a date to indicate
> when the EPR is created, two different EPRs will contain two different
> dates. Do these EPRs refer to the same endpoint? You betcha. Are they
> the same? The answer is: It depends. Perhaps my application does not
> allow access to the endpoint with EPRs that were created a year ago and
> require the client to get a new EPR. Maybe it does. The answer to the
> comparison question is highly application dependent. Since the reference
> parameters are opaque to the client, the client can not answer this
> question, but an EPR minter can. 
> 
> -- Currently we require per our SOAP binding to use the endpoint address
> and the reference parameters in an EPR  to communicate with the
> endpoint. However our comparison rules may seem to indicate that two
> EPRs they are the same if their addresses are the same. Again, if the
> comparison is about interchangeability, I may incorrectly conclude that
> if I had two EPRs for the same endpoint, one with reference params and
> one without, I could use the the second one by omitting the reference
> parameters in communicating with the endpoint. (They were supposed to be
> interchangeable after all!) This incorrect conclusion would violate the
> SOAP binding and would create a paradox in our specification ;-) 
> 
> -- Given two EPRs, one with extensibility and one without, how can we
> safely say that two EPRs are the same? We just can not determine that
> without knowing the nature of the extensibility as extensibility may be
> able to change the EPR in an application specific manner. 
> 
> I can give more examples, but I do hope you get the idea. In all these
> cases above, however, we can safely determine whether two EPRs refer to
> the same endpoint by comparing their addresses. 
> 
> IMO, only an endpoint (or EPR minter) knows whether two EPRs are
> interchangeable, not the clients. This is consistent with the view that
> reference parameters are opaque from WS-A perspective. Therefore, if we
> "really" want to solve the comparison (interchangeability) problem, it
> is NOT the client who would be able to determine the answer to this
> question. This notion is application specific. Therefore, only an
> endpoint can safely determine whether two EPRs who refer to it are the
> indeed interchangeable. If we want to solve this problem correctly, we
> should explore going down this route relying on the endpoint to answer
> this question instead. 
> 
> Conclusion: 
> 
> The beauty is in the eyes of the beholder. Given two EPRs we can only
> determine that two EPRs refer to the same endpoint. Nothing more,
> nothing less. Even if two EPRs refer to the same endpoint, they may be
> or may not be interchangeable. It all depends on what the EPR minter has
> intended for a specific client, usage of some internal application data,
> etc. As I illustrated, the reference parameters may be significant for
> distinguishing between EPRs, not endpoints. I say "may be", NOT "must
> be", as we are talking about and making wild speculations of application
> dependent data here which is completely opaque to a client in WS-A. 
> 
> Proposal: 
> 
> I believe that the current status quo is really harmful and misleading
> for all purposes. I will be strongly against the status quo and closing
> the issue. 
> 
> There are three different things we can do: 
> 
> (1) Remove Section 2.3 and clean up the confusion we have created as
> proposed by Paco.  
> (2) Change 2.3 to make it consistent with the resolution of Issue 20 iv,
> by illustrating that EPRs are not interchangeable and by clarifying how
> they refer to the same endpoint that use the same metadata.  
> (3) Add capability for endpoints to determine whether two EPRs are the
> indeed interchangeable. 
> 
> Lets look at the details: 
> 
> Proposal for (2) 
> 
> Per [6], a gateway configuration can be considered to be endowed with
> the union of all the metadata of all services that share that address.
> However the following section is misleading for this as it is
> inconsistent with the decision we just made [8]. 
> 
> {The following rule clarifies the relation between the behaviors of the
> endpoints represented by two endpoint references with the same
> [address];
> - The two endpoints accept the same sets of messages, and follow and
> require the same set of policies. That is, the XML Schema, WSDL, and
> policy and other metadata applicable to the two references are the
> same.}
> 
> Instead it should be corrected to say: 
> 
> {The following rule clarifies the relation between the behaviors of the
> endpoints represented by two endpoint references with the same
> [address];
> - The two endpoint references refer to the same endpoint that accepts a
> set of messages, follow and require a set of policies that are defined
> by a (set of) XML Schema(s), WSDL(s), and policies and other metadata
> applicable. Hence, these endpoint references are designed to utilize the
> set of messages, policies and descriptions that apply to the specific
> endpoint. 
> }
> 
> Other wordings are welcome. 
> 
> Proposal for (3). 
> 
> I observe that only an endpoint can determine whether two EPRs are
> indeed interchangeable. The best way to solve this problem is to empower
> the endpoint to make the determination instead of the client as follows:
> 
> -- We define a message exchange that contains two EPRs as input and a
> comparison result as output. The output message determines whether two
> EPRs are interchangeable. (i.e. boolean result). 
> 
> -- We require that all endpoints must support this message exchange. 
> 
> -- We could further define the WSDL for the endpoint that supports this
> message exchange as well as the SOAP binding. 
> 
> My preference: 
> 
> The ideal thing is to do (3) as it addresses whether two EPRs are really
> interchangeable and gives the responsibility to where it belongs: the
> endpoint itself. Although I am all for (3), given the timing
> constraints, I am not sure whether this wg will want to go there. I
> strongly believe however that this is the ideal direction to solve the
> comparison problem. 
> 
> If we can not do (3), I would be more inclined to go with (1). Other
> specifications that build on top of WS-A can address comparison if
> desired that suits their needs as also stated in [9]. Proposal (2) helps
> and is consistent with the resolution of Issue 20 subissue iv [8] if we
> were to retain Section 2.3 but realistically it partially addresses the
> interchangeability problem (if that IS the problem we were trying to
> solve in the first place). 
> 
> 
> 
>>Paco
>>
>>[1] http://www.w3.org/2002/ws/addr/wd-issues/#i048
>>[2]
>>http://lists.w3.org/Archives/Public/public-ws-addressing/2005Ja
>>n/0145.html
>>[3]
>>http://lists.w3.org/Archives/Public/public-ws-addressing/2005Ja
>>n/0186.html
>>[4]
>>http://lists.w3.org/Archives/Public/public-ws-addressing/2005Ja
>>n/0170.html
>>[5]
>>http://lists.w3.org/Archives/Public/public-ws-addressing/2005Ja
>>n/0195.html
>>[6] Stated by Marc H. in 1/31 telecom, not refected in the minutes,
>>http://www.w3.org/2002/ws/addr/5/01/31-ws-addr-minutes.html#item08
>>[7] Stated by Marc H. in 1/31 telecom, not refected in the minutes,
>>http://www.w3.org/2002/ws/addr/5/01/31-ws-addr-minutes.html#item08
>>
>>
>>
> 
> 
> --umit 
> 
> [8] http://www.w3.org/2002/ws/addr/5/02/14-ws-addr-minutes.html
> [9]
> http://lists.w3.org/Archives/Public/public-ws-addressing/2005Jan/0167.ht
> ml
> 
>

Received on Monday, 21 February 2005 20:07:16 UTC