Automatic Determination of Compatibility in Evolving Services

Automatic Determination of Compatibility in Evolving Services

Karin Becker, Jim Pruyne, Sharad Singhal, Andre Lopes, Dejan Milojicic
Copyright: © 2011 |Pages: 20
DOI: 10.4018/jwsr.2011010102
(Individual Articles)
No Current Special Offers


A major advantage of Service-Oriented Architectures (SOA) is composition and coordination of loosely coupled services. Because the development lifecycles of services and clients are de-coupled, multiple service versions must be maintained to support older clients. Typically versions are managed within the SOA by updating service descriptions using conventions on version numbers and namespaces. In all cases, the compatibility among services descriptions must be evaluated, which can be hard, error-prone and costly if performed manually, particularly for complex descriptions. In this paper, the authors describe a method to automatically determine when two service descriptions are backward compatible. The authors describe a case study to illustrate version compatibility information in a SOA environment and present initial performance overheads. By automatically exploring compatibility information, a) service developers can assess the impact of proposed changes; b) proper versioning requirements can be put in client implementations guaranteeing that incompatibilities will not occur during run-time; and c) messages exchanged in the SOA can be validated to ensure that only expected messages or compatible ones are exchanged.
Article Preview


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.

Complete Article List

Search this Journal:
Volume 21: 1 Issue (2024): Forthcoming, Available for Pre-Order
Volume 20: 1 Issue (2023)
Volume 19: 4 Issues (2022): 1 Released, 3 Forthcoming
Volume 18: 4 Issues (2021)
Volume 17: 4 Issues (2020)
Volume 16: 4 Issues (2019)
Volume 15: 4 Issues (2018)
Volume 14: 4 Issues (2017)
Volume 13: 4 Issues (2016)
Volume 12: 4 Issues (2015)
Volume 11: 4 Issues (2014)
Volume 10: 4 Issues (2013)
Volume 9: 4 Issues (2012)
Volume 8: 4 Issues (2011)
Volume 7: 4 Issues (2010)
Volume 6: 4 Issues (2009)
Volume 5: 4 Issues (2008)
Volume 4: 4 Issues (2007)
Volume 3: 4 Issues (2006)
Volume 2: 4 Issues (2005)
Volume 1: 4 Issues (2004)
View Complete Journal Contents Listing