Oh my gosh, who's going to write all those bindings?

The example I put out a while ago [1] seems to require 4 or 5 separate
bindings of the one-way MEP in order to work.  I'd like to comment on
that here.

First, no bindings at all are required to implement the pattern.  In
order to know that you've implemented the one-way MEP correctly, you
just have to answer the same questions a binding writer would.  My
position is that there are three such questions:

   1. Who are the receivers?
   2. What is the message path to each receiver?
   3. Is the message at each receiver the same message that was sent?

The bindings I outlined provide a rigorous way of answering those
questions and, more importantly, they should be re-usable in answering
the same questions in any number of similar situations.

Second, we are of course not on the hook to write any of these bindings,
at least not as part of this activity.  We just write the MEP that lays
out what questions the binding writer needs to answer.  As to the
bindings themselves:

    * We sincerely hope that people will feel moved to write transport
      bindings.
    * Bindings like the security binding would make nice additions to
      the standards they make use of.  For example, there's a WS-RX
      binding just waiting to be written.  WS-RX's four box picture
      looks uncannily like a sender, a receiver and two intermediaries.
    * The fan-out binding seems like a useful building block, but I
      don't know who would write it.
    * The no-op binding is a technical device that's probably not even
      needed, since it's just a way of saying "this hop is optional".

The important part is that we describe what the one-way MEP looks like
so that the barrier to binding to it is as low as possible.

Finally, if the one-way MEP itself is a note, then clearly bindings
would be too, and writing a binding just means documenting "I was able
to do SOAP one-way this way" for the benefit of the community at large.

[1] http://lists.w3.org/Archives/Public/xml-dist-app/2006Nov/0000.html

Received on Thursday, 16 November 2006 16:36:38 UTC