RE: MAPs and SOAP

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

Received on Friday, 18 March 2005 22:18:11 UTC