354 Smart SOA Solutions with WebSphere Enterprise Service Bus Registry Edition V7.5
10.1 Service versioning concepts
Managing versions of services is a key challenge in SOA. As a company’s
business processes change in response to new competitive challenges and
business opportunities, so also services in an SOA will need to change to
support the new processes.
One of the benefits of an SOA approach is that as it defines business functions
as easily reusable services at a level of abstraction that separates the business
function from the IT resources used to provide the function, the IT constraints on
making changes to the business are reduced. This makes it easier to respond to
changing business requirements by combining the existing services in new ways.
It is easier to implement new products and processes, change existing ones, or
recombine them to deliver new value, without requiring major changes to the
However, inevitably the detailed functional and non-functional requirements for a
business function will also change over time to meet the changing business
requirements, and new versions of the service that implements a business
function will be required.
To be successful in SOA it is essential to govern changes in versions effectively
to minimize impact on continuous operations, to maximize reuse, and to meet the
evolving business goals.
For example, the impact of introducing a new version needs to be understood.
Does an existing version need to be kept in operation for a set period of time to
ensure existing consumers have time to migrate to the new version, or can the
change to the new version happen instantly?
Changes to a service may apply to a service specification, the actual code
implementing the service, or any other meta-data related to a service, for
example, a service level agreement (SLA) between a service consumer and
provider. Because all of these components can change independently they can
be versioned independently, even though they may belong to the same service
In the sections that follow we describe the key service versioning concepts to
follow when managing service versions with WESB Registry Edition.
10.1.1 Service versions
A service is defined by a combination of its service interface specification and its
implementation. A service can change due to a change in the service
Chapter 10. Service versioning 355
specification, a change in the service implementation, or changes in both.
Service versions include the following types of changes:
A change is
forward compatible if the new version of the service can be
deployed to coexist with the previous service versions, allowing consumers to
continue consuming the existing versions using old SLAs. A deployment
environment (for example, production) can have multiple forward-compatible
versions of a service running simultaneously.
A change is
backward compatible if the new version is compatible with the
previous versions in case the previous version is deprecated. The consumer
of the previous version can consume the new version without any changes in
the consumer request.
Changes to a service interface that are backward compatible might include
the following examples:
– Adding a new operation (with no change in message type). If the
consumer is unaware of the new operation, the old consumer request
continues to work.
– Adding a new optional XML schema type that is not contained within the
Changes to service implementation that are backward compatible might
include the following examples:
– Adding another QoS binding, for example JMS to HTTP
– Updating the implementation code (software) to improve performance; that
is, for better QoS
A change is
non-backward compatible if the existing consumer capability
version can no longer consume the new service version. A new consumer
request needs to be generated to conform to the new service interface or
Changes that are non-backward compatible might include the following types
– Removing an operation
– Renaming an operation
– Changing structure of complex data type
Not all changes constitute a new service version. For example, a change in
service bindings might not constitute a new service version. In some cases, a
consumer version can use dynamic bindings. Thus, it continues to work
uninterrupted by a binding change. For our discussion, we treat this type of
change as a new service version because it often requires a change in the
implementation of the provider service version and putting the change through
deployment life cycle states.