Life Cycle Management

(For more resources related to this topic, see here.)

Service stages

A service goes through several stages; it has a life cycle. The following figure shows the various stages of this life cycle:

Apart from identifying, designing, and implementing a service, you also need to take into account the possibility of cleaning up services. Services can become obsolete, because they don't conform to the requirements anymore, because there are better alternatives or because nobody is using them anymore. The stages deprecated and retired are used for this. The following table explains the different life cycle stages of a service and who is involved in reaching that stage.





The service is identified; the organization is aware that it is needed. The approach to identification can be either top-down, bottom-up, or meet in the middle.

Architect: Top-down (and meeting the middle) identification of service is based on the process or user interface requirements.

Developer: Bottom-up identification is based on the existing capabilities.


The service interface (operations) and contract are known and documented. A developer can create a mockup of the service based on the design by tooling, and clients can be built based on the design.

Architect: Top-down design of services based on the process or user interface requirements.

Developer: Bottom-up (and meet in the middle) design based on existing capabilities.


The service is available for consumers to use in production systems.

Project, or the service is bought from a supplier.

Administrator: Deploy the service and makes it available.


The service is a candidate for replacement or is obsolete. Current consumers can keep using the service for now; new consumers should use a replacement or find other alternatives.

Service provider: Decides to move to this state.


The service is no longer available for consumers.

Service provider decides and the administrator undeploys the service.

There are no approval states in this life cycle. Within your organization you need to decide who is responsible for what type of actions and who needs to approve those. For example, you could decide that since you have already created a business case for the realization of the SOA, you don't need to approve identified services explicitly. If something is identified and later you decide you don't need it after all, you can either delete it, or retire it straight away. Another approach is to approve the services in the step define the solution in detail, as part of the approval of the project architecture.

Keep details out of the life cycle

Beware of adding too many details of the software development and release management in the life cycle of the services. It becomes tedious and outdated very quickly. The only message it needs to convey to the service consumers is, can these services still be used?

Versioning of services

During the life cycle of a service, the service changes because consumers have change requests, laws and regulations change, and errors need to be fixed. First, you learn about versioning of services, and then the relationship with the different stages of a service is investigated. A common way of keeping track of these changes is using version control. Version control is the management of changes to documents, software, and artifacts. Changes are identified by a number or letter code; a version or revision number. Now when do you give your document, data model, or service a new version number? And what type of versioning scheme are you going to apply? Usually, you make a distinction between minor and major versions of a change. A service consists of an interface, a contract, and an implementation. All these aspects of a service can change. Let's look into the different types of change and how this affects the version of your services.

Type of change – contract, interface, and implementation

Let's take the example of a diner that offers breakfast. The menu lists all their services. The contract of the service states the quality, price, availability, order time, and so on. The interface is the way we interact with a service. When ordering breakfast we interact with Jane, our waitress, and the menu that is in English and Spanish. The implementation of the service is the cooking of the service, and the serving and eating of it.

Changing the contract

The contract of the service states:

  • Ingredients are all local and natural

  • Breakfast might contain gluten

  • Breakfast can be ordered from 7 a.m. to 1 p.m.

  • Breakfast costs $9.95

  • Payment by credit card or cash is accepted

  • Currency that is accepted is in dollars

  • Time between ordering breakfast and the delivery time to the table is 5 minutes to 10 minutes

  • Complaints should be delivered to the manager by telephone

Prices of the ingredients increase every year, so after the first year the breakfast place is in business, the cost of the breakfast is increased. This is a major change in the contract, so the owner creates a new menu with the new prices, effectively creating a new version of the service.

The waitress informs the regulars (customers that visit the diner every week) about the increase in advance. Other customers find out when they visit the breakfast place.

After having been in business for a couple of years, the owner of the breakfast place notices that a lot of tourists from Europe and Asia visit his breakfast place. They are suffering from jet lag and have different breakfast requirements. They would rather have something light and pay less for the breakfast. The manager decides to change something in the contract: not all breakfasts cost the same anymore; it depends on what you order. Now this is good news for customers who want to eat less: they don't have to pay for something they did not order. However, existing customers who were used to the "all inclusive" breakfast concept and eat more won't appreciate the change.

