Re: Strongly agin the "strongly typed" meps

David Orchard wrote:

> Strongly typed meps are like putting the cart before the horse. 
> Looking at the message to figure out the mep to figure out what the
> receiver should do is harder than looking at the message to figure out
> what the receiver should do. 
>
>  
>
> A longer version is at
>
> http://www.pacificspirit.com/blog/2006/02/13/message_exchange_patterns_and_flavours_of_oneway_messaging
>
>  
>
> Cheers,
>
> Dave
>
I believe the main argument here is that working with "strongly typed"
MEPs is more complicated than working with "weakly typed" (BTW, as a
language geek I'm not completely happy with those designations, but
that's what we're using so I'll go with it).

In order to assess this, we need to dive a bit into the steps one has to
go through with each approach.  With due respect, it's not enough simply
to object to having to "peek into each binding", which in any case I
take to mean "determining what properties the binding in use has," or in
other words simply "using the binding".

Unfortunately, to do this properly, we have to consider (sender point of
view, receiver point of view)x(in-only, robust in-only,
in-out)x(protocols that look like HTTP, protocols that look like UDP,
maybe other protocols), for a total of 18 possibilities.  Further, the
robust in-only and in-out cases split three ways depending on whether
all, some or no response endpoints are anonymous.  This makes the
analysis a pain in the butt.  Ideally, a solution will be able to handle
the cases uniformly enough that you don't have to deal with all the
various subcases separately, but we still have to look at all those
cases before we can say which approach is simpler.

I believe there is a more or less "standard" model that has evolved over
time.  I'll state it here without reference to "strongly typed" or
"weakly typed" approaches:

    * in-only MEP
          o Sender's view
                + If the underlying protocol looks like UDP, just send
                  the message
                + If the underlying protocol looks like HTTP, send the
                  message and wait for a (possibly empty) response. 
                  There has been ongoing discussion about cases where
                  the response is non-empty, perhaps a WSRX ack.
          o Receiver's view
                + If the underlying protocol looks like UDP, you just
                  got a message.
                + If the underlying protocol looks like HTTP, send back
                  an empty response per the protocol binding.  Again,
                  there is ongoing discussion about the possibility of
                  sending something else back.
    * in-out MEP
          o Sender's view
                + If the underlying protocol looks like UDP
                      # Response endpoints must not be anonymous
                      # Make sure you're listening on the response
                        address(es) given, and then send the request.
                + If the underlying protocol looks like HTTP
                      # If all response endpoints are anonymous, send
                        the request and get the response from the protocol.
                      # If no response endpoints are anonymous, make
                        sure you're listening on the response
                        address(es) given, and then send the request and
                        wait for a response as with in-only.
                      # If neither of the above, make sure you're
                        listening on non-anonymous the response address,
                        send the request and get the protocol-level
                        response.  If it's a response sent to the
                        anonymous address (or a failure, including some
                        SOAP faults such as mU), you can stop listening
                        on the non-anonymous address.  If not, expect a
                        response on the non-anonymous address.
          o Receiver's view
                + If the underlying protocol looks like UDP
                      # You got a request.  Send the response to the
                        appropriate address.
                + If the underlying protocol looks like HTTP
                      # Figure out what kind of response you have.
                      # If the endpoint for that response is anonymous,
                        send the response back as the protocol response.
                      # If not, send back an empty protocol response
                        (with the usual disclaimers as above) and send
                        the application response to that endpoint,
                        following the rules for the sender of an
                        in-only, as above.
    * robust in-only.  I'm going to handwave that this is a morph of the
      above two cases.

I believe this captures our understanding so far.  If you buy that, the
question is, how do we determine the conditions of all those "ifs".

    * In both "strongly typed" and "weakly typed", we figure out the
      WSDL MEP (in-only, robust in-only, in-out) from the WSDL.  No
      surprise.
    * In both cases, we figure out which endpoints are anonymous by
      looking at the message, either as we build it (sender) or as we
      unpack it (receiver).
    * In both cases, the protocol binding tells us how to send and
      receive messages.
    * In the "strongly typed" view, you find out "If the underlying
      protocol looks like UDP" by looking at the features and properties
      of the binding.  Currently we propose to do this by keying off of
      "supports f-a-f MEP" or "supports r-o-r MEP", though I'm seriously
      considering slicing this down into properties more like "return
      address", "anonymous allowed".
    * I'm not yet quite sure how one does this in the weakly typed view.

I honestly don't believe the "strongly typed" approach is complex at
all.  Look at the binding and see what properties are there.  Both the
sender and receiver know which binding they're using beforehand.

I can't comment on the complexity of the "weakly typed" approach because
I'm not yet sure how one answers the "what does the binding look like"
question in that approach.