About this Project • Who We Are • Development Process • Technical Documentation • Evaluation

This project was developed as part of an international university team project in which students from the University of Mannheim, Germany, and students from Babeș-Bolyai University in Cluj, Romania, worked together for six months on a common research question. The project was mainly organized by the Institute for Enterprise Systems (InES) at the University of Mannheim.

The key goals of the project were given as follows:

• Understand and evaluate existing architectures in terms of software adapters which link incompatible APIs or devices (provided) to required interfaces (domain-models)
• Build an infrastructure and product for the automatic execution of service compositions independent of the available API-endpoints (that is “plug-and-play” at runtime)

The results of the six-month project, i.e. both the developed platform for the dynamic integration of external APIs and execution of service compositions and the comparison with existing technologies as well as the evaluation of the developed software prototype are documented in the following.

We are all students in the area of computer science from the two mentioned universities:

• Chiș, Raluca (Babeș-Bolyai University, Cluj)
• Coajă, Andreea (Babeș-Bolyai University, Cluj)
• Hessenthaler, Marius (University of Mannheim, Mannheim)
• Horn, Tobias (University of Mannheim, Mannheim)
• Keszeg, Flavia (Babeș-Bolyai University, Cluj)
• Mic, Bogdan (Babeș-Bolyai University, Cluj)
• Widmer, Peter (University of Mannheim, Mannheim)

While the members from Germany are all studying in the master program in Business Informatics, three of the Romanian students are studying Bachelor Computer Science and one in the master program in Computer Science.

Apart from a one-week introduction phase at the beginning of the project, when the students from Mannheim travelled to Cluj, the entire cooperation during the project took place via digital media. In order to nevertheless work together successfully in such a large team with very heterogeneous previous knowledge, we pursued an agile development process and strict adherence to the SCRUM guidelines. As part of this, we agreed on week-long Sprints from Monday to Monday, with Sprint Review, Retrospective and Sprint Planning taking place in a joint meeting via Skype at the end of each Sprint. To keep track of our progress and upcoming tasks, we decided to use a Trello Board where we assigned tasks into mainly five categories: Product Backlog, Sprint Backlog, In Progress, In Review and Done (see exemplary Screenshot). Apart from this, we agreed on a written daily twice a week via the Messaging Service Discord, which was also used for other written communication during the project. The roles of Product Owner and Scrum Master changed between the team members during the project. The role of the external customer was taken over by the supervisors from the InES.

The following documentation should enable a technically experienced person to understand the function and the interaction of the core modules of the underlying Microservice Architecture of the developed software prototype. On the other hand, the implementation and the underlying concepts, especially in the area of dynamic integration of further services, should be addressed to the extent that an external person is able to integrate further services or even continue working on the developed prototype.

After a description of the overall archtitecture, the four microservices that are basically independent of each other, are explained in more detail:

• Overall Microservice Architecture
• Frontend Service
• Master Service
• Service Provider and its underlying Mapping Concept
• User Service

Besides, there are two supplementary services that were initially developed as part of an earlier archtitecture idea which was based on several independent Category Services instead of having one more generic Service Provider and became redundant with the introduction of this (in case of Finance Category Service) or were modified to serve only as an additional external API (in case of Messaging Category Service) to be accessed by the Service Provider like any external API.

During our development process we pursued an approach of Continuous Integration and Continous Delivery (CI/CD) which is shortly explained here.

You can find the user guide here.

Initially, it should be mentioned that the following evaluation does not claim to meet scientific standards. The aim is rather to give a short overview of comparable technologies in a first step. In doing so, similarities and differences between our platform and similar tools shall be pointed out. This should only be a purely qualitative comparison. In a second step, we quantitatively evaluated the performance of our platform against various criteria using previously defined use cases and associated evaluation tasks.

• Comparison With Existing Platforms
• Use-Case Based Evaluation Process