MEPs and Up-front Knowledge

Dave Orchard writes about message exchange patterns (MEPs) and one-way-messaging — very interesting, although my guess is that the total number of people who really understand all of his arguments is extraordinarily low. One thing I fundamentally agree with is that anything that turns the availability of a WSDL (or any other description) into a requirement at runtime is a bad idea:

The data needed for a receiver to “know” can be in the message. Therefore trying to say the receiver will “know” ahead of time based upon the MEP is just plain wrong. It leads down bizarre paths like “If the ReplyTo is anonymous then the soap mep is request response else if the replyTo is non-anonymous then the soap mep is f-a-f if the protocol is not http else the mep is request-optional-response if the protocol is http. If the mep is f-a-f then close the connection, etc. “. The whole point of doing things “strongly” or “statically” is that there’s something known up front, but with data driven protocol interactions supported by WS-A et al, this is just plain broken. Instead of the previous, I propose “The mep is request-optional-response. If protocol is HTTP and replyTo is anonymous, wait for response from application. Else don’t wait.”.