RE: Issue i048 - summary of discussion

This seems similar to the way that the http rfc "extends" the URI rfc
for comparison of http: uris.  However, most uri based comparisons
ignore the http rfc when doing comparisons, such as the namespace spec,
for simplicity.  

Cheers,
Dave

> -----Original Message-----
> From: public-ws-addressing-request@w3.org
[mailto:public-ws-addressing-
> request@w3.org] On Behalf Of Anish Karmarkar
> Sent: Monday, February 21, 2005 12:01 PM
> To: Yalcinalp, Umit
> Cc: Francisco Curbera; public-ws-addressing@w3.org;
public-ws-addressing-
> request@w3.org
> Subject: 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:37:17 UTC