Demonstrating the obvious

One day in math lecture, while writing a particularly complex proof on 
the board, the professor paused and pondered the last step.  "Can we 
really make that inference?" the professor asked aloud, and after a 
pause answered "Yes ... it's obvious".  A bewildered student asked "But 
how do you get there from the previous step?"  The professor paused for 
even longer, studying the board, muttering and gesturing, and finally, 
with a grunt of satisfaction replied "It's obvious."

...

If we are to say that interaction patterns beyond request/reply can be 
handled by defining further properties, we need to be able to 
demonstrate how that would happen.  Could someone please detail how to 
handle cases other than variants of request/reply?  So far all I have to 
go on is my own fragmentary construction of request/reply/alternate.  I 
had some basic questions about this (e.g., which SOAP module are 
properties to be defined in?), and at this point I have no idea whether 
that was on the right track.

I wouldn't expect anyone to cover all possible use cases, only enough to 
show that other cases could be handled by essentially the same means (of 
course, if it's already obvious, then zero cases are enough for this :-)

Cases to consider would include:

    * Dave Orchard's request/reply/alternate reply example.  An
      alternate reply message would include an "alternate reply"
      relation in [relationship], but the alternate reply endpoint
      itself would be defined outside the MAPs.
    * The initial/normal processing/urgent processing/fault case I
      gave.  From a narrow viewpoint of counting inbound and outbound
      endpoints, this is isomorphic to the previous case, but the
      endpoints here would all be defined outside the MAPs.
    * Request/reply, but the reply message is correlated by reference to
      an external context (or by uniqueness of the reply endpoint), and
      not by message ID,
    * Any of the asynchronous cases mentioned in [1], [2] and not listed
      here.
    * It would also be instructive to show how request/reply would have
      been built on top of the core if the reply and fault endpoints had
      not been built into the MAPs.

[1] http://lists.w3.org/Archives/Public/public-ws-async-tf/2005Mar/0012.html
[2] http://lists.w3.org/Archives/Public/public-ws-async-tf/2005Mar/0016.html