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
- From: Doug Davis <dug@us.ibm.com>
- To: ws-rx@lists.oasis-open.org
- Date: Mon, 22 May 2006 19:34:22 -0400
"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]