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 22:49:55 +0100
Message-ID: <99CA63DD941EDC4EBA897048D9B0061D0F676F4E@uspalx20a.pal.sap.corp>
To: "Jonathan Marsh" <jmarsh@microsoft.com>, <public-ws-addressing@w3.org>

>-----Original Message-----
>From: public-ws-addressing-request@w3.org 
>[mailto:public-ws-addressing-request@w3.org] 
>Sent: Monday, Feb 21, 2005 10:39 AM
>To: public-ws-addressing@w3.org
>Subject: 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 ;-).

Of course it is :-). I did not want to take on the task to fully bake it
before understanding whether the wg wanted to go there or not ;-). Based
on your reply, I take that you consider proposal (3) is too high a bar
to set for some implementations. 

I will be happy with any of the options, but not the status quo. 

--umit
 
>
>> -----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 21:55:41 GMT

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