This is part of the Patterns of Enterprise Deployment series.
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.
- Simple, quick to do
- maintains old interface, callers don’t need to update
- 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
- 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
- When you have already used it once.
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!