Section 13.3. Configuration Management

13.3. Configuration Management

Configuration management in an SOA project requires an approach that is somewhat different from usual practice. Traditionally, each project creates a single repository in configuration management systems such as CVS, Rational Clear Case, or Telelogic's Continuus. Such an approach is not practical in an SOA for the following reasons:

• Services often do not belong to a single project.

• Service infrastructure is used across all participants of the SOA.

• The SOA should enable the independent deployment of individual services.

• The access to the source code of individual services must be controlled independently.

We discuss these issues in great detail in the next section along with some proposed solutions.

13.3.1. CHALLENGES FOR AN SOA CONFIGURATION MANAGEMENT

In an SOA, not all artifacts generated by a project will ultimately be owned by this project. Instead, the services that are intended to be reused in other projects will be owned by the organization. This is necessary due to the mode of reuse that one strives for with SOA.

Traditionally, reuse has been achieved by either reusing source code or sharing libraries between different applications. This will lead either to transfer of ownership of the copied code fragments to the new project or to tying the project to a certain version of a library that has been used. SOA, on the other hand, focuses on the reuse of software components at runtime, effectively reusing existing business systems including the life data they own. This creates a set of dependencies completely different from those of the reuse of code or libraries. Reuse of existing services will raise the need to amend these services or to fix errors within these services that are only discovered in subsequent reuse. At the same time, a project can be expected to come up with some services that will in turn be made available to the entire enterprise (see Figure 13-11).

Figure 13-11. An SOA leverages a scenario in which multiple projects typically share common services.

Much the same holds true for certain support code that is written for a number of specific services, regardless of the eventual ownership of these services. Examples include logging components (see Chapter 9) and transaction handling (see Chapter 8).

It seems beneficial to be able to maintain, build, release, and deploy all shared servicesand to some extent the supporting codeindependently from each other. Otherwise, the agility that the SOA approach enables might be undermined by the requirements of the release and deployment process.

There is no apparent reason why independent services that are created during any particular project should only be deployable and maintainable together. In fact it seems largely beneficial to separate them as much as possible. Consider a service that provides customer-related information within an airline corporation. This service might have been created originally to support booking services during a booking project. As a typical cross-corporate service, it can be reused by other projects. All requested amendments apply to the customer service but not the booking application and its booking services. Ownership of the customer service itself might at some point actually move into another project, for example one that supports a customer retention program. Here, the customer service will be developed and deployed totally detached from its originthe booking application.

13.3.2. RECOMMENDATIONS FOR THE SOA INTEGRATION TEAM

Although the creation of an appropriate structure for configuration management (CM) is a difficult problem, it is actually a benefit of an SOA in that it highlights the parts of a project that should be grouped together in their own CM containers. Traditional projects tend to squeeze everything into one container in order to cut corners when defining the build and deployment process. It is only after several iterations into the project deliveryor the application lifecyclethat the problems of this approach become painfully obvious. Interdependencies of project artifacts all too often mean that a fix cannot be delivered in time or that changes to a library send ripplesor even shockwavesthrough the application fabrics.

When viewing an application from the viewpoint of an SOA, the division into different CM projects happens rather naturally from the bottom up. To start with, all basic services should be put into their own CM container. There might actually be some intermediary services that are closely related to one basic service, and they should be put into the same CM container. As long as other intermediary and process-centric services are designed for reuse, they should be stored separately. Where appropriate, the application frontend and related project-specific services can be grouped togetheroften by the specific functionality they offer or by the customer base they target.

After such a separation is made, common libraries will usually emerge that are reused by more than one service. These libraries themselves are, of course, prime candidates to be grouped in several independent CM containers.

In the end, any project will consist of one or more "frontend" CM containers and will use multiple CM containers that provide services of variable complexity and libraries. Ultimately, the best and most obvious driver for finding the right CM container layout and granularity is to start with a CM container for each reusable service and work upwards.

Create a Standalone Project in Configuration Management for Every Reusable Service

Creation of standalone projects (or subprojects) enables individual services to be developed, maintained, and deployed in an independent fashion. This enables truly agile development. Services can be maintained and upgraded without cross-dependencies to an overall multi-project schedule.

At first glance, it might seem that this implies a need for an enterprise-wide CM management system to properly manage all these different containers. Given that most organizations run multiple versions of different CM systems at the same time, this would seem quite scary. In fact, however, quite the opposite is true. A CM container exists to separate a certain code and configuration set from another one, and there is no compelling reason why these sets should be maintained within the same product (see Figure 13-12). Of course, any organization can only support a limited number of CM systems, and the systems will differ in their capability to integrate with automated build tools of various vendors. This can actually be a good thing, as certain CM environments might be better suited for creating Java-based Unix service development, while others are better suited to support C++-based Windows services or COBOL-based Mainframe development.

Figure 13-12. In practice, different CM systems are involved in one SOA. The service repository plays a key role by abstracting from the actual technologies.

Throwing away an existing CM infrastructure is usually not an option. It is far better to identify a number of suitable CM systems based on the ones that are already available in the organization, but at most one to match each target platform that is available. Also, you should gradually retire CM environments that differ conceptually from the rest in a significant way. If part of an existing code base is not present in one of the target CM systems, you then could migrate it to these systems in the course of service enablement or during subsequent projects. This will eventually enable you to retire all legacy CM systems.

Obviously, runtime reuseas it is leveraged by SOArequires a dedicated version of management. Although you can go to great lengths to ensure that services are maintained in a backward-compatible way, this is not always strictly possible. Sometimes, there might be changes to a system that requires new operation signatures, or a service operation might need to be removed. Because each actual software project is likely to consist of various independent services, along with project-specific and enterprise-wide support libraries, tight tracking of the dependencies of individual software artifacts is required. This includes information about which application frontends or service versions are compatible with other service's versions and the dependency on versions of libraries and runtime environments (see Figure 13-13).

Figure 13-13. Dependencies exist between the various SOA artifactsapplication frontends and services.

This is different from traditional monolithic software versions, where each version in configuration management was created as a single entity, with clearly defined dependency. An example is a traditional software project that depends on, say, a specific version of a byte manipulation library, whereas the multiple services in their respective current versions might very well use different versions of the same library.

At first, you might think that the SOA creates a new problem that requires the creation of such an interoperability matrix. Quite the opposite is true. The creation of a service environment forces important decisions or makes them at least explicit:

• A documentation of dependencies between runtime components is required

• This documentation belongs to a central and easily accessible place

• The information provided by such a documentation is particularly required for multiproject-management.