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:
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:
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.
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.
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
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
Post a Comment