Skip to main content

How to NOT do Web Services versioning (WCF)

On the internet, there are a lot of companies that sell information or different functionalities that are exposed like as web-services. This week I had the “opportunity” to update a client application that use remote services from a 3rd part provider.
And now the story begins.
In the last 12 months, there were more than 9 new versions of the service that were roll out by the 3rd part. Not all the clients use the last version of the services of course, because of this they had to support also the old versions of the services.
What was their solution for this? To create for each version a new method exposed in the same endpoint and service. Because of this for an operation like GetDriver we had the following possible calls:
GetDriver(), GetDriver_V2(), GetDriver_V3(), 
GetDriver_V4(),GetDriver_V5(), GetDriver_V6(), 
GetDriver_V7(), GetDriver_V8(),GetDriver_V9()
Imagine that this is happening for a lot of operations that are exposed. Beside this, not all the operations were updated, because of this, a part of operations have 9 versions, and other ones have 3 versions and so on.
GetDistance(), GetDistance_V2(), GetDistance_V3()

GetDriver(), GetDriver_V2(), GetDriver_V3(), 
GetDriver_V4(),GetDriver_V5(), GetDriver_V6(), 
GetDriver_V7(), GetDriver_V8(),GetDriver_V9()

UpdateCar(), UpdateCar_V2(), UpdateCar_V3(), 
UpdateCar_V4(), UpdateCar_V5()
This is not the end of the story yet. Each operation has a response and a request. If we are working with GetDriver_V9 operation we may expect to have GetDriverRequest_V9 and GetDriverResponse_V9. The version of each request and response don’t have the same version as the operation that we use. Because of this we can have operation that would look something like this:
public GetDriverResponse GetDriver(GetDriverRequest request)
public GetDriverResponse GetDriver_V2(GetDriverRequest request)
public GetDriverResponse GetDriver_V3(GetDriverRequest_V2 request)
public GetDriverResponse GetDriver_V4(GetDriverRequest_V2 request)
public GetDriverResponse GetDriver_V5(GetDriverRequest_V3 request)
public GetDriverResponse_V1 GetDriver_V6(GetDriverRequest_V3 request)
public GetDriverResponse_V2 GetDriver_V7(GetDriverRequest_V3 request)
public GetDriverResponse_V1 GetDriver_V8(GetDriverRequest_V4 request)
public GetDriverResponse_V2 GetDriver_V9(GetDriverRequest_V4 request)
Working with a service like this can be a nightmare. I don’t want to imagine what will happen after 12 months, when they will have another 10 new versions.
In this moment the client proxy that is generated with svcutil.exe has almost 2MB and around 90k lines of codes (of course we can remove the unused services and operation). This can be a little funny, when the client application itself had no more than 2k lines of code.
When you need a versioning system, I would recommend thinking twice before starting implementing it. Not all the time, the simple solution is the best solution.
The first mistake was that we have only one service defined - we have operations with different functionalities under the same service. For example the same service offer different functionalities like:
  • Resolve addresses
  • Calculate distance
  • Track trucks
  • Manipulate trucks (CRUD operations)
  • Manipulate drivers (CRUD operations) 
  • Manipulate routes (CRUD operations)
  • Refuel history
  • Generate different reports 
I would expect to group each of operations under different services. We have different functionalities that don’t need to overlap.
When we would have a new version of the service we should offer a different endpoint for it. Another solution is to have under the same endpoint different versions of our service.
ww.myService.com/Services/v1/RoutesService
www.myService.com/Services/v1/RefuelService
www.myService.com/Services/v1/AddressResolverService
www.myService.com/Services/v2/RoutesService
www.myService.com/Services/v3/RoutesService
Also we can imagine different solution for this problem.
Another problem is how we can make obsolete the old versions of ours services.
In time we can have 100 clients that user V7, 8 clients that use V1, V2, V3, V4, V5, V6 and only 4 clients that use version V8 and V9. If we want to scale up with a specific version, than we need to have on all the servers that are behind the load balancer all the versions installed. We cannot have 10 servers with version V7 and 1 server that have the rest of the version.
I’m happy that tomorrow id Friday.

Comments

Popular posts from this blog

How to check in AngularJS if a service was register or not

There are cases when you need to check in a service or a controller was register in AngularJS.
For example a valid use case is when you have the same implementation running on multiple application. In this case, you may want to intercept the HTTP provider and add a custom step there. This step don’t needs to run on all the application, only in the one where the service exist and register.
A solution for this case would be to have a flag in the configuration that specify this. In the core you would have an IF that would check the value of this flag.
Another solution is to check if a specific service was register in AngularJS or not. If the service was register that you would execute your own logic.
To check if a service was register or not in AngularJS container you need to call the ‘has’ method of ‘inhector’. It will return TRUE if the service was register.
if ($injector.has('httpInterceptorService')) { $httpProvider.interceptors.push('httpInterceptorService&#…

ADO.NET provider with invariant name 'System.Data.SqlClient' could not be loaded

Today blog post will be started with the following error when running DB tests on the CI machine:
threw exception: System.InvalidOperationException: The Entity Framework provider type 'System.Data.Entity.SqlServer.SqlProviderServices, EntityFramework.SqlServer' registered in the application config file for the ADO.NET provider with invariant name 'System.Data.SqlClient' could not be loaded. Make sure that the assembly-qualified name is used and that the assembly is available to the running application. See http://go.microsoft.com/fwlink/?LinkId=260882 for more information. at System.Data.Entity.Infrastructure.DependencyResolution.ProviderServicesFactory.GetInstance(String providerTypeName, String providerInvariantName) This error happened only on the Continuous Integration machine. On the devs machines, everything has fine. The classic problem – on my machine it’s working. The CI has the following configuration:

TeamCity.NET 4.51EF 6.0.2VS2013
It seems that there …

Run native .NET application in Docker (.NET Framework 4.6.2)

Scope
The main scope of this post is to see how we can run a legacy application written in .NET Framework in Docker.

Context
First of all, let’s define what is a legacy application in our context. By a legacy application we understand an application that runs .NET Framework 3.5 or higher in a production environment where we don’t have any more the people or documentation that would help us to understand what is happening behind the scene.
In this scenarios, you might want to migrate the current solution from a standard environment to Docker. There are many advantages for such a migration, like:

Continuous DeploymentTestingIsolationSecurity at container levelVersioning ControlEnvironment Standardization
Until now, we didn’t had the possibility to run a .NET application in Docker. With .NET Core, there was support for .NET Core in Docker, but migration from a full .NET framework to .NET Core can be costly and even impossible. Not only because of lack of features, but also because once you…