Patterns of Enterprise Deployment: Versioned Contract

This is part of the Patterns of Enterprise Deployment series.

Summary

A contract is my word for anything that forms an agreement between two systems. It could be formed by database schema, message format or API.

You have a new version of a system that uses the same technologies as before but in the new version there are changes of usage or naming that makes the old version and the new version incompatible and confusing to compare. In order that you don’t have to do a BigBang deployment, your system continues to support both contracts. The new system maybe distinguished by a new name, version number, address, port number, GUID etc. Under these contracts, you may or may not decide to have one code base supporting all the requests. Ideally, there would be a single source for the data if the same data is accessible  via both contracts.

Many systems for doing remote invocation support VersionedContract as part of their architecture; e.g., DCOM, RMI, CORBA, .Net Remoting, .NET WCF.

Difficulty

Low

Advantages

  • Simple, quick to do
  • maintains old interface, callers don’t need to update

Disadvantages

  • leads to cluttered system interfaces
  • sometimes it just isn’t possible to clean out the old callers; that leaves you with version 2 and 3 as well
  • support burden can be onerous as the “old way” holds you back

Use when

  • You have a small new feature to implement and you can re-use the old contract as the implementation
  • it’s time to make a clean break with an old contract that is being stretched too thin
  • you just don’t know who calls your system or when

Don’t use

  • When you have already used it once.

My experiences

The classic instances of this, for me, come from the windows API. The one that stands out in my mind is the DCOM call CoCreateEx. The windows AP is full of this sort of thing because they fall under the “you don’t know who is calling you” advice. That is the one thing that MicroSoft do better than anyone else: backwards compatibility. They can support so many flavours of OS and the same damn code keeps on working. But you also see the burden of all those changes!

Advertisements

2 thoughts on “Patterns of Enterprise Deployment: Versioned Contract”

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s