Reference Hub14
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 |Volume: 8 |Issue: 1 |Pages: 20
ISSN: 1545-7362|EISSN: 1546-5004|EISBN13: 9781613509715|DOI: 10.4018/jwsr.2011010102
Cite Article Cite Article

MLA

Becker, Karin, et al. "Automatic Determination of Compatibility in Evolving Services." IJWSR vol.8, no.1 2011: pp.21-40. http://doi.org/10.4018/jwsr.2011010102

APA

Becker, K., Pruyne, J., Singhal, S., Lopes, A., & Milojicic, D. (2011). Automatic Determination of Compatibility in Evolving Services. International Journal of Web Services Research (IJWSR), 8(1), 21-40. http://doi.org/10.4018/jwsr.2011010102

Chicago

Becker, Karin, et al. "Automatic Determination of Compatibility in Evolving Services," International Journal of Web Services Research (IJWSR) 8, no.1: 21-40. http://doi.org/10.4018/jwsr.2011010102

Export Reference

Mendeley
Favorite Full-Issue Download

Abstract

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.

Request Access

You do not own this content. Please login to recommend this title to your institution's librarian or purchase it from the IGI Global bookstore.