SOA and the Button Problem

Service-oriented architecture (SOA) is a popular architectural style centered around services, loose coupling, and interoperability. A recurring problem in SOA development is the Button Problem; how to ensure that whenever a “button is pressed” on some service—no matter what—the performance of other key services remains unaffected? The Button Problem is especially complex to solve in systems that have devolved into hardly comprehensible spaghettis of service dependencies.

In a collaborative effort with industry partner First8, we present the first formal framework to help SOA developers solve the Button Problem, enabling automated reasoning about service sensitivities and candidate refactorings. Our formalization provides a rigorous foundation for a tool that was already successfully evaluated in industrial case studies, and it is built against two unique requirements: “whiteboard level of abstraction” and non-quantitative analysis.

1. 1.

   In terms of the Osi transport layer, Tcp/Ip packets involved in a push are acknowledged (as part of the Tcp/Ip protocol), but this is at a lower level of abstraction.

2. 2.

   Individual services in \(\hat{S}\) may contribute only partially to the simulation (see also Example 2). This is where our definition of simulation differs significantly from the classical one in concurrency theory (e.g., [17]). It is also why \(s \mathrel {R} \hat{s}\) appears as a conjunct on the right-hand side of the implication instead of on the left-hand side.

3. 3.

   More precisely, the only services that create additional services or calls are \(\textit{Split} \), \(\textit{AddQueue} \), and \(\textit{AddCache} \). The number of times a service can be split is bound by the number of types, while the services and calls added through \(\textit{AddQueue} \) and \(\textit{AddCache} \) carry annotations that inform Elmo to not refactor them any further.

4. 4.

   Elmo may find designs that solve the specified insensitivity goals, but that are still unacceptable to SOA developers due to external constraints (e.g., the number of machines exceeds the budget; some services should not be merged because it requires reorganization of development teams). Instead of letting Elmo first explore the entire design space and then filtering the unacceptable solutions, SOA developers can specify additional model annotations upfront to constrain which refactorings Elmo will try to apply; corners of unacceptable solutions in the design space are skipped.

   Specifically, in the initial deployment model, users can indicate that a service must remain intact (i.e., it cannot be split, merged, or modified); that some services cannot be merged; that some sets of types cannot be split; that a call must remain intact (i.e., it cannot be flipped or replaced by a queue/cache); that some sets of services must be collocated; that the number of machines must not exceed some limit.

Authors and Affiliations

1. Department of Computer Science, Open University of the Netherlands, Heerlen, The Netherlands

   Sung-Shik Jongmans, Arjan Lamers & Marko van Eekelen

2. CWI, Netherlands Foundation of Scientific Research Institutes, Amsterdam, The Netherlands

   Sung-Shik Jongmans

3. First8, Nijmegen, The Netherlands

   Arjan Lamers

4. Institute for Computing and Information Sciences, Radboud University Nijmegen, Nijmegen, The Netherlands

   Marko van Eekelen

Corresponding author

Correspondence to Sung-Shik Jongmans .

Editors and Affiliations

1. Consiglio Nazionale delle Ricerche, Pisa, Italy

   Maurice H. ter Beek

2. Macquarie University, Sydney, NSW, Australia

   Annabelle McIver

3. University of Minho, Braga, Portugal

   José N. Oliveira

Reprints and permissions

© 2019 Springer Nature Switzerland AG

Policies and ethics