Re: Asynch Scenarios

David Orchard wrote:

> I've posted an update based on Marc H's comments at
>
> http://www.pacificspirit.com/Authoring/async/async-scenarios.html
>
>  
>
> I'll continue to update as soon as I get comments.
>
>  
>
> Cheers,
>
> Dave
>
This is definitely a helpful document.  Some specific comments:

    * Have we agreed on whether the "no message" response is 202
      (accepted), 204 (no content) or something else?  The document
      shows 202.
    * Should the WSDL bindings mention the proposed
      "wsa:UsingAddressing" header?
    * We don't quite capture all the cases that were on the board in
      PA.  In particular
          o Robust in-only, no fault-to shows an example for a fault
            coming back, but not for no fault coming back (which should
            be a 202 or whatever we decide).
          o In-out should have a "fault-to, anonymous reply-to" case (or
            a "reply-to, explicitly anonymous fault" case), and this
            case should show both fault and non-fault behavior.  I
            particularly want to see explicitly that the anonymous
            channel may receive either an actual message (200 or 500) or
            a "no message" marker (202 or whatever).
    * We don't show a wsa:To header anywhere, and it's not clear whether
      the default (anonymous) is appropriate (or not).  Should we show this?
    * Under robust in-only over one-way, there's a segment of
      strangely-formatted text at the end of the section.
    * Which reminds me, the sections themselves should be numbered to
      match the numbering in the table of contents.
    * The "robust in-only FaultTo" (over two-way) section states "Note
      that the previous scenario, a fault on the return path, is allowed
      when a FaultTo is specified. The messages flows in this pattern
      and the previous are valid."  I assume this means that you can
      also get a 500 back, even if faults are directed elsewhere, per
      Tony's timeline.  Is this what it means?  In any case, I found the
      text unclear.
    * Along those lines, we should point out that a two-way transport
      can /always/ return a fault (even in the pure in-only case).
    * And along a related line, I agree with Paul Downey that "two-way"
      is a bit unclear.  Probably "anonymous reply channel available" or
      similar would be better.