RE: Issue i048 - summary of discussion

-1 on option 3: too complex, time-consuming, out-of-scope, and
burdensome for some implementations.

The other options are much better.  I suspect 3 was a straw man ;-).

> -----Original Message-----
> From: public-ws-addressing-request@w3.org [mailto:public-ws-
> addressing-request@w3.org] On Behalf Of Yalcinalp, Umit
> Sent: Sunday, February 20, 2005 11:14 PM
> To: Francisco Curbera; public-ws-addressing@w3.org; public-ws-
> addressing-request@w3.org
> Subject: RE: Issue i048 - summary of discussion
> 
> 
> 
> 
> >-----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 18:40:24 UTC