Versioning of SOA services
At my current project, we deliver a lot of services in the Oracle Service bus. When a service goes into production, how do you maintain those services ? What do you do when new business requirements needs to be implemented on the service, or what do you do when you need to fix a bug ?
I think when this questions arise, you need to think about versioning of your services. Last week I had a talk with a colleague about naming conventions on services, his opinion is that services have a version number in the name of the service.
So, what are the situations when a services needs to be changed ? In fact there are at least the next 2 situations :
1 – Things you didn’t know at design time, so when the service goes into production, somethings needs to be changed in production.
2 – Business requirements, the services is changed functional, what to do in this situation ?
In situation 1 the service needs to be fixed, so it’s ready to go through the OTAP, but what about situation2 ? In sitation2 the service in production will still be used by different consumers. When the service is changed in behaviour or interface, the current consumers can not use the new service. You can not expect from the consumers that they will change their system so it can use the new service.
For situation 2, version numbering of the service is essential. For instance, in production you will have CustomerService_V1.0, a business change of this service will result in a CustomerService_V1.1.
You can think of a situation that a bug fix will also result in a business change of interface change of the service. In that case a new version number is nescessary. Keep in mind that you need to inform the owners of the consumer systems about the fact a service will be changed.
If you enjoyed this post, please consider to leave a comment or subscribe to the feed and get future articles delivered to your feed reader.
