Introduction
This post basically explains how to version the WCF.
Background
Generally when a service is deployed in the production environment, there can be barely any changes that can be done on the service which also means that their service endpoints or contracts - in general all the WSDl documents should not be changed. However if there should be a change, then the backward compatibility should be considered such that the change does not affect the existing clients.
How can we change an existing service without affecting the existing clients?
WCF Versioning
WCF Versioning is nothing but a set of guidelines that will help both the client and the service providers to be in sync. These guidelines also help the client systems from breaking.
Now let's us see in brief what are those protocols used in WCF Versioning.
WCF Versioning Protocols in a brief
Basically there are two version terminologies
- Strict Versioning
- Lax Versioning or Agiler versioning
In scenarios where the change may affect the existing consumers, we go for strict versioning. Versioning the formal contract and endpoint due to change done to the service contract, data contract, message contract or any other contract-related or endpoint. Which also means that at a said time, there will be 2 versions for the same service available and will be consumed by 2 different types of clients.
Lax Versioning
In scenarios where the developers presume that introducing a new optional parameter will not break the functionality for their clients, we go for lax versioning. This approach relies hugely on backward compatibility. There will not be any change in the versioning part as long as compatibility is not broken. In other words, this approach avoids formal contract and endpoint versioning until compatibility is broken.
WCF Versioning Sample
Consider an example where there are clients consuming a service; the service is meant to do an operation - Calculate
, which takes in two parameters. So when the clients says Calculate(2,3)
, the response will be an addition of 2
and 3
= 5
.
Due to advancement in technology, the management decides to change the underlying logic of calculate; such that calculate will henceforth do Addition
, Subtraction
, Multiply
and Division
based on the parameter the client is providing, which implies that Calculate
will take 3 parameters going forward.
If the management has to decide on what kind of versioning to use, let us also put a thought on the same:
If we follow strict versioning, then the solution will look something like below:
If we follow lax or agile versioning, then the solution will look something like below:
Solution for the Above Problem
The Service provider now wants to upgrade his logic. There are two ways to accomplish it, either we introduce new contracts as Add
, Sub
, Mul
, Div
or add a new data member which will be an optional parameter.
Imagine that we are the service provider and would like to maintain 1 whole function as the name depicts “Calculate
” which will do all the 4 operations- and we very well know that the logic for add
already sits in there. So that being the case, we would very well put a select clause and the default will be Add
thereby making the Calculate
method take the parameter as Calculate(Val1,Val2,Optional Operation)
.
In WCF, while defining the DataContract
and the members - there is a possibility to state if the member is required or not.
[DataMember(IsRequired=false)]
public string Operation;
Through this, any DataMember
can be made required or not required for any service consumption. This means that the client who consumes calculate
service will always get a summed up value but the other new clients who wish to send in their operation parameter will get their response based on the operation
value.
Conclusion
This is how WCF versioning protocol helps us to build robust services for our clients.
Strict Versioning