Supervising the Evolution of Web Service Orchestrations Using Quality Requirements

  • Chouki Tibermacine
  • Tarek Zernadji
Part of the Lecture Notes in Computer Science book series (LNCS, volume 6903)


Since many years, Web services have confirmed their status of one of the most pertinent solutions for a given service provider, like Google, Amazon or FedEx, to open its solutions for third party software development. New business logic can be implemented through orchestrations of existing Web services. This helps development teams in capitalizing resources held by the providers of these services. Nonetheless, these service-oriented software architectures, like any other software artifact, are subject to changes during their lifecycle, and thus can undergo an evolution phenomenon. In this phenomenon, it is argued that quality can be weakened after successive changes (Lehman’s 7th law of software evolution), and this is mainly due to the lack of architecture documentation and tool support to supervise architecture changes. In this paper, we present an approach to supervise the evolution of Web service orchestrations, with quality requirements considered as a support documentation. First, we show how important design decisions, like the choice of a service-oriented architecture pattern can be formalized as a documentation for the quality they implement. Then, we detail how this documentation can be used to supervise architecture changes. In this way, the impact of changes made on a software architecture are analyzed on-the-fly to determine which quality is affected.


Quality Attribute Design Decision Software Architecture Authentication Service Business Process Execution Language 
These keywords were added by machine and not by the authors. This process is experimental and the keywords may be updated as the learning algorithm improves.


Unable to display preview. Download preview PDF.

Unable to display preview. Download preview PDF.


  1. 1.
    Bass, L., Bachmann, F., Klein, M.: Quality attribute design primitives and the attribute driven design method. In: Proceedings of the 4th International Conference on Product Family Engineering, pp. 169–186. Springer, Heidelberg (2001)Google Scholar
  2. 2.
    Bass, L., Clements, P., Kazman, R.: Software Architecture in Practice, 2nd edn. Addison-Wesley, Reading (2003)Google Scholar
  3. 3.
    Buschmann, F., Meunier, R., Rohnert, H., Sommerlad, P., Stal, M.: Pattern Oriented Software Architecture: A System of Patterns. John Wiley & Sons, Chichester (1996)Google Scholar
  4. 4.
    Capilla, R., Nava, F., Duenas, J.C.: Modeling and documenting the evolution of architectural design decisions. In: Proceeding of the Second Workshop on SHAring and Reusing Architectural Knowledge Architecture, Rationale, and Design Intent (SHARK-ADI 2007). IEEE Computer Society, Los Alamitos (2007)Google Scholar
  5. 5.
    Chung, L., Nixon, B.A., Yu, E., Mylopoulos, J.: Non-Functional Requirements in Software Engineering. Kluwer Academic Publishers, Dordrecht (1999)zbMATHGoogle Scholar
  6. 6.
    Clements, P., Bachmann, F., Bass, L., Garlan, D., Ivers, J., Little, R., Nord, R., Stafford, J.: Documenting Software Architectures, Views and Beyond. Addison-Wesley, Reading (2003)CrossRefGoogle Scholar
  7. 7.
    Clements, P., Kazman, R., Klein, M.: Evaluating Software Architectures, Methods and Case Studies. Addison-Wesley, Reading (2002)Google Scholar
  8. 8.
    Cysneiros, L.M., Sampaio do Prado Leite, J.C.: Nonfunctional requirements: From elicitation to conceptual models. IEEE TSE 30(5), 328–350 (2004)Google Scholar
  9. 9.
    Erl, T.: SOA Design Patterns. Prentice Hall, Englewood Cliffs (2009)Google Scholar
  10. 10.
    Gamma, E., Helm, R., Johnson, R., Vlissides, J.: Design Patterns: Elements of Reusable Object-Oriented Sofware. Addison-Wesley Professional Computing Series. Addison Wesley Longman, Inc., Reading (1995)Google Scholar
  11. 11.
    Jansen, A., Bosch, J.: Software architecture as a set of architectural design decisions. In: Proceedings of of the 5th IEEE/IFIP WICSA 2005 (2005)Google Scholar
  12. 12.
    Kim, S., Kim, D.-K., Lu, L., Park, S.: Quality-driven architecture development using architectural tactics. Elsevier JSS, 82(8), 211–1231 (2009)Google Scholar
  13. 13.
    Kruchten, P.: An ontology of architectural design decisions in software intensive systems. In: Proceedings of the 2nd Groningen Workshop Software Variability, pp. 54–61 (2004)Google Scholar
  14. 14.
    Lehman, M., Ramil, J.F.: Software evolution. In: Marciniak, J. (ed.) Encyclopedia of Software Engineering, 2nd edn. Wiley, Chichester (2002)Google Scholar
  15. 15.
    Marew, T., Lee, J.-S., Bae, D.-H.: Tactics based approach for integrating non-functional requirements in object-oriented analysis and design. Journal of Systems and Software 82(10), 1642–1656 (2009)CrossRefGoogle Scholar
  16. 16.
    Mylopoulos, J., Chung, L., Nixon, B.: Representing and using nonfunctional requirements: A process-oriented approach. IEEE TSE 18(6), 483–497 (1992)Google Scholar
  17. 17.
    OASIS. Web services business process execution language version 2.0. Website of the Organization for the Advancement of Structured Information Standards (2006),
  18. 18.
    OMG. Objectconstraint language specification, version 2.0, document formal/2006-05-01. Object Management Group Web Site (2006),
  19. 19.
    Tibermacine, C., Fleurquin, R., Sadou, S.: Nfrs-aware architectural evolution of component-based software. In: Proceedings of the 20th IEEE/ACM ASE 2005, Long Beach, California, USA, pp. 388–391. ACM Press, New York (2005)Google Scholar
  20. 20.
    Tyree, J., Akerman, A.: Architecture decisions: Demystifying architecture. IEEE Software 22(2), 19–27 (2005)CrossRefGoogle Scholar

Copyright information

© Springer-Verlag Berlin Heidelberg 2011

Authors and Affiliations

  • Chouki Tibermacine
    • 1
  • Tarek Zernadji
    • 2
  1. 1.LIRMM, CNRS and Montpellier-II UniversityFrance
  2. 2.Computer Science DepartmentUniversity of BiskraAlgeria

Personalised recommendations