Software systems evolve during their lifetime and therefore face several challenges. Changing requirements or upcoming feature requests make modi cations or extensions inevitable. Especially long-living software systems have often been built as monolithic applications and are based on obsolescent architectures and technologies. This circumstance makes it di cult for developers to maintain or extend software. In this paper, we report on the modernization process of our open source research project ExplorViz { moving from a monolithic towards a microservice architecture. We describe our previous version within the project and present how we solved the modernization and handled occurring problems. Afterwards, we illustrate our modernized software system and point out the obtained bene ts. Finally, we delineate open questions for the ongoing development.
Software systems evolve over time and encounter di
culties during their life cycle. Often these systems are
modi ed or extended, induced by new requirements
or upcoming requests from customers. In the context
of long-living software systems, these systems have
often been built in form of monolithic applications and
are comprised of obsolescent architectures and
technologies. A key problem of monolithic applications is
that all components are developed on a single
codebase among several developers. This basically means,
that if a developer wants to modify code or add a
new feature, he needs to be certain that the
remaining code and provided services are still working
after his changes [10]. A solution to this problem can
be employing a di erent architectural style, namely
a microservice architecture, composed of several
selfcontained systems [
The remainder of this paper is organized as follows. In Section 2, we describe the monolithic architecture of our open source project, referred to as ExplorViz Legacy , and point out problems during development. Afterwards, we present our approach to address the presented problems in Section 3. In Section 4, we discuss related work regarding our approach. Finally, the conclusions are drawn and open questions are delineated. 2
The idea behind ExplorViz was initially
conceptualized in 2012 and rst published a year later [
<<device>>
Server <<component>> ExplorViz Legacy In Figure 1 the deployment and simpli ed software stack of our GWT-based ExplorViz Legacy is shown. It can be deployed on a single server node. On startup, ExplorViz Legacy automatically creates a database for user management. The lesystem is facilitated to store serialized landscape objects, i.e., the underlying data models, that are retrieved from monitoring data and used for visualization.
The presented project setup was used since 2012 and published in 2013 on Github.2 During subsequent development we frequently migrated client code from Java to JS using GWT's JavaScript Native Interface (JSNI), i.e., embedded JS code in Java methods. The reason behind this alteration of GWT's intended work ow was the utilization of modern JS libraries to simplify the usability for users. The result was a fragmentation of ExplorViz's codebase in JSNI- and Java-methods. This was further deteriorated when we substituted GWT's WebGL implementation with the JS-based library three.js. three.js provides a high level of abstraction for 3D rendering and thus o ers a better maintainability and extensibility for new developers.
In 2016 we stopped the development of new features in ExplorViz. GWT seemed to disappear in a variety of other projects. Additionally, there was no major update of the toolkit for at least a year. Meanwhile Google released a new programming language which can also be used for web development, called 2https://github.com/ExplorViz/Explorviz Dart. This language is used by Google itself to build many applications as noted on the related website.3 Since it was announced that JSNI will be removed with the release of GWT 3, we were in need of migrating code once again. At this time ExplorViz Legacy contained a great amount of JS code. Therefore, we decided to drop GWT as sca old and modernize the monolithic project with new technologies and less dependencies to modules of the underlying web framework. 3
Two major communication technologies emerged from
practical realization when implementing web services.
Research shows that SOAP-based services are in fact
less performant and do not support mobile devices
as good as their RESTful counterparts [5].
Furthermore, the latter eases the development and in uences
the characteristics of a system, e.g., scalability and
exibility [
In [13] the authors present how the German ecommerce provider Otto modernized the underlying software system of their online shop. Instead of refactoring the old monolithic system, they completely reimplemented the functionality, using a microservice architecture. The developed microservices communicate only by accessing REST APIs. This redesign resulted in a highly scalable and fault tolerant software system.
The previously mentioned issues in ExplorViz Legacy (see Section 2) and the experience reports about successful utilization of alternative technologies, e.g., RESTful APIs, were triggers for a modernization of the ExplorViz project. We no longer saw advantages of preferring GWT over other web frameworks. Therefore, we decided to split the codebase into two separated projects, i.e., backend and frontend. The backend is implemented as a Java-based web service providing a RESTful API for clients. Since client-side code is mostly written in JS nowadays, we choose this programming language for the frontend.
Figure 2 depicts the new architecture and simplied software stack of ExplorViz. Backend and frontend are now two self-contained microservices. Thus, they can be deployed on di erent server nodes. In detail, we employ distinct technology stacks with integrated storage. This allows us to exchange a single or both microservices, as long as we take our speci ed interfaces into account.
The backend provides a RESTful API for frontend instances and is based on the Jersey framework,4 which implements the Servlet 3.0 speci cation. This is utilized to implement a web service without the need to state a web.xml le, i.e., the servlet con guration le. Instead, we use javax.servlet.annotations to 3https://webdev.dartlang.org 4https://jersey.github.io <<device>>
Server A <<microservice>>
Backend <<component>> ExplorViz (Jersey) de ne servlet declarations and mappings. We expect this approach will ease the development, especially for students.
ExplorViz's new frontend uses the client-side JS framework Ember.js (Ember), 5 which allows us to use to provide software visualizations with a WebGLenabled browser. Ember is based on the Model View ViewModel architectural pattern. As a result, manual Document Object Model accesses are not necessary and developers need less code. Ember allows and emphasizes the use of components in web sites, i.e., self-contained, reusable, and exchangeable user interface fragments. We employ this feature to encapsulate visualization modes. Therefore, they can be included, containing all necessary logic by inserting a single line of code. Network communication, e.g., fetching a landscape from the backend, is abstracted by so-called adapters. These make it easy to send or request data by using convention over con guration, if the backend applies the same rules for URL de nitions.
The introduced microservices represent the core of ExplorViz. As for future extensions, we implemented clean and comprehensive interfaces for both components, that allow the registration of extensible functionalities. A student implementing new mechanics will therefore use a template extension as starting point. Those extensions access core mechanics only by a de ned read-only API, which is implemented by the backend, respectively frontend. The modularization enables us to improve the backend or frontend, while not breaking extension support.
In summary, both frameworks are exchangeable with respect to their language domain. The backend would primarily need to de ne new ways to provide data. Since client-side JS frameworks have similar elements and approaches, we think substituting Ember can be done with little e ort.
In [
[10] compares the development and cloud deployment of an enterprise application based on a monolithic approach and a microservice architecture. Their approach contains common elements to our applied process. They employ modern technologies for separate microservices, e.g., Java in the backend and JS in the frontend. Contrary to their results, we did not face any of the mentioned problems during the migration, like failures or timeouts.
According to [5], RESTful services can improve system exibility, scalability, and performance in comparison to SOAP-based web services. Additionally, REST-based services are easier to consume and compose, based on well-de ned standards and heterogeneous operations. They provide an approach to migrate SOAP-based to RESTful services. Unfortunately, their approach is not applicable for us, since our project is based on GWT instead of SOAP.
In [
In this paper, we report on our modernization process of ExplorViz from a monolithic towards a microservice architecture. We pointed out encountered problems during our development since 2012, especially those related to the architecture underneath our software. Consequently, we described ExplorViz Legacy , the previous version of our open source research project, and presented solutions to address the existing problems. Afterwards, we revealed our modernized software system and emphasized the obtained bene ts. Even though our modernization process is still in progress, we were already able to employ a microservice architecture in order to ease maintainability on one hand, and extensibility on the other hand. Finally, we would like to delineate some of our open questions:
How can we derive best practice guidelines from our migrations for other projects? Does the rapid evolution of JS frontend frameworks in uence the ongoing evolution of ExplorViz? How can we reposition ExplorViz as an open source visualization framework for diverse data, as exemplarily shown in [14]?
B. Upadhyaya et al. \Migration of SOAP-based services to RESTful services". In: Proceedings of the 13th IEEE International Symposium on Web Systems Evolution (WSE). Sept. 2011, pp. 105{114.