Obviously, the owner also has other options, not just changing the service for everyone at once:

  • Change the contract for everyone, everybody pays a la carte

  • Add the "light" breakfast option to the menu as an additional menu for a fixed lower price of $4.95

  • Offer an a la carte option next to the all-inclusive breakfast

After some research, he decides to use the last option, in effect leaving the old contract intact by adding an a la carte option to it.

Note that in both examples nothing has changed about the interface, you still order what you want to eat for breakfast, and the implementation has not changed either. The same cook is preparing the breakfast, the same ingredients and kitchen utensils are used, the same cooking method is applied, and so on. The change was in the contract of the service. The first change (increase in price) affected all the customers in the same way. The second change was more complicated, it was an improvement for some customers but the owner did not want to scare away the other group. Obviously, the owner does not use version numbers in his menu, but he did create a new version of the menu. The way this was communicated was not with a version number but with an effective date and an announcement to the customers.

Changing the interface

Apart from the contract, the interface can also change. As you have read before, a lot of customers are from Europe and Asia. For these people, it is sometimes hard to speak English. So the owner of the diner decides to print the menu in multiple languages: Spanish, French, Japanese, and Chinese. He also hires some waitresses and waiters that speak multiple languages.

This change has no impact on the current customers; English is still supported as a language to order the breakfast in.

After a while, the waitress who speaks French quits her job and the owner decides not to replace her, because only a small number of customers speak French. This change has an impact on the current customers who speak French; they will have to switch to another language that still is supported.

Changing the implementation

After a couple of years, the owner of the diner decides to hire some new kitchen staff and replace some of the kitchen tools. The new people improve some of the processes in the kitchen, thus creating a more efficient operation. The customers notice that a dish is served a little faster than in the past and that fewer meals arrive cold or over-cooked as a result of the improved operation.

Versioning schemes

You want to keep track of changes to a service, using version control. You don't want service consumers to accidently use the wrong version. This can cost money or cause errors to occur. In the case of an IT service, you don't want to break the code of the service consumers. The types of change that can occur in the BreakfastService also apply to IT services; you can change the interface, the implementation, or the contract.

The service as a whole is the unit of interest for the service consumer; therefore you need to version the service as a whole. This means that you change the version of the service if any of the parts of a service change, whether this is the implementation, the interface, and/or the contract. As a consequence, there is no need to version the contract, interface or implementation separately.

Version the service as a whole

Version the service as a whole and you need to version the underlying files. There is no need to version the contract, interface and implementation separately.

The following diagram illustrates this for OrderService. Every time a change is made to a file, this is recorded in the version control system. This has no impact on the version of the service. Once you decide to release the change into production, you determine the new version of the service as a whole.

The diagram shows OrderService with a version 1.0.1. It consists of an implementation, contract, and an interface. These are not versioned separately, because this is of no interest to the consumer. Three Java files make up the implementation. These are versioned in the version control system, because the service provider needs to keep track of the changes they make. The contract consists of two policy files: a security policy and an availability policy. These are versioned in the version control system as well. The interface consists of an XSD and a WSDL. These are versioned in the version control system.

Versioning and life cycle stages

There are several things you can do when the version of a service changes, as you learned with the change of contract of BreakfastService:

  • You can replace the current version with the new version

  • Let the new and current (or old) version co-exist (for a limited time period)

Apart from deciding what to do with the old version, you also have to decide what to do with the version number. This depends on the impact of the change; to determine whether a change is minor or major, you have to look at the impact the change has on its current consumers. For example, adding an operation or a field has little impact on current consumers. If you want to make a major change, it is good practice to create a new major version of the service, and to support consumers who want to keep using the previous (deprecated) service for a certain time period.

