Follow-ups to today's call: 1 (where do you look?)

A major problem we're trying to solve with all this machinery is to
enable a processor to know what to do with a message.  Should it send
the message and wait for a reply on the wire?  If so, should it also
wait for an application-level reply elsewhere?  Should it allow messages
with various MAPs set to anonymous?

In the SOAP/WSDL/WSA world as I understand it, the answers to these and
many other questions can be found in:

    * The WSDL MEP for the operation in question
    * The SOAP binding in use
    * The values of the various MAPs, particularly the response endpoints.

In particular, the SOAP binding tells you whether or not to wait for a
response on the wire, and that together with the WSDL MEP and (in the
general case) the MAPs and the form of any response on the wire tells
you whether to wait elsewhere for a further message.

The difference between the "weakly typed" and "strongly typed"
approaches bears on just /how/ you look at the SOAP binding to figure
out what's going on.  In the "strongly typed" approach, the binding is
basically a bundle of features and properties, which should tell you
what you need to know.  In this case, which SOAP MEPs the binding
supports will tell you whether you want to wait for a wire response. 
Request-response means you do, fire and forget means you don't.  I've
also proposed adding further features and properties to answer questions
like "is there an explicit return address?"

The "weakly typed" approach, as I understand it, relies instead on the
underlying protocol.  If you're implementing the weakly-typed
request-optional-response MEP, you know what your underlying protocol
can do, and you know whether to wait for a response on the wire. 
Presumably the driver can signal to the next level up either "I waited
for a response and got ..." or "there will be no response."

Personally, I'm still pretty sure I prefer "strongly typed," but I
wanted to make the point that one important lens to see all this through
is "where do I look to find out what steps to take".

Received on Wednesday, 8 February 2006 22:18:23 UTC