Comment lines: Greg Flurry: Service versioning in SOA

Using service-oriented architectures as a way of enabling flexible and resilient enterprises is becoming widespread. Success with initial SOA deployments now lets architects and developers focus on things that are common to all business and IT systems. One such constant in any system is change. This article discusses the challenge of change in SOA and describes a model that helps address the challenge. This content is part of the IBM WebSphere Developer Technical Journal.

Share:

Greg Flurry, Senior Technical Staff Member, IBM Software Group, Information Management

Author photoGreg Flurry is a Distinguished Engineer in IBM's Business Process and Service Optimization group. His responsibilities include working with clients on service oriented solutions and advancing IBM's service oriented product portfolio.


developerWorks Professional author
        level

08 October 2008

Also available in Chinese Japanese

Handling change

Service Oriented Architecture (SOA) is successfully addressing the need for business flexibility and resiliency in many different enterprises. But like any system, even SOAs inevitably have to address change when it occurs due to business or technical reasons. In fact, since SOA promotes business agility, and agility implies change, you could suggest that SOA even encourages change. But even in SOA change can be painful. Since SOA promotes resilience, and resilience implies an ability to adapt to change, you could suggest that SOA must then deal with change in a graceful manner.

There are changes at many levels of granularity in systems. Since SOA is about services, the most natural focus for examining change in SOA is services. When something changes, we often think of the result as a new version of the thing that changed. As a result, this article will discuss service versioning in the context of SOA.

In SOA, a service consumer interacts with a service provider to accomplish some business task. Change in SOA impacts services. Many service consumers can (and in an ideal SOA, do) use one service provider. Thus, it is reasonable to expect the perspectives and expectations of the consumer and the provider to be different with respect to service versioning. For example, the provider would typically be motivated to minimize change, but, of course, would respond reasonably rapidly to requests for change from consumers and the need for change from within. On the other hand, the consumer will typically desire no changes, or perhaps isolation from changes, or perhaps very slow change.

The different perspectives on change in SOA give rise to the challenge of service versioning, to:

  • Facilitate the delivery of change by the provider.
  • Minimize disruption to consumers due to change.

Let’s look at a model that introduces concepts you can use to analyze this challenge, and approaches you can take to address the challenge.


Service specification

Because of its business and technical relevance to both service provider and service consumer, the lynchpin of the service versioning model is the service specification. Shown in Figure 1, the service specification is a set of concise, external functional and non-functional characteristics enacted by a service. The service specification defines only external characteristics to maintain separation of concerns between the service consumer and service provider.

Figure 1. Service specification
Figure 1. Service specification

At a business level, the service consumer and service provider use the service specification to understand what functional behavior is achieved by engaging in a service interaction. At a technical level, the service consumer and service provider use the service specification to understand how a service consumer instance interacts with a service provider instance. Thus the service specification describes the “what” and the “how” of a service interaction.

Figure 1 shows that the service specification is a versioned entity in the model. As such, it has an identifier, abbreviated as “Nx.y” in the figure. The identifier is unique to one service specification in a domain. The identifier is a tuple of the form {name, version}. The name reflects the relevant large-grained functional and non-functional external characteristics of the service and distinguishes different services, but not different versions of a service; for example: {“CreditScore”, ?} versus {“Customer”, ?}. The version distinguishes different versions of a service; for example, {“CreditScore, 1.2} versus {“CreditScore”, 1.3}.

The service specification version logically has the form of a number <major.minor> and is based on backward compatibility adapted from OSGI. The version starts at <1.0> for the initial service specification. Backward compatible changes cause the <minor> number to increment. Backward incompatible changes cause the <major> number to increment and the <minor> number to reset to 0.

Versioning change in the service specification

Change in the service specification can be evolutionary or revolutionary. Evolutionary changes show a clear heritage to prior service specifications. Revolutionary changes do not. Evolutionary change results in essentially the same, albeit evolved, business value, and is thus a new version of a service. This leads to a view of the service as a continuum of evolved service specifications over the lifetime of the service, from its inception to its retirement, as shown in Figure 2.

Figure 2. Evolutionary change
Figure 2. Evolutionary change

Revolutionary changes result in a new service, as shown in Figure 3. The provider must determine whether a change is evolutionary or revolutionary based on its impact to consumers and consequences to the provider. The “old” service lifetime can continue or end, depending on the needs of the enterprise. Evolutionary change that results in new versions are in the focus of this discussion.

Figure 3. Revolutionary change
Figure 3. Revolutionary change

Details of the service specification

Figure 4 shows additional detail about the service specification.

Figure 4. Details of service specification
Figure 4. Details of service specification

The service specification consists of four major pieces:

  • The behavior specification (BS) describes the business semantics of the service in particular its operations, mostly in terms of the business data required by and produced by the operations.
  • The interface specification (IfS) describes the business syntax of the operations of a service strictly in terms of the abstract data types used by the operations.
  • The interaction specification (IaS) describes the non-business or infrastructural policies, protocols, mechanisms, and constraints that must be satisfied in order for a consumer to interact with the service.
  • The operation specification (OS) describes the non-business-functional traits, such as performance or capacity that a service should exhibit but that are not required for a consumer to interact with the service.

The IaS and OS can be considered defining the qualities of service for the operations.

The service specification is treated as a monolith; the individual pieces are not themselves versioned entities. Further, any characteristic not included in the service specification cannot be considered a source of change.


Service description

The service specification defines the “what” and the “how” for a service interaction, but it is not enough on its own to truly enable an interaction. In particular, there is no information that indicates the location of a particular instance of a service provider. The entity called the service description (Figure 5) contains all the information needed to interact with an instance of a version of a service. The service description is made up of (by inclusion or reference) the service specification to define relevant external functional and non-functional characteristics (the “what” and ‘how”), and a service instance address (the “where”).

Figure 5. Service description
Figure 5. Service description

The service description itself has a unique identifier of the same form as a service specification. In fact, the service description identifier reflects the service specification identifier, but the version adds a <micro> to the service specification version to account for “maintenance changes.” The <micro> increments when internal changes are made that can affect the tacit behavior relevant to a particular version of a service specification. Examples include different configuration files or rules, and even bug fixes in the implementation or assembly for the service instance. A service description can include various forms of tags to distinguish one service instance from others enacting the same service specification.

The service description is typically published (as metadata) in a Service Registry. In general, the associated service specification is published (as metadata) as well.


Service version

The previous section suggests that many service instances can implement the same version of a service specification. This motivates another entity in the model called the service version, shown in Figure 6.

Figure 6. Service version
Figure 6. Service version

The service version aggregates all service instances that implement the same version of a service specification for a service. The service version comprises (by inclusion or reference) one version of a service specification and one or more service descriptions.

The service version itself has a unique identifier that is the same as the service specification identifier. The service version, however, is not itself a versioned entity in the model; it simply represents all instances of a particular service version.

Like the other entities, the service version is typically published (as metadata) in a service registry.


Service

The final entity in the model is the service, shown in Figure 7. A previous section suggested that a service can be considered a continuum of service specifications and implementations of those service specification.

Figure 7. Service
Figure 7. Service

The service aggregates all service versions from inception of the service to most current version, resulting in a continuum of service versions. The service also indirectly aggregates all service instances that implement all versions of a service specification. The service comprises (by inclusion or reference) one or more service versions, each identifying the corresponding service specification and service description.

The service has an identifier that is simply the name of the service, as in the service specification. The service itself is not a versioned entity in the model.

As with the other entities, the service is typically published (as metadata) in a service registry.

Figure 8 shows a summary of the model.

Figure 8. Summary of the model entities
Figure 8. Summary of the model entities

A service consists of a number of service versions. Each service version has its external functional and non-functional characteristics defined in a service specification. Any single service specification can have many service instances that manifest that service specification. Each of the service instances is defined by a service description, and each of these service descriptions is identified by the corresponding service version.


Summary

The model presented here lets you reason about how change in SOA manifests itself through the services, how that change can be represented, how to classify the change, and how to express change so the impact can be understood. This model can be represented in a service registry that could enable implementation of governance processes to control change, notify interested parties about change, and even let mediations running in an ESB help minimize the impact of change.

Resources

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into WebSphere on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=WebSphere, SOA and web services
ArticleID=343789
ArticleTitle=Comment lines: Greg Flurry: Service versioning in SOA
publish-date=10082008