Does adding a method to a WCF ServiceContract break existing clients?

Question

We have an existing ServiceContract

[ServiceContract(Namespace = "http://somesite.com/ConversationService")]
public interface IConversationService
{
        [OperationContract(IsOneWay = true)]
        void ProcessMessage(Message message);

        [OperationContract(IsOneWay = true)]
        void ProcessMessageResult(MessageResult result);
}

and we need to add a method to it

[ServiceContract(Namespace = "http://somesite.com/ConversationService")]
public interface IConversationService
{
        [OperationContract(IsOneWay = true)]
        void ProcessMessage(Message message);

        [OperationContract(IsOneWay = true)]
        void ProcessMessageResult(MessageResult result);

        [OperationContract(IsOneWay = true)]
        void ProcessBlastMessage(BlastMessage blastMessage);
}

Will this break any existing wcf clients that are using this service? Or will we have to update all existing wcf clients?

EDIT: This service is using both netTcpBinding and netMsmqBinding

Remora

You should edit the question to reflect that you're concerned with net.tcp and net.msmq protocol bindings. – Bamford

Answer 1

I think your existing clients will continue to work. After all this is very similar to SOAP and web services in that the client will connect to the given URL and request a specific service. If you take methods away you will risk breakage (only if the method is used I believe) but adding should be pain free.

I've only dabbled in WCF but have used the ASP.NET web services in this way to great success.

Alexio

@lazarus, I would agree with you, except that every experience I've ever had with modifying WCF services results in breakage (adding new operation contracts, adding optional parameters). ASP.NET web services behave quite differently, and seem to be less restrictive. – Deanndeanna

@andrew-hare [Citation Needed] – Deanndeanna

Answer 2

I just tested this with a WCF client Windows app (UWP) and it continued to work after updating the WCF service application. So no: as previously answered, your clients will not break when you add a method.

I thought it was worth mentioning, however, how easy it is to update your service clients with Visual Studio 2015:

1. Make sure your WFC service is running.

2. Simply go to the Solution Explorer,

3. Expand Service References

4. Right-click on your service reference

5. Click Update Service Reference

6. If you get an error message, repeat the last step. I had to try a few times for some reason.

Troche

Answer 3

No, I wouldn't expect that - adding new functionality / new service methods that does NOT alter any of the existing methods / function calls will not affect "old" clients. Of course, they won't know about the new methods until their proxies have been recreated from metadata, or adapted manually.

But existing calls should be unaffected, as long as their signature (the data they exchange) stays the same.

Marc

Cockerel

Answer 4

I take the more extreme view on this. Why ever change anything? Instead, why not create a new contract, inheriting from the old, and adding the new operation? The new contract can be exposed in a separate endpoint in the same service.

It may be paranoia uninformed by formal proof, but it seems to me that, if it's possible to construct a client that can tell the difference, then it's possible that some client will "break" when you make the change. Consider that, when you change the service contract you're not just changing service code - you're changing the proxy code in any client that happens to update his service reference. Some, more conservative customers, might consider that a reason to re-test their client code - after all, they may well have rules that say they have to retest their code whenever any change is made to it.

The existing client will be referring to the original endpoint, so will not be affected by adding a new endpoint - no code would change if an "Update Service Reference" was performed.

Besides, why even think about it, if you don't have to?

Reciprocity

Wouldn't inheriting from the old cause a new service config node to be created and a new entry in the .svc file? I thought that the <service name=""> (name value) had to be the Namespace.ClassName of the implementing class of the contract, which in this case would be the derived class not the base class. Therefore is seems that putting the derived contract in the same service would not work. If I'm wrong, can you provide an example of this? My error is: The contract name 'Namespace.IDerivedInterface' could not be found in the list of contracts implemented by the service 'Namespace.BaseClass' – Litigate

Answer 5

In general, adding to a message in SOA solutions does not break the contract. I believe that as long as you're not using a binary protocol (net.tcp), you'll maintain backward compatibility.

I'm not sure about whether or not it will break your clients using binary bindings, though?

Bamford

Yeah, that's one of the things I'm worried about. We have both netMsmqBinding and netTcpBinding bindings – Remora