Understanding the Runtime Topology of Service-Oriented Systems Tiago Espinha, Andy Zaidman, Hans-Gerhard Gross Delft University of Technology, The Netherlands {t.a.espinha, a.e.zaidman, h.g.gross}@tudelft.nl Abstract—Through their dynamic and loosely coupled na- ture, service-oriented systems are ideal for realizing runtime evolvable systems. However, runtime evolution demands proper understanding of the configuration of service-oriented software systems over time. In order to keep system disturbance as low as possible while replacing existing services with their newer versions, engineers require an adequate illustration of how the connections and dependencies of services change in the running system. That way, they can identify the most appropriate point in the service-oriented systems’ operation time for maintenance. In this paper, we make use of the runtime topology (i.e. the configuration of a distributed, dynamically composable software system which describes available services and how they depend and interact with each other) to help software engineers under- stand service-oriented systems, and we describe a tool, Serviz, that visualizes how services are activated, and how much they interact over time. A user study demonstrates to which extent the runtime topology can support the analysis and understanding of service-oriented software systems. I. I NTRODUCTION The fact that software systems need to evolve in order to remain successful has been long recognized [1]. With the advent of Service Oriented Architectures, the maintenance problem was said to become easier [2], as a Service Oriented Architecture (SOA) would be composed of several loosely coupled (and smaller) services. These smaller services are said to be easier to evolve and more flexible to compose, thus easing overall evolution. However, in 2004 already, Gold et al. warned that even though the actual evolution was possibly easier, the understanding of service-oriented software systems would still be a challenge [2]. This is mainly due to the shift from understanding a monolithic application to understanding a distributed system composed of many entities (services). Thus, program comprehension remains an absolute and im- portant prerequisite to evolving systems [3], also for systems built around the concept of service-orientation. In this context Corbi even reported that up to 60% of the time effort of a maintenance task lies in understanding the system at hand [4]. Strangely enough then, a large-scale survey of scientific lit- erature in the area of program comprehension using dynamic analysis from 2009 did not reveal any major advances in the area of understanding service-oriented software systems using dynamic analysis. As the authors note, this seems strange as dynamically orchestrated compositions of services would seem to benefit from dynamic analysis for understanding them [5]. In particular, when understanding a service-oriented soft- ware system, one of the challenges lies in the uncertainty of the software construction [2]. This uncertainty is instigated by the fact that service-oriented software systems are composed of loosely coupled components or services. As the composition of the entire service-oriented system only happens at runtime, the services composing the system may only be known at execution time [6]. Furthermore, the service-composition can be changed at runtime, a situation that can become even more complicated when services can be automatically dis- covered [6], [7]. It comes as no surprise then that Kajko- Mattsson et al. identified the understanding of the service- oriented infrastructure as one of the most important challenges when evolving service-oriented software systems [8]. In order to support the understanding task, we propose to reverse engineer [9] the runtime topology of the service-based system. The runtime topology is the configuration of a distributed, dynamically composable software system and describes which services are available and how they depend and interact with each other at any point in time. Knowing exactly which services depend on each other, and when they are interacting with each other, enables a better understanding of how the service-oriented system is composed and a more efficient maintenance strategy as insight is obtained in when an upgrade of a service should ideally occur. However, this knowledge is only possible by continuously analyzing the runtime topology. That is, not only looking at the current runtime topology, but analyzing how it evolved over time. As such, we consider the time-dimension of this runtime topology to be very important. In this paper, we demonstrate how the runtime topology of a service-oriented software system can be reverse engi- neered from observing its operations, and investigate how the topology, augmented with a time-dimension, enables a better understanding. More specifically, our research is steered by the following research questions: RQ1 Does the runtime topology help in identifying ser- vices involved in a specific use case? RQ2 Does the runtime topology help in debugging a service-oriented system? RQ3 Does the runtime topology augmented with the time- dimension help to identify services that are used more often (e.g., to optimize them)? RQ4 Does the runtime topology help to identify periods in time when the usage of a particular service is low, e.g., for evolving it with minimal disturbance to its users?