The following table shows a common versioning scheme that works well for both consumers and providers:

Change type

Minor version

Major version

Previous version

Major change

To 0

Increase by 1

Keep it (stage is


Minor change

Increase by 1

Stays the same

Replace it (stage stays implemented)

Let's look at an example; suppose your organization offers OrderService and uses the convention [major version].[major version].[minor version]. The current version is 1.0.0. This means the major version is 1.0 and the minor version is .0.

Now if you make a major change, you increase the major version and keep the previous version available to consumers for a little while. This results in two services:

  • OrderService 1.0.0 (stage deprecated with a planned end date)

  • OrderService 1.1.0 (stage implemented)

If the change is minor, you increase the minor version and discard the previous version. This results in one service:

  • OrderService 1.0.1 (stage implemented)

Supporting two versions has advantages for both the consumers and for the providers. Consumers can plan the migration to the new version, and planning the upgrade for the provider is also a little easier because not everybody needs to test the new service at the same time.

Note that you will keep track of all the files that you use during development in your version control system. The version number that is of interest here is the version number that you communicate as a whole to the service consumers when the (new version of the) service is released.

Making the version explicit for service consumers

When you are using a WSDL to describe your interface to your consumers, you can make the version of the service explicit by putting the (major) version number in the namespace and in its endpoint.

A namespace in a WSDL or XSD is used to differentiate between elements, and it enables the document to reference multiple external specifications, including the WSDL specification, the SOAP specification, and the XML Schema specification.

By using the version in the endpoint, it is also easier to support two versions of the same service on your server.

Let's see how this works with a WSDL for OrderService:

<wsdl:definitions name="OrderService-1.0" targetNamespace="" xmlns:tns="" xmlns:xsd="" xmlns:wsdl="http://" xmlns:soap="" xmlns:msg="" <wsdl:documentation> The Order will create an order for multiple orders Version history V1.0.0 Initial service description </wsdl:documentation> <wsdl:types> </wsdl:types> <wsdl:message> … </wsdl:message> <wsdl:portType> .. </wsdl:portType> <wsdl:binding> … </wsdl:binding> <wsld:service name=OrderService-1.0 <wsdl:port name="OrderServicePort" binding="tns:OrderServiceSoapHttpBinding"> <soap:address location=""/> </wsdl:port> </wsdl:service> </wsdl:definitions>

The highlighted parts show the version in the namespace and in the endpoint (soap:address). In this case, the major version is in the namespace (1.0 and the endpoint); the minor version is in the documentation (1.0.0).

With REST services you can make a distinction between versions in a similar way. Basically you have two options:

Multipurpose Internet Mail Extensions (MIME) are used to identify the type of representation that is in the body of an HTTP request or HTTP response. MIME types are sometimes referred to as CONTENT-TYPES. The MIME type has a major type and a subtype, separated by a slash.

The major MIME types are text, video, image, audio, and application. Application can refer to a number of formats: application/xml, application/pdf, application/octet-stream, and so on. For vendor specific commercial use, vnd is used as a prefix, followed by the name of the company and the domain for example, application/vnd.vennster.crm. For personal non-commercial use, prs is often used. For experimental or non-standard types you can use x.

Putting the version in the vendor MIME media type, has the disadvantage that user agents such as browsers, wget, and so on don't understand the MIME type. So you might not be able to display the resource correctly. The advantage of putting the version in the MIME type is that it has less impact on the client code.

To make the version explicit in a service, you can implement an operation getVersion that returns the version of the service (both the major and the minor version). This operation can also be used as a heartbeat operation by monitoring tools.

Versioning tips

Support the current version and the previous version in case of a major change.

Use major and minor versions. Minor versions can be put in the documentation. Major versions can be expressed in the namespace and endpoint in case of WSDL or in URI, or MIME type in case of REST. Implement a getVersion method in your service.

Communicating change

In the previous paragraph, you learned what type of change could occur in a service and what versioning schemes you can apply. These changes have some impact on the customers or service consumers. To make sure that service consumers can adjust to the new version of the service, you have to take the following steps:

  • Determine if the change is major or minor

  • If the change is major:

    • Change the state of the service to deprecated and determine the "end of life" date;

    • Create a new version of the service with the state identified

    • Announce the change to all current clients

    • Design the new version of the service and change the state of the new service to designed

    • Communicate the new design to clients who want to migrate

    • Realize the new version of the service and change the state to implemented

    • When the "end of life" date is reached, remove the old version

  • If the change is minor:

    • Design the new minor version of the service

    • Announce the change to all current clients

    • Realize the new version of the service

  • Communicate the situation to all current clients and prospects that have indicated interest in the service

There are different ways of communicating these changes to your clients: you can announce it in a meeting, you can send emails, or you can update a central registry that describes all the available services.

Changing the namespace and endpoint of the service is a good way of communicating the change at runtime. The client calls a service using the namespace in its code, as you can see in the Java example given as follows:

public class OrderServiceClient{ public static void main(String[] args) throws Exception { URL url = new URL(""); QName qname = new QName("", "OrderService-1.0"); Service service = Service.create(url, qname); OrderService orderService = service.getPort(OrderService.class); System.out.println(orderService.orderProduct("ipod")); } }

Now let's look at tooling support for versioning and life cycle management.


There are two types of tools that help in keeping track of the services that are provided and used in your organization: a registry and a repository. The registry lists the services and its features and has an interface to search for services and to add information about services. A repository holds the actual service artifacts, such as WSDLs, policies, XSDs, and so on. It's like a library, the registry is the catalog that lists all the books and other things you can borrow. You can search it, find information about the books and CDs and add items to it. The repository is the shelves where the books and CDs are stored.

There are two use cases for searching in a registry: runtime discovery of services and design time discovery of services. Runtime discovery of services means that a service consumer looks for a service, based on certain metadata. The registry returns a number of potential candidates. The consumer inspects the web service description and then binds to the service provider of the server that is the best fit.

The following figure shows the conceptual model of runtime discovery as it is used in Universal Description Discovery and Integration (UDDI), a standard for service registries.

Runtime discovery is hardly ever used in environments where SOAP or ebXML are used. The main reason is the overhead that is involved, apart from searching for the right web service, the client needs to generate a service consumer that is compliant with the WSDL of the service. One of the examples that shows how little it is used, is the fact that IBM and Microsoft offered a public UDDI registry that could be used for runtime discovery, but they have since stopped this effort.

Design time searching is a more common use case. Often prospective or current clients are looking for a specific service or for specific information about a service. Think for example about a project that wants to use CustomerService. The project first of all wants to know if the service is implemented already. They need to know the conditions of use and the interface. A registry is a very useful tool in that case. Once they decide to use it in the project, they will have to go to the repository to get access to the artifacts like the WSLD, test suites, and so on.

The biggest difference between runtime and design time service discovery is with design time use of the registry, the binding of the consumer to the provider is done beforehand, during coding of the application; you know what service you are going to call. You have seen this in the previous code sample, the service address and qualified name are known at the time you are building your application. With runtime discovery, the consumer doesn't know in advance what services are available and it is decided at runtime what service to call.


There are several standards for service registries and repositories. The three main standards that are associated with a certain type of service standard are:

  • UDDI: The acronym stands for Universal Description, Discovery and Integration. It is a standard that is maintained by OASIS. It defines a set of services to support the description of web services providers; the web services themselves, and the technical interfaces that are used to access these services. It is mainly associated with environments where SOAP and WSDL are used.

  • ebXML RegRep: This specification is also maintained by OASIS. It defines interoperable registries and repositories with an interface that enables submission, query, and retrieval of contents. It actually consists of two specifications: ebXML Registry Information Model OASIS Standard (ISO 1500-3) and the ebXML Registry Services Specification OASIS Standard (ISO 1500-4). It is based on ebXML, an XML standard that enables an electronic marketplace and is focused around specific business processes.

  • Atom Publishing Protocol: This specification is maintained by IETF. It is an application level protocol for publishing and editing web resources using REST. This means it is based on HTTP and XML. The protocol defines interfaces for retrieving (collections of) resources, discovery and description of collections of resources, editing, deleting, and creating resources.

Registries are widely used within enterprises for design time use; to keep track of the services, the contracts, and the interface. It is very useful in the process of service identification to determine whether the service is already available, but also later when it is implemented to keep track of the state (life cycle stage) of the service.

Often, an ESB is used to hide the location and specific interface of service in the organization instead of a registry, thus making runtime discovery obsolete.

Instead of buying a service registry or service repository, you can also create your own using a Wiki or your company intranet.

Information needed

Not only if you create your own registry, but also when you use a tool you buy on the market and need to configure it, it is important to realize what information about your services you need to record. A registry helps service consumers in:

  • Finding services: Potential clients need to know what services are available, how to use them, and what the conditions of use are.

  • Troubleshooting: Whenever existing consumers experience problems it should be clear who can be contacted to solve the issue.

  • Change process: If you need a change to the service, it should be clear who to contact.

Find services

Find services To help in the design process of potential consumers, the following functionality should be offered by the service registry/repository:

  • Search for artifacts and service descriptions on certain attributes.

  • Create a taxonomy. There are different categories of services. It helps to find a service if this taxonomy is reflected in the registry/repository.

  • Store the service owner. If future consumers have questions or there is a discussion about requirements, it is important to know who has the final say.


To help the troubleshooting process, the registry/repository should contain the following information:

  • Administrator of the service: If something goes wrong, the client needs to know who can be called.

  • Consumers of the service: If a service is down, the administrator needs to know who is going to experience problems so they can be warned in advance (proactively).

  • Version of the service: If something is wrong with the service (for example, a bug) it is important to know what version of the service is used by whom.

Change process

To support the change process the following information is needed:

  • Owner of the service: This is the person who decides what is going to be implemented, when, and how much budget is available.

  • Consumers of the service: They need to be consulted about changes that are planned.

  • Version of the service: That is currently active and by who it is used.

The following table shows some of the information that needs to be stored in a registry. The list is not exhaustive, and you can expand it to suit your needs:






Unique identification of a service.

Functional description


Functional description of the service, including its operations.



Event, process, service, data element (CMD), transformation.


URI or MIME type

See Versioning Schemes given earlier in this article: namespace or MIME type.



Identified, designed, implemented, deprecated, retired.

State Date


Date the state was set.


Service identification

In case of a new version of a service you can point to the previous version here.


Service identification

In case of a new version, you can point to the newer version in this field.

Test suite


References to one or more test suites, preferable tests that can be run automatically.



References to applications, processes, services that consume this service.

Contact data

Reference to owner and administrator

Contact data of the owner and the administrator of the service, for example email address, phone number, and so on.

Security (availability, confidentiality, reliability, and so on)


Reference to policies that apply.



Reference to SLA

Technical artifacts


Reference to WSDL or technical design.

The references mentioned in the previous table are references to the repository or some external source.

Registries and repositories in your IT landscape

You have read about the relationship between ESB and registry/repository briefly in the previous paragraph. But there are more tools in your organization. The following figure shows how the main tools most organizations use to govern their IT assets, both design time and runtime relate to a registry/repository. The numbers represent different tools, the letters represent information types and the arrows show what tools use this information.

Enterprise architecture tools

In architecture modeling tools, there are often multiple models, describing the to-be situation, the current situation, and situations in between. Descriptions of models of the future situations can lead to the identification of new services that need to be developed. Descriptions of the current situation give insight into the dependencies between processes and existing services. Process descriptions in architecture models are mainly used to track organizational goals to processes, describe improvements, and define capabilities in an organization. As is shown by arrow "A", information in the registry about services is used to describe the current situation in the enterprise architecture modeling tool. New services that are identified in the enterprise architecture model are registered in the registry, as well as the processes that (will) consume these services.

Business Process Management tool

A BPM tool, or the older term, "workflow" tool also holds process descriptions just like the enterprise architecture modeling tool. These models are used to actually execute the process. Some of these BPM tools also support a higher level, more abstract way of modeling, in fact creating some overlap between enterprise architecture tools and BPM tools. Sometimes these tools offer synchronization options, for example by exporting the processes from the modeling tool into the BPM tool or vice versa, as is shown by arrow "B". Arrow "A" shows that the same information is shared between a BPM tool and the registry/repository, as between the enterprise architecture modeling tool and the registry/repository. Executable processes can also be published in the registry, as business services.

Architecture tool versus business process management tool

Use the architecture tool of your organization to identify future services and publish these with the state "Identified" in the registry/repository. Use the BPM tooling to describe executable processes. Publish these to the registry/repository as soon as they are designed with the state "Designed". Update them to "Implemented" as soon as they are in production and being used by the organization.

Configuration Management Database

Configuration Management Database (CMDB) is the same as a service registry or repository, with one difference that it contains information about all the components of Information systems in your organization. The term stems from ITIL and helps you to understand the relationship between components and track their configuration.

ITIL stands for Information Technology Infrastructure Library and is a set of practices for IT service management.

In fact, a registry/repository contains only a subset of what CMDB contains, that is the information that is relevant to the service consumers. Logically, the service registry or repository is part of your CMDB, but just for services and focused more on the consumer than the provider. CMDB and registry/repository tooling both offer the same type of functionality, that is options to automatically harvest items from systems, interfaces to add and edit information, and so on. You might wonder if you need a service registry/repository if you already have a CMDB in your organization. If CMDB contains the information that is described earlier in this article and the clients in your organization can easily get to this information, you don't need a registry/repository. But often CMDB is used more for the service providers, so you need to arrange for information specifically targeted at the consumers.

Bug and issue tracker system

This tool is used to keep track of changes, bugs, and issues that arise with functionality that is in use, or is being developed. As you can see in Arrow "C", information about services is used in this tool to determine the correct functionality, impact on consumers, and so on.


An ESB can route service requests from service consumers to the correct service provider. This way, part of the binding of the client to the service is done by the ESB instead of the registry/repository. The address of the service on the service bus is published in the registry so that clients know what to call. These services are public and available for consumers. The services that are called by ESB are stored in the registry/repository as well, but these services are private, and not to be called by any other service consumers. The following image shows that services that are created on the ESB are published to the registry. The description of the services that are called by the service bus is imported by the ESB from the registry. This can often be done automatically from the ESB, depending on the standards and brand/suite you use. Arrow "D" in the previous figure also showsthis relationship.

The following diagram shows the relationship between a registry/repository and Enterprise Service Bus. The public services, or the services that are exposed to service consumers can be published in the registry/repository (either by a pull or by a push mechanism). The description of the services that are called by the enterprise can be imported by the ESB from the registry/repository, if a formal description exists. This would not be the case if the ESB puts a message in a file (file adapter).

Business Activity Monitoring

Business Activity Monitoring (BAM) enables you to monitor business processes and events. It is based on events or alerts that are generated by processes and services. There is no direct relationship between BAM and the registry or repository.

Infrastructure monitoring

Tools that monitor the health of services and servers have no direct relationship with the repository or registry. It is important that services that are published in the registry as "implemented" or "deprecated" are monitored by the monitoring tools and that the contract is used to determine what the desired performance and behavior is.


In this article, you have learned about the life cycle of a service, and what types of changes in a service can lead to a new version of the service. You have seen that you need to communicate and keep track of the services and versions using a registry or repository. This tooling can be purchased or you can create the tools yourself. Finally, the attributes you need to store in the registry and the position of the registry/repository in your organization was discussed.

Resources for Article :

Further resources on this subject:

You've been reading an excerpt of:

SOA Made Simple

Explore Title