This project is read-only.

Outgoing message does not match that of the encoder

Topics: Usage Scenarios, Technical Questions
Feb 4, 2009 at 8:51 PM
I am trying to install the MSE on two servers where one will act as the Messenger and the other as the Broker/Dispatcher.  When I seperated the MSE between two servers and made a call to the facade endpoint I kept getting this error:

<?xml version="1.0" encoding="utf-16"?>
<s:Envelope xmlns:s="">
    <s:Fault xmlns:s="">
      <faultcode xmlns:a=">a:MSE Runtime Message Processing Exception</faultcode>
      <faultstring xml:lang="en-US">The message version of the outgoing essage (Soap12 ( Addressing10 ( does not match that of the encoder (Soap12 ( AddressingNone ( Make sure the binding is configured with the same version as the message.</faultstring>

The MSE was installed on two Windows Server 2003 x64 Edition Service Pack 2 servers.  Within the configuration of the MSE I am using the Bindings that were imported from the Basic Calculator service for my facade endpoint.  I originally installed it on one of these servers and set it up to be both Messenger and Broker and with the same configuration it was working.  It wasn't until I seperated them that I had this error.  I understand that this is a WCF error but I was wondering if within my configuration for the seperated servers I am missing some change that needs to take place in order to work.  Any ideas on how to remedy this?

- Corey
Feb 4, 2009 at 9:00 PM
It's great you are exploring separating the Messenger and Broker.  The first thing to check is to make sure the binding used for the Broker endpoint is WsHttp (Soap12).  This matches the internal normalized message format we use in the MSE.

Feb 4, 2009 at 9:17 PM
Awesome!!!  I had the Broker set to BasicHttp (Soap12) and sure enough when I set it to WsHttp (Soap12) it worked.  Thanks for your help...
Feb 4, 2009 at 9:24 PM
I should also clarify that NetTcp is a good binding to use for the Broker as well.  This binding uses the same Soap12 Addression10 message format we use as the normalized message format and would be more efficient.
Feb 4, 2009 at 9:36 PM
That is a very good point.  I think that is probably the route I will take.  Thanks again...