W3C home > Mailing lists > Public > public-ws-addressing@w3.org > February 2005

RE: Issue i048 - summary of discussion

From: Yalcinalp, Umit <umit.yalcinalp@sap.com>
Date: Mon, 21 Feb 2005 08:14:11 +0100
Message-ID: <99CA63DD941EDC4EBA897048D9B0061D0F676F4B@uspalx20a.pal.sap.corp>
To: "Francisco Curbera" <curbera@us.ibm.com>, <public-ws-addressing@w3.org>, <public-ws-addressing-request@w3.org>



>-----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 07:14:47 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:35:03 GMT