The Service Life Cycle

The service life cycle is a very important topic when you start considering the governance of all the services developed across the enterprise and SOA landscape. One of the dilemmas is to define on how long a service should be maintained and given support and when should it should be deprecated and retired.

The services can be grouped as a portfolio of services available in an enterprise. Any service defined or designed in the enterprise will need to be published to the portfolio of services.

•        Before you define a service make sure that the service doesn’t exist.

•        Define stage - To define a service, identify the purpose of the service, appropriate name and design the service  

•        Development stage - Once the service design is approved it moves to the development stage

•        Release stage – Once the development /testing is completed the service is released/published to the consumer

•        Upgrade stage - As the time passes, initial release may not be enough to cater to all the consumer requirements, so will need an upgrade to the service. When the upgrade is published, the older service becomes deprecated. A deprecated service will be in production and available for consumers use for a pre-defined time frame, before they need to upgrade to the new service.  

•        Retirement stage - A retired service is no longer available to consumers and is removed from the enterprise.

Life cycle of the service can be tracked as metadata in a service registry or as part of the header information in the SOAP message. For example service in the released stage should provide the date of its release and deprecated service should record the planned date of its retirement. To maintain the lifecycle we can always leverage capabilities of Enterprise service Repositories and Registries.

Upgrade options

1.       Service URL will have the version number so that it will be clean and easy for deprecating the previous versions and can track the number of cycles of evolution. The consumers will need to change the service url when they have to migrate to new version.

2.       The other mechanism is to add a user header with version mentioned in it, and the Router will need to decode the version and route it to the appropriate service implementation. No change in URL for consuming the new service, but the version number in header only gets modified.

I somehow like the first option because it’s easy for maintaining the services and deprecating them. Anyway to use newer version means the consumer is getting additional functionalities for which anyway they need to make changes. So the URL change can be clubbed in with that, for a consumer it’s not mandatory to upgrade to new service, but the constant change in today’s environment is change ,so you always need to change and move on to new things. Migration can always be planned and worked out as enough time would be given to consumers to upgrade their system to move on to new service.