Re: MAPs and SOAP

Comments inlined below.

-Anish
--

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

It is more than aesthetics. The relevant question that needs to be asked 
is should MAPs enable various MEPs or just req-res (or a subset that 
requires reply-to and fault-to)? If the answer is -- just req-res -- 
then the current spec is sufficient. If the answer is -- various MEPs -- 
then it isn't. My opinion is that the answer should be -- various MEPs.
This is quite independent of whether the SOAP header extensibility is 
sufficient or not.

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

The issue is that MAPs are not extensible. One cannot add the several 
properties that you mention. MAPs is a fixed set of properties.

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

Which properties are you suggesting we extend? I suspect you mean MAPs. 
If so, see the previous comment.

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

I wasn't suggesting that. Apologies if I gave that impression.
Regardless of how the headers look like, if the endpoint does not 
understand the MEP it is not going to work. It isn't that various MEPs 
will be supported for free, but there is a framework in place to support 
new MEPs.

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

The inconsistency does not create a problem per se. All (or almost all) 
the arguments that you are making (and I'm making) apply to not only 
[reply-to] and [fault-to] but also to [relationship] property. What I 
find inconsistent is the position that it is ok (and advantageous) for 
[relationship] to be extensible but not for [endpoint] (or whatever the 
property is called) to be extensible.

(I'm beginning to suspect that perhaps I'm not getting your point)

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

I do agree that this requires change to existing implementations but 
because of some of the changes we have made this is inevitable (part of 
the standardization process). But I don't quite see the other points 
that you mention. For example, why is there a need to have a WS-A 
specific MU? We already have a Invalid Message Addressing Property 
fault. It also seems to me that you are viewing this as a SOAP centric 
issue (I could be wrong), but I'm viewing this as independent of SOAP 
(which is what the Core spec is).

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

I thought David Hull did a good job on this.
I guess it all depends on what you mean by broken. The question that I'm 
asking myself is does the Core provide enough capabilities to enable 
interesting MEPs beyond req-res and the answer is no.

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

Received on Monday, 21 March 2005 18:49:25 UTC