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

Windows Docker Containers can make WIN32 API calls, use COM and ASP.NET WebForms

After the last post , I received two interesting questions related to Docker and Windows. People were interested if we do Win32 API calls from a Docker container and if there is support for COM. WIN32 Support To test calls to WIN32 API, let’s try to populate SYSTEM_INFO class. [StructLayout(LayoutKind.Sequential)] public struct SYSTEM_INFO { public uint dwOemId; public uint dwPageSize; public uint lpMinimumApplicationAddress; public uint lpMaximumApplicationAddress; public uint dwActiveProcessorMask; public uint dwNumberOfProcessors; public uint dwProcessorType; public uint dwAllocationGranularity; public uint dwProcessorLevel; public uint dwProcessorRevision; } ... [DllImport("kernel32")] static extern void GetSystemInfo(ref SYSTEM_INFO pSI); ... SYSTEM_INFO pSI = new SYSTEM_INFO(

Azure AD and AWS Cognito side-by-side

In the last few weeks, I was involved in multiple opportunities on Microsoft Azure and Amazon, where we had to analyse AWS Cognito, Azure AD and other solutions that are available on the market. I decided to consolidate in one post all features and differences that I identified for both of them that we should need to take into account. Take into account that Azure AD is an identity and access management services well integrated with Microsoft stack. In comparison, AWS Cognito is just a user sign-up, sign-in and access control and nothing more. The focus is not on the main features, is more on small things that can make a difference when you want to decide where we want to store and manage our users.  This information might be useful in the future when we need to decide where we want to keep and manage our users.  Feature Azure AD (B2C, B2C) AWS Cognito Access token lifetime Default 1h – the value is configurable 1h – cannot be modified

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.51 EF 6.0.2 VS2013 It see