Service Contract Changes
Once again, all service contracts should follow the best practice of using both the
Name and
Namespace parameters on the
ServiceContract attribute. An updated version of the Person service contract might look like this:
[ServiceContract(Name="PersonService", Namespace="http://services.mycompany.com/2009/05/25"]
public interface IPersonService
As with the data contract, using the
Name isolated the service consumer from the actual interface name, allowing the internal implementation to change as needed. The addition of the
Namespace allows you to version the contract at some point in the future. Remember that new versions also require new endpoints.
You can add operations to service contracts without breaking existing consumers. Consumers will simply ignore the new operations. Removing operations, on the other hand, will break existing consumers. As with all breaking changes, the removal of an operation requires a new version along with a new endpoint.
Operation Contract Changes
As with the service and data contracts, you should use the
Name parameter with the
OperationContract attribute:
[OperationContract(Name="GetPerson"]
Person GetPerson(int personId);
The consumer is, once again, isolated from changes in the internal implementation.
Finally, the last change to consider is in the signature of an operation contract. This is a breaking change for which you have two solutions: create a new version or add a new operation to the service contract.
Honor Your Commitments
Change is inevitable, but with a little planning and a few key principles, you can minimize the impact changes have on your WCF services. Always remember that when you release a service, you make a commitment to the service consumers to honor the contract. Making changes to an existing contract is bad form.
To that end, keep some best practices in mind:
- Always use the Name and Namespace parameters on all contracts.
- Always use the Order parameter on data members.
- Implement the IExtensibleDataObject on all data contracts.
- Use namespaces for contract versioning.
- Always remember that new versions require new endpoints.
- When using strict schema validation, do not change contracts. Create new versions.
- When removing an operation from a service contract, create a new version.
- When changing the signature of an operation, create a new version.
With these practices in mind, you can make change just a little easier to dealing with for yourself and your service consumers.
Previous Page
