Top 10 SOA Pitfalls: #9 - Versioning

Last week we started the Top 10 SOA Pitfalls countdown with #10: NIH syndrome. This week it's time for #9.

Version mismatch is one of the growing pains of a SOA. A SOA starts simple, but after a while new versions of services will appear and the complexity will grow. Good life cycle management and supporting tools will help you to control the complexity.

The implementation of a SOA will contain services. Initially the services are designed for a purpose. Consumers of these services will use the functionality as designed. However, over time the services might change or new functionality is needed. What effect will this have on the consumers, services and infrastructure?

Let’s take a closer look on these changes. The changes can be divided in major changes (v1.0 to v2.0 ) and minor changes (1.0 to 1.1). The following types of change can be identified (combinations of the types can occur):

1. Minor change of interface: The current interface is extended without compromising the current functionality and interface usage. For instance adding a new method with new functionality.
2. Minor change of functionality: The functionality is changed without effecting any consumers. The implementation is revised. For instance a bug fix of the current version.
3. Major change of interface: The current interface is changed is such a way that it is not backwards compatible. For instance the methods are changed or the functionality is completely new.
4. Major change of functionality: Although in this change the interface remains the same, the functionality is changed in such a way that it will affect the consumers.

In general the minor changes won’t effect the current consumers. These consumers can continue to use the existing interface or functionality. Normally the service can be replaced with the new version without keeping the old version online. Howver regression testing is desired in order to make sure that the new functionality/interface hasn’t affected the existing functionality/interface. Note that the new functionality should fit into the current SLA.

In a major change the changes will most likely effect the current consumers. The old version can’t be replaced by the new version for a couple of reasons.

• The current consumers are not able to upgrade to the new version in time
• The old functionality is still required, although it is not functional supported (only technically).
• The consumers do not want to upgrade and/or are not willing to pay for the extra costs. These costs will raise in time in most cases.

In these cases two versions of the same service will be available for the consumers, although the functionality and interface differ. When multiple versions of a service exists, the complexity of the SOA increases. Although some companies will restrict the amount of versions in production it is often hard to maintain the versions. Often the functional support will only apply on the new version, but technically all versions should be supported. Maintenance is needed for both versions which could result in a minor new version for the old major version.

Versioning problems are in most cases caused by poor governance and lack of supporting tools. Practically the common problems with versions are:

• Who is using the versions? Who used the old interface? How long ago did they use it?
• Missing supporting tools to help manage the different versions.
• How long is support needed for an old version. When is it save to upgrade or remove a version.
• Are the consumers redirected to the right version?
• Consumers are directly connecting to the services without a proxy.

In order to keep track of all these services a good registry is needed. The registry contains services that are active. The registry contains the location and the consumers that use the services.
Tools like an ESB can act like a proxy to different versions. The exact location of a version is hidden from the consumers. The ESB routes the call to the correct version of the service.

Note that generic public internet services are hard to version. In these cases the consumers are unknown and can’t be contacted. Although the same principles apply, the only way they can be notified is in an anonymous way (for instance a notification on a website).

In conclusion versions of services will change overtime. Therefore it is important to be prepared for these changes. Limit the amount of versions and keep track of who is using them in a registry. Use tools to hide the implementation from the consumers so you can be more flexible with multiple versions.

Next week, Viktor Grgic will move on to pitfall #8.