OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-rx message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [ws-rx] i119: EPR comparisons overly restrictive


Jonathan,

Looking over the wall from my usual habitat in TX, I've been following all of this for a while, because of related issues dealt with in TX. A quick thought follows. Apologies in advance if it duplicates or misunderstands.
 
Perhaps you could walk right round this by defining an RX WS-A extension element, which is of a clearly comparable type, and globally unambiguous, e.g. absolute URI. "Interlocutor identity", "endpoint equivalence marker" or some such.

If EPR A and EPR B (or EPR A') have such an element, both with value of "foo" then you can send ack to EPR A on a message to EPR B. You could re-use this same id for the client identification issue for MakeConnection too: reply EPR = anon/polling + interlocutor id.

I think you're right, that in this particular context where false negatives are just deoptimizations of the attempted optimization, "guessing the EPR equivalence" will work, and will, by evolution, chuck out the bad guessers ( in reality, push most implementations to the conservative case of EPR comparison, e.g. bit-for-bit for [address] and [ref params], or indeed to abandon the optimization).

In the client id case for GetMessage/MakeConnection I think you have the problem that false negatives are dangerous. If you misidentify a request to respond as coming from e.g. an unknown client then the two sides will freeze up.

Overall, there seems to be a latent concept of "party to a conversation", which might usefully be surfaced.

Alastair

Jonathan Marsh wrote:
I think you and I are pretty close on this.  We seem to agree that it is
desirable to allow a range of options from no optimization, to a simple
bit-for-bit comparison (though there may even be flavors of this),
through a canonicalized approach, through to what I'll call semantic
equivalence.   An implementation should be free to choose the level it
wishes to invest in, with the understanding that the more you invest,
the more optimization dividends you receive.

We don't seem to agree on the value of providing a non-normative
snapshot of a comparison algorithm in this spec.  IMO, such an algorithm
is likely to miss the sweet spot, provide an illusion of
interoperability when in fact it's just documentation of an
implementation detail, and consume a lot of TC time to work out details,
consume a lot of reader time to, and increase the burden of ongoing
maintenance of the spec.

I don't have a problem addressing the specific issue raised during
interop that reference parameters should be considered when determining
EPR equivalence.  I think the simplest way to address this issue is by
adding a simple warning to implementers along the lines of: "Note that
reference parameters should be considered when determining EPR
equivalence."  In this case the "very least" is perfectly sufficient.

  
-----Original Message-----
From: Anish Karmarkar [mailto:Anish.Karmarkar@oracle.com]
Sent: Monday, May 22, 2006 7:25 PM
To: Jonathan Marsh
Cc: ws-rx@lists.oasis-open.org
Subject: Re: [ws-rx] i119: EPR comparisons overly restrictive

These are all very good point.
But from them I don't necessarily conclude that we should not define
    
an
  
EPR comparison algorithm.

1) WRT to false negatives: I don't think false negatives are
    
themselves
  
a problem -- they result in one not being able to utilize the
optimization. I would hope that if we define a comparison algorithm,
    
it
  
would be stated in a way that would *not* prevent anyone from defining
additional mechanisms to figure out equivalence.
For example, if 2 EPRs are bit for bit the same then they are the
    
same.
  
If they are not (in absence of an equivalence algorithm), then one
cannot make any statement about the equivalence (they may be
    
equivalent
  
or not, one just doesn't know). There may be additional metadata that
tells me that they are (or not). For example, I may know that
http://www.w3.org and http://www.w3c.org are the same. One should be
able to add additional criterion (than the one that we define in WSRX,
if we do at all) to figure out equivalence.

2) WRT to 3a and 3b: if we define a comparison algorithm, an
implementation is not (or should not be) forced to use them. It may
choose to ignore it (and only use, say, bit-for-bit comparison) at the
cost of extra messages and a saving on processing. OR if it is willing
to put additional resources to prevent extra messages, it may use
additional criterion on top of what we define.

One of the feedbacks that I got from the interop was that some
implementations ignore refps when figuring out equivalence -- this is
quite bad for interop. If we don't define an equivalence algorithm, at
the very lease we should include a warning about EPR comparisons and
pitfalls.

-Anish
--

Jonathan Marsh wrote:
    
I don't have any religious objection to defining EPR comparison
mechanisms in specific circumstances (as WS-Addressing allows), but
      
in
  
this case I fail to see why defining such a mechanism is a good
      
thing.
  
In fact it seems harmful.



1) Piggybacking is an optimization, although an important one.
      
Failure
  
to correctly determine that two EPRs are equivalent for the purposes
      
of
  
piggybacking eliminates the possibility to benefit from the
optimization.  The nature of the optimization is in reducing the
      
number
  
of messages sent on the wire.



2) EPR comparison is tricky:

  a) URI comparison is notoriously difficult, unless the URI is
      
simply
  
an identifier (e.g. namespace URI) and not primarily intended to be
dereferenced, in which case simple string comparison suffices.  I
      
don't
  
believe this will suffice for [address] property values.  The
      
current
  
reference to 2396 is confusing and inadequate to describe how URIs
      
are
  
to be compared.  See http://www.ietf.org/rfc/rfc3987.txt section 5
      
for a
  
more thoughtful (and applicable) explanation of why there isn't a
      
single
  
right mechanism.

  b) Comparing canonicalized representations of reference parameters
      
is
  
also difficult.  There might be a broad set of allowable
      
manipulations
  
to reference parameters that result in false positives, e.g.
      
annotating
  
a ref param with an extension attribute (even WS-A does that).



3) Despite the choices made above, both components of the proposed
      
EPR
  
comparison can result in false negatives.  Trading off complexity of
      
the
  
comparison algorithm versus the amount of optimization is a choice
      
that
  
should be left to implementations.

  a) Canonicalization and full IRI normalization are fairly
      
expensive.
  
Some implementations may prefer a simpler mechanism, with
correspondingly higher false negative rates.

  b) Network messaging is fairly expensive.  An implementation
      
wishing
  
to expend extra computational resources to minimize the network
      
traffic
  
should be free to implement as comprehensive a comparison mechanism
      
as
  
they like.



A standardized EPR comparison mechanism writes into the standard
optimization choices that should be left to implementers, and would
force some implementations to become needlessly (from their
      
perspective)
  
complex, and others to dumb-down and miss opportunities for better
optimizations.  Some seem to fear incorrectly piggybacking messages
      
not
  
destined to the message recipient, which is again an implementation
issue (a bug) which the market will easily sort out.


      

  


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]