Re: MAPs and SOAP

Could I ask everyone to please step away form the "why change the form 
of ReplyTo on the wire?" argument?  It's not relevant.  We can put 
ReplyTo on the wire however we want, whether or not MAPs are extensible.

The issue is whether I can easily add new kinds of endpoints to the MAPs 
and to the Addressing 1.0 properties, so that, for example, a processor 
wanting to know where ongoing messages could be sent only needs to know 
about WSA and not about an arbitrary number of extensions.

Yes, SOAP is extensible.  I can always define an entirely new module to 
hold my special-purpose endpoints.  If this is the approach, fine 
(actually, not fine IMHO, actually pretty lame, but so be it).  In that 
case, let's at least make this clear in our description of MAPs:  
They're hardwired toward async request/reply and you're completely on 
your own if you want to do more or different.

Jonathan Marsh wrote:

>[The comments below are not aimed at Anish specifically, but his
>rebuttal to DaveO does provide a nice format for looking at the costs
>and benefits of the proposal.]
>
>  
>
>>-----Original Message-----
>>From: public-ws-addressing-request@w3.org [mailto:public-ws-
>>addressing-request@w3.org] On Behalf Of Anish Karmarkar
>>Sent: Thursday, March 17, 2005 4:17 PM
>>To: David Orchard
>>Cc: David Hull; public-ws-addressing@w3.org
>>Subject: Re: MAPs and SOAP
>>
>>
>>David Orchard wrote:
>>    
>>
>>>Anish,
>>>
>>>You keep on making what I considered unfounded and unproven claims.
>>>
>>>      
>>>
>>David Hull has made a very good case for this at [1], [2] and [3].
>>
>>    
>>
>>>You say
>>>
>>>      
>>>
>>>>Applying the same design principles to [reply
>>>>to] and [fault to] as they are applied to [relationship] would make
>>>>WS-Addressing very useful in the implementation of additional
>>>>        
>>>>
>>>patterns.
>>>
>>>Yet you have not proven why an <endpoint type="replyTo"/> is somehow
>>>more useful than <ReplyTo/>
>>>
>>>      
>>>
>>See [4].
>><endpoint> is extensible wrt to its "kind" and <ReplyTo> is not.
>>    
>>
>
>Your statement above is literally true but I fail to see how it is
>relevant, as <ReplyTo> is one of a set of extensible SOAP headers.  I
>still fail to see any benefit of <endpoint type="anotherReply"> over
><AnotherReply> other than the aesthetic desire to enforce a conceptual
>equality between all MEPs by downplaying the most common message types
>"reply" and "fault".
>
>  
>
>>The exact syntax (as quoted above) is not important. What is important
>>is that there be a property (like [endpoint]) which can support/enable
>>all kinds of MEPs not just req-response. WSDL 2.0 allows different
>>MEPs.
>>    
>>
>
>You have not shown that a single property with some values that might
>not be understood, is better than several properties some of whose
>values might not be understood.  Again the upside seems to be purely
>aesthetic.
>
>  
>
>>Independent of WSDL I can create interesting SOAP MEPs. For example,
>>WSDL 2.0 allows you to have an operation with one "in" and three "out"
>>messages. Providing an extensible (similar to the extensibility of
>>[relationship] property) WS-A property allows me to express all the
>>three "out" endpoint references in the "in" message. 
>>    
>>
>
>Yes it does.  However, I fail to see how you can do any more with these
>properties than you could with extension properties, which are similarly
>powerful.
>
>  
>
>>Another example
>>is:
>>a notification producer wants to send messages to its subscribers with
>>the source EPR, subscription manager EPR, EPR to access the archive of
>>subscription messages and EPR for reporting abuses included in the
>>message as its Addressing properties. With extensibility builtin
>>[relationship] and [endpoint] (or whatever the property is called), to
>>implement the above scenario all I have to do is specify the URI/IRIs
>>for all the different kinds of URIs and relationships between
>>messages.
>>    
>>
>
>So, if I send your processor <endpoint type="something"> you will
>somehow know what that MEP means?  More than you would know if you
>encountered the <Something> header?  At least the latter has a
>processing model which includes mU capability and associated
>well-defined faults.  The implication that you can support MEP
>extensions for free seems too good to be true, and in fact I don't see
>how it can be true.
>
>  
>
>>>This totally feels like change for the sake of making change, and
>>>further makes a very common case more difficult.
>>>
>>>      
>>>
>>I just don't see how this makes the common case difficult? No more or
>>no
>>less than the fact that having to include the URI
>>"http://www.w3.org/@@@@/@@/addressing/reply" in the [relationship]
>>property makes the common case difficult.
>>    
>>
>
>For the simple case, I believe we're comparing:
>  <wsa:associatedEndpoint
>     type="http://www.w3.org/@@@@/@@/addressing/reply">
>to
>  <wsa:ReplyTo>
>.  Is that not correct?  The latter sure looks simpler to me (more later
>on whether reusing that URI even makes sense).
>
>  
>
>>>The multitude of emails that do not identify a single problem with
>>>      
>>>
>>the
>>    
>>
>>>current design lead me to think that any issue should be closed with
>>>      
>>>
>>no
>>    
>>
>>>change.
>>>
>>>      
>>>
>>The only concern against this, that I have seen is at [5].
>>    
>>
>
>Personally, I find [5] compelling, (a lesson learned from XLink's
>failures) but recognize it's largely an aesthetic call.
>
>  
>
>>I find that
>>position inconsistent, as it says that it is OK for [relationship]
>>property to be extensible but not for [Endpoint] (or whatever it is
>>called).
>>    
>>
>
>You haven't showed where that "inconsistency" creates a problem.
>Hobgoblins and all that.
>
>Balanced against what I see as a void of concrete benefits that would
>accrue by adopting the proposal, I see some very real concrete costs:
>
>1: Schedule slip, both in our LC deliverable, and in later stages when
>existing implementations are upgraded to the new version.
>
>2: Stability.  Churn in a spec without good reason risks unintended
>side-effects.  If it ain't broke, don't fix it.
>
>3: Different conceptual model.  While I suspect you and other proponents
>might see a change in the conceptual model as the biggest benefit of
>this proposal, existing users will find this conceptual model
>unfamiliar.
>
>4: Simplicity.  I believe the lack of defined fallback behavior for
>un-recognized endpoint types will require us to invent new machinery
>such as a WS-A specific mustUnderstand.  Such machinery already exists
>for SOAP headers, allowing ReplyTo and FaultTo to be reused in both
>compatible and incompatible ways with new MEPs and their associated
>MAPs.
>
>5: More simplicity.  The predefined reply URI for relationship doesn't
>seem to be exactly the same as the meaning of [reply to].  I don't think
>we'd be able to reuse this URI as the proposal suggests, suggesting at
>the least that more work would need to be done if we decide to go in
>this direction.
>
>6: Even more simplicity.  The addition of URI-based extensibility does
>not prevent other kinds of extensibility (just as WSDL f&p doesn't
>preclude extension elements).  Indeed, since we're primarily leveraging
>SOAP's extensibility model, you can't prevent people from adding new
>headers and their associated properties.  If we have two models
>available, it complicates life for users, spec writers, implementers,
>and of course standards representatives.
>
>7: Flexibility.  Often when extensibility is engineered in a specific
>way it does not accommodate scenarios not considered at the time of
>design.  For instance, if you require something the WSDL f&p composition
>model can't provide, you simply can't use f&p extensibility.  Reusing
>the most general extensibility mechanism (that already deployed in SOAP)
>gives us the best assurance we haven't closed the door on something
>useful.
>
>8: Brevity.  The current syntax is shorter for the most common cases,
>including all of the WSDL 2.0 MEPs.
>
>  
>
>>To me the benefits of making this change are quite large, the change
>>itself is very small (wrt to time it would take to include this in the
>>spec) and I have not been convinced that there is any drawback to
>>this.
>>It is just better design. But, as always, I'm willing to be convinced
>>otherwise.
>>    
>>
>
>Perhaps the points above will help change your mind.  But at this point
>in our development I think it's up to the proponents of the proposal to
>show beyond reasonable doubt that the current approach is broken to some
>extent, and that the new approach solves the problem.  So far the only
>evidence I've seen leads me to the opposite conclusion.
>
>  
>
>>-Anish
>>--
>>
>>[1]
>>http://lists.w3.org/Archives/Public/public-ws-
>>addressing/2005Mar/0100.html
>>[2]
>>http://lists.w3.org/Archives/Public/public-ws-
>>addressing/2005Mar/0109.html
>>[3]
>>http://lists.w3.org/Archives/Public/public-ws-
>>addressing/2005Mar/0140.html
>>[4]
>>http://lists.w3.org/Archives/Public/public-ws-
>>addressing/2005Mar/0150.html
>>[5]
>>http://lists.w3.org/Archives/Public/public-ws-
>>addressing/2005Mar/0160.html
>>
>>    
>>
>
>
>  
>