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


Exactly. +1

-----Original Message-----
From: "Jonathan Marsh" <jmarsh@microsoft.com>
To: "Doug Davis" <dug@us.ibm.com>; "ws-rx@lists.oasis-open.org" <ws-rx@lists.oasis-open.org>
Sent: 5/22/06 6:04 PM
Subject: RE: [ws-rx] i119: EPR comparisons overly restrictive

If the primary issue is that some implementers might incorrectly
piggyback messages because they only look at Address instead of Ref
Params (I agree that is insufficient), we can get by with a much simpler
proposal.  Your proposal defines a lot of things people must do instead
of warning them what they should avoid.  I argue you don't need to tread
through the fire-swamp of EPR comparison to do that.  The result, after
a lot of discussion about what the majority considers a reasonable EPR
comparison algorithm, is disenfranchising a minority of implementations
which could benefit from better (smarter, faster) ways to achieve the
desired optimization.

 

I also think you misconstrue the structure of my argument below.  Points
1, 2, and 3 lead up to the conclusion, which is where I believe the spec
would be harmed by overly proscribing EPR comparison.  The points
individually don't prove harm.  And I think the current proposal is
already over-engineered, brainstorming on ways to make it even more
complex isn't too appealing!  

 

________________________________

From: Doug Davis [mailto:dug@us.ibm.com] 
Sent: Monday, May 22, 2006 4:34 PM
To: ws-rx@lists.oasis-open.org
Subject: Re: [ws-rx] i119: EPR comparisons overly restrictive

 


"Jonathan Marsh" <jmarsh@microsoft.com> wrote on 05/22/2006 05:59:48 PM:
> 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. 

I'm really lost by this one.  How does correctly knowing when a message 
is going to the right place hurt?  Correctly sending an Ack to the right

place can never hurt - however, sending an Ack to an endpoint that 
doesn't know what to do with it can.  Your argument seems backwards 
to me. 

If you're concerned that you won't be able to piggy-back an Ack in 
cases where the wsa:Address is the same but the ref-p's are different 
and therefore lose the optimization then that's an argument for 
the text to say "SHOULD" instead of "MUST".  This allows for an 
implementation that "just knows" to make smarter decisions.  But in 
general I don't believe you can make that kind of assumption. 

> 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). 

I dunno - sounds a bit like you may have a religious objection to it 
since you're basically saying its not realistic to expect people to 
be able to do it.  Can't compare URIs, can't compare ref-p's - can't 
really compare EPRs then.  Some may wonder if this is the beginning 
of a push to get people to encode their ref-p data into the URI 
since while comparing it may be tricky its more do-able than 
comparing ref-p's.  Sure hope not. 

> 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. 

And what can each side expect of the other then? 

>   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. 

Again - sounds like a "SHOULD" to me. 
As for it being a "bug" - I disagree. It will force everyone 
to do only the bare minimum (wsa:Address comparing) and eliminate the 
possiblity of certain scenarios from being supported (like the 
clustered case) by constraining their impl choices. 

I wonder if there's a way to leverage the wsa:Metadata section to 
help here.  Could there be something in there that tells the user 
of it what kind of comparison algorithm it should use.  Or, using 
a variant of Sanjay's idea, place some unique RM ID in there and 
have them compare that.  Wouldn't want it to be a seqID since the 
same EPR can be used for lots of sequences.  Just brainstorming... 
  
>  [  Jonathan Marsh  ][  jmarsh@microsoft.com  ][  http://spaces.msn.
> com/auburnmarshes  ] 
>  



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