“OneWay” Operation style mismatch

When working with service you sometimes may get following error

“The server did not provide a meaningful reply; this might be caused by a contract mismatch, a premature session shutdown or an internal server error.”

The good thing is that this error does not come very often, as long you tooling works fine. However in some advanced interop scenarios you will have build your proxies, contracts etc with different tools or manually. When working this way, the error above can happen more often than you like. In this post I will show one short and advanced case, which briefly describe why happen behind the stage in Service Model.

Assume there is a provider which implements service based on this contract:

It is obvious that that the service will listen on oneway messages in the operation HelloWorld. Usually, one would create a proxy for this servic eby using of Visuals Studio “Add Service Reference” functionality and the svcprosvcutil would create semantically the same interface on the client side.

But imagine now, that for some reason the service has to have IsOneWay property set to FALSE and the client should have the same property set to TRUE. Onb could ask why this should ever be a requirement in universe?  Well, if the underlying channel is for example some queuing system like MSMQ or MQ this might be very important. For example one WCF channel can support reliable messaging like wsHttpBinding. Such binding internally may require that the the message is never of type one way. This is reasonable, because in oneway scenario message is fired and forgotten. That means no reliability and robust messaging is possible.

Internally WCF will never call back the channel to perform some action after the message has been delivered to operation, if the message is one way. For more information about this take a look here.

Assume there is client which do not have a requirement to perform reliable messaging, but there is a service which requires reliable messaging. How this can work? It can, it is in big enterprises a possible scenario. For example client can fire some messages and forgot them, but the service is responsible to process all messages which arrived without of loosing of any. It is just about a service level agreement.

In this case operation style OneWay can be different at the client and service. And exactly this scenario causes the error described above.

Here is why and how?

Assume there is a client which has following interface:

The only difference is mismatch in operation style. If the client is set to OneWay=FALSE and Service to OneWay=TRUE, the message above will appear. This is exactly the problem. The client sends message and expects the response, which will never come back. Depending on what kind of binding is used, for example HTTP, the HTTP listener on the service side will always send response message which would be (because OneWay=true at service side) is HTTP message without of SOAP envelope. This message would cause the client to throw the exception shown above.