Article Preview
TopIntroduction
A major advantage claimed for service-oriented architectures (SOA) is the ease for making changes, because they support composition and coordination of autonomous, sharable services in a loosely coupled manner. SOA enables independent development by disparate teams, each one with its own delivery and maintenance schedule (Frank, 2008). The decoupled life-cycles of services and clients have major consequences from a change management perspective. As a service is upgraded, it must continue to support existing clients while meeting requirements of new ones. This requires the ability to represent and manage multiple versions of the same service within the SOA, and transparently enable redirection of old clients to new versions of the service when possible. Ideally, compatible changes should not cause failures or unexpected behavior. Hence, research is required in how changes are introduced in services within the SOA (Andrikopoulous et al., 2008; Endrie et al., 2006; Fang et al., 2007a; Frank et al., 2007; Kaminsky et al., 2006). Finally, because every service can be used in multiple solutions, any change in the behavior of a service can cascade across clients (and clients of those clients) in a transitive manner, causing a broad impact within the SOA. Thus the SOA must support early detection of incompatible changes.
This paper addresses backward compatibility, which is concerned with how changes to the service interface affect existing clients (Andrikopoulous et al., 2008; Brown & Michael, 2004; Endrie et al., 2006; Fang et al., 2007b; Kaminsky et al., 2006; Narayan & Singh, 2007). In this paper, we shall use compatibility as synonymous with backward compatibility. A service version is defined to be backward compatible with a previous one if it a) delivers at least the same functionality; b) possibly relaxes constraints on the input expected while delivering the same results; and c) generates outputs that can be consumed by existing clients.
There is no comprehensive solution for managing compatibility of evolving services in SOA. Existing work can be divided into: a) best practices and design patterns for service versioning (e.g. Andrikopoulous et al., 2008; Brown & Michael, 2004; Endrie et al., 2006; Lubinsky, 2007; Narayan & Singh, 2007), b) version aware registry solutions (e.g. UDDI v3.0.2, Systinet, Fang et al., 2007b), which make assumptions about service compatibility, and c) architectural components for dealing with service compatibility within the SOA (e.g. Fang et al., 2007a; Frank et al., 2007; Kaminsky et al., 2006). In all cases, it is assumed that compatibility among versions is assessed manually, a particularly error-prone task for complex service descriptions.