14

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

Nick
  • 5,848
  • 4
  • 28
  • 33

5 Answers5

8

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.

Lazarus
  • 41,906
  • 4
  • 43
  • 54
  • @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. – Andrew Theken Feb 12 '14 at 15:02
  • @andrew-hare [Citation Needed] – Andrew Theken Feb 12 '14 at 15:02
5

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.

ZX9
  • 898
  • 2
  • 16
  • 34
4

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

marc_s
  • 732,580
  • 175
  • 1,330
  • 1,459
2

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?

John Saunders
  • 160,644
  • 26
  • 247
  • 397
  • 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 (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' – EbbnFlow Jun 22 '12 at 15:36
1

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?

Michael Meadows
  • 27,796
  • 4
  • 47
  • 63
  • Yeah, that's one of the things I'm worried about. We have both netMsmqBinding and netTcpBinding bindings – Nick Mar 10 '09 at 19:59