Using interface inheritance to address problems in system software evolution

Abstract

Two specific problems faced in large distributed systems are (1) evolving and managing different versions of an interface while minimizing the impact on existing clients, and (2) supporting the addition of auxiliary interfaces that are orthogonal to the main interface of an abstraction.In the context of the Spring distributed system, we addressed both problems using an object-oriented interface definition language. Different versions of an interface are represented as different types with an inheritance relationship that minimizes the impact on existing clients and allows easy management of versions.We distinguish between fundamental and auxiliary properties each of which are defined as separate types. Rather than use simple root inheritance, we use a combination of root and leaf inheritance. This provides flexibility in supporting auxiliary properties and allows us to add new auxiliary properties as the system evolves without forcing the system to be recompiled.The solutions have been tested and refined through their use in the Spring system.

Component evolution and versioning state of the art

“…One workaround for this problem has been demonstrated by Hamilton and Radia in the Spring Experimental Distributed System [6]. They created new interface versions by derivation and added version numbers to the interface names.…”

“…Doing so, it is possible to run different versions of one web-service to support applications that require older versions of the service. Due to the strong-typing of web-services, it is, for example, not possible to change a parameter-type of a service without invalidating existing 6 ISO/IEC 14750:1999 clients. Automatic techniques to announce those kinds of changes are missing.…”

“…Just like any other piece of software too, software components are hardly perfect, when they are created [6]. Problems and bugs have to be fixed and new features need to be added [7].…”