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(...

How to audit an Azure Cosmos DB

In this post, we will talk about how we can audit an Azure Cosmos DB database. Before jumping into the problem let us define the business requirement: As an Administrator I want to be able to audit all changes that were done to specific collection inside my Azure Cosmos DB. The requirement is simple, but can be a little tricky to implement fully. First of all when you are using Azure Cosmos DB or any other storage solution there are 99% odds that you’ll have more than one system that writes data to it. This means that you have or not have control on the systems that are doing any create/update/delete operations. Solution 1: Diagnostic Logs Cosmos DB allows us activate diagnostics logs and stream the output a storage account for achieving to other systems like Event Hub or Log Analytics. This would allow us to have information related to who, when, what, response code and how the access operation to our Cosmos DB was done. Beside this there is a field that specifies what was th...

Cloud Myths: Cloud is Cheaper (Pill 1 of 5 / Cloud Pills)

Cloud Myths: Cloud is Cheaper (Pill 1 of 5 / Cloud Pills) The idea that moving to the cloud reduces the costs is a common misconception. The cloud infrastructure provides flexibility, scalability, and better CAPEX, but it does not guarantee lower costs without proper optimisation and management of the cloud services and infrastructure. Idle and unused resources, overprovisioning, oversize databases, and unnecessary data transfer can increase running costs. The regional pricing mode, multi-cloud complexity, and cost variety add extra complexity to the cost function. Cloud adoption without a cost governance strategy can result in unexpected expenses. Improper usage, combined with a pay-as-you-go model, can result in a nightmare for business stakeholders who cannot track and manage the monthly costs. Cloud-native services such as AI services, managed databases, and analytics platforms are powerful, provide out-of-the-shelve capabilities, and increase business agility and innovation. H...