The aim of this post is to highlight the importance of having a service registry and a service lifecycle within any organization. There are several working profiles interested to have a response to the following questions:
- What are the available services?
- What is their interface and their behavior?
- What is the service availability and its lifecycle?
The previous questions are really important from a business perspective and also from a technical point of view. So this means that business analysts, architects and designers are interested to have proper responses to the previous questions, in order to provide working solutions; exploiting as much as possible existing functionalities and providing new requirements based on existing services.
It’s really important to set up a service registry from the beginning of the project, even though with a customized solution in order to:
- Do not lose track of what services are available and which are not
- Have a description of what a service does and what functionalities it provides
- Know what interface the service exposes and if there are multiple versions of the same service
- What are the consumers of the service
- What services are consumed by the service itself
- Make a future impact analysis whenever a service is interested by some changes
The next picture shows what should be provided in the service registry solution (e.g. a custom or generic service registry solution).
Service registry requirements
Looking at the role of the service registry, the first thing that pops up is that there are two different groups of users: consumers and providers. Sometimes it also happens that the two groups even belong to different organizations. In order to accomplish the different needs, the service registry has to support an efficient use of the service. To achieve this target it’s useful to have for each service:
- Service one-line description
- Service abstract description
- Service context and interface definition
- Consumers and consuming service’s list
Service one-line description
The one-line description presents as brief summary as possible what is the service intend for use. The final target of the one-line description is to help someone to decide, at the first glance, if it’s worth to spend time learning more about the service.
An example of the one-line description might be “The create port-in request service manages either fixed line or mobile phone numbers”.
Service abstract description
The service abstract description supports a next screening level of potentially interesting services. It should give a brief overview of what the service does, including significant variations. The description itself should assume that the reader has no prior knowledge of the service.
An example of the service abstract description might be “The create port-in request service is taking care of customers that want to move from a provider X (i.e. DONOR) to a provider Y (i.e. RECIPIENT). The request contains either fixed line phone numbers or mobile phone numbers. In case the customer is a business company, it’s possible to have a slot of phone numbers to port-in. At the end of the create port-in request the external consumer of this service will receive a synchronous response (i.e. acknowledge) that specifies the successful delivery of the create request. Later on the external consumer will receive a final notification to confirm the successful completion of the port-in process”.
Service context and interface definition
The service specification is a central document to be shared between the service provider and the service consumer. It represents an agreement between the two parties. From the service provider’s perspective, it is a complete statement of what will be provided and a description of its intended utilization. From the consumer’s perspective, it is a user manual that explains what the service is meant for and how it is intended to be used. To serve these needs, the specification must clearly state the purpose of the service, describe its context and intended usage scenarios and detail its interfaces and observable behavior. To accomplish this, the service specification should include the following information:
- Service one-line and abstract description
- The context in which the service is intend to fit in
- The service’s utilization scenarios
- The interface definition (e.g. protocols and connection methods) with clear description of the fields’ service meaning
- References to external service calls
- Specification if the service is stateful or not and in case of stateful service describe the observable states
- Constraints in the use of the service itself
- Nonfunctional capabilities of the service
- Deployment specifics
Consumers and consuming service’s list
The content of this paragraph is important along the same lines as the service one-line description. With a first glance it should be possible to identify:
- What are the consumers of service X?
- What services does the service X consume?
Replying to the previous two questions it is fundamental for impact analysis and in conjunction with the one-line service description to have a high level overview on the service functionalities itself. An example of those details are represented in the following pictures.
Service lifecycle
Together with the service registry it’s really useful to have in place a tool/software that manages the service lifecycle. Whenever a service is provided a contract is established between the service consumer and the service provider. A service lifecycle tool/software has to take care of:
- Service/Contract versioning
- Service/Contract lifecycle
- Service/Contract deprecation
Providing a service with a version allows the consumer to get a specific interface/contract based on specific requirements. Moreover there is the possibility to extend/change the service behavior providing a new version of the service. In this way the external consumers are not forced to move towards the new service version if it’s not required. This means that the service can have multiple versions running and available at the same time. Obviously this doesn’t mean that the number of service versions running in parallel will be unlimited. Within the organization has to be decided (e.g. with the use of guidelines and/or assertions) how many service’s versions will be handled simultaneously. This implies specific behaviors/rules for the service consumers. In fact when the maximum number of service’s versions has been reached, the oldest service’s version will be deprecated with consequences for the consumers of the service that will be forced to use another service’s version.
From a pure service’s lifecycle point of view there is the need to manage the state changes of a service as it evolves across its lifecycle from design and candidate services, through testing and staging and to deployment and operations.
Conclusions
The service registry, together with a service lifecycle process, is vital for the organization service portfolio. At the beginning it represents an additional investment with a lot of efforts, without seeing the real value add, but when the content of the service portfolio grows and the quantity of consumers/providers increases as well, then the initial investment is really worthwhile. In every organization you cannot know what you really need if you don’t know what you already have.
