Towards Holistic Modeling of Microservice Architectures Using LEMMA Florian Rademacher1 , Jonas Sorgalla1 , Philip Wizenty1 and Simon Trebbau1 1 IDiAL Institute, University of Applied Sciences and Arts Dortmund, Otto-Hahn-Straße 27, 44227 Dortmund, Germany Abstract Microservice Architecture (MSA) is an approach for the realization of scalable and maintainable software systems. However, MSA adoption also increases architecture complexity significantly when compared to monolithic applications. This paper investigates MSA as an object of study for the development and application of architecture modeling languages (AMLs) to facilitate MSA engineering through Model-driven Engineering and lifted abstraction. To this end, we present a case study microservice architecture from the Electromobility domain and identify modeling dimensions to employ AMLs in MSA engineering. Next, we illustrate AML adoption for certain dimensions using the AMLs from our Language Ecosystem for Modeling Microservice Architecture (LEMMA). With these contributions, we aim to provide insights on MSA as a driver for research on holistic AML adoption throughout architecture design, development, and operation. Keywords microservice architecture, model-driven engineering, architecture modeling languages 1. Introduction terwards careful balancing of microservices’ granularity. Too fine-grained microservices increase network load, Microservice Architecture (MSA) is a novel approach for thereby decreasing performance [9], whereas too coarse- the realization of service-based software architectures [1]. grained services counteract scalability. In addition, MSA MSA emerged from Service-oriented Architecture (SOA) fosters technology heterogeneity [1] by enabling teams [2, 3] and promotes to decompose software architectures to independently decide for implementation technolo- into microservices. A microservice is a service [2] that gies, e.g., frameworks and databases, which may result puts particular emphasis on (i) cohesion by fulfilling a in additional maintainability cost and steeper learning single, distinct task; (ii) independence in terms of its curves for new team members [10]. Moreover, MSA as- implementation, data management, testing, deployment, sumes a sophisticated deployment infrastructure includ- and operation; and (iii) responsibility w.r.t. its interaction ing specialized components, e.g., for service discovery, with other components and ownership by exactly one API provisioning, load balancing, and monitoring [11]. team [1, 4]. This paper investigates MSA as an object of study for Based on these characteristics, MSA adoption is ex- the design, implementation, and application of architec- pected to benefit a software architecture’s (i) performance ture modeling languages (AMLs), i.e., architecture descrip- efficiency because microservices are independently scal- tion languages that constitute modeling languages in the able; (ii) maintainability by allowing targeted modifica- sense of Model-driven Engineering (MDE) [12, 13]. Our tion or replacement of functionality given microservices’ hypothesis is that AMLs can reduce the complexity in high cohesion and loose coupling; and (iii) reliability due MSA engineering by introducing abstraction to, e.g., (i) to microservices’ constrained functional scope and their facilitate reasoning about granularity by reifying service self-responsibility for fault handling [5, 1, 6, 7]. boundaries; (ii) make technology choices explicit; and (iii) On the other hand, MSA tends to increase the com- support the specification of operation infrastructure. Our plexity of a software architecture because it poses sig- contribution is twofold. First, we present a case study mi- nificant challenges concerning architecture design, de- croservice architecture from the Electromobility domain velopment, and operation [8]. For example, regarding and identify modeling dimensions [13] to employ AMLs in design, MSA requires microservice identification and af- the context of MSA. Second, we illustrate AML adoption for certain modeling dimensions of the case study using MDE4SA 2021: Second International Workshop on Model-driven Engineering for Software Architecture, September 13, 2021, Virtual the Language Ecosystem for Modeling Microservice Ar- Envelope-Open florian.rademacher@fh-dortmund.de (F. Rademacher); chitecture (LEMMA), which is a set of AMLs for MSA, jonas.sorgalla@fh-dortmund.de (J. Sorgalla); that we developed in our previous work [14, 15]. With philip.wizenty@fh-dortmund.de (P. Wizenty); both contributions, we aim to provide insights on MSA as simon.trebbau@fh-dortmund.de (S. Trebbau) a driver for AML research w.r.t. holistic architecture mod- Orcid 0000-0003-0784-9245 (F. Rademacher); 0000-0002-7532-7767 eling, i.e., the usage of AMLs throughout architecture (J. Sorgalla); 0000-0002-3588-5174 (P. Wizenty) © 2021 Copyright for this paper by its authors. Use permitted under Creative design, development, and operation. Commons License Attribution 4.0 International (CC BY 4.0). CEUR Workshop Proceedings http://ceur-ws.org ISSN 1613-0073 CEUR Workshop Proceedings (CEUR-WS.org) The remainder of the paper is organized as follows. Figure 1: Service-based design of the PACP including shared infrastructure components. Section 2 introduces the case study microservice archi- • C h a r g i n g S t a t i o n M a n a g e m e n t M i c r o s e r v i c e : Man- tecture. Section 3 derives modeling dimensions from ages charging station information like location, the case study. In Section 4, we apply LEMMA to cer- charging type, and plug type, and receives data tain modeling dimensions by using its AMLs to express from charging stations. various parts of the case study architecture. Section 5 • C h a r g i n g S t a t i o n S h a r i n g M S : Realizes functional- discusses the resulting insights on holistic architecture ity for citizens to offer spare charging stations on modeling for MSA. Sections 6 and 7 present related work private ground for use by others under certain and conclude the paper, respectively. conditions and for a given time period. • C h a r g i n g S t a t i o n S e a r c h M S : This service imple- ments functionality to search for spare charging 2. Park and Charge Platform Case stations. Study • B o o k i n g M a n a g e m e n t M S : Enables owners of electric vehicles to book spare charging stations. For this This section introduces the microservice architecture of purpose, the service maintains a Blockchain [16] the Park and Charge Platform (PACP), which we will use to prevent manipulation during booking, and sub- throughout the paper as a case study to illustrate and sequent charging and billing processes. discuss holistic architecture modeling in the context of • E n v i r o n m e n t a l D a t a A n a l y s i s M S : Supports han- MSA. The PACP constitutes one of the deliverables of dling of air quality indicators, e.g., CO2 pollution, the PuLS research project1 . PuLS aims to increase the temperature, and humidity, and therefore inter- accessibility of charging stations for electric vehicles by acts with a municipal Environment Monitoring enabling citizens to offer spare stations on private ground System. for use by other owners of electric vehicles. In addition, The listed PACP microservices constitute logical mi- charging stations are equipped with sensors to contribute croservices in the sense of the Command Query Respon- in urban air quality monitoring. sibility Segregation (CQRS) pattern [17]. CQRS decom- In PuLS, we design, develop, and operate the PACP to poses a microservice into a command part and query handle charging station offering and booking, and the parts. The command part handles incoming requests that storage and analysis of air quality indicators. The PACP result in state changes, e.g., database updates, and the is a microservice architecture to ensure (i) scalability of query parts execute state queries, e.g., database reads. the solution across city quarters; (ii) modifiability to fos- To this end, the command part sends state changes to ter innovation through quick functionality integration; query parts, which then incorporate the changes into and (iii) technology heterogeneity, in particular of pro- their data models. For the PACP, the usage of CQRS has gramming languages used by project partners. Figure 1 two benefits. First, query operations are much more fre- shows the PACP’s design. quent than write operations, and CQRS permits separate The following paragraphs describe the microservices scaling of command and query parts because we realize and infrastructure components of the PACP. them as physically segregated microservices. Second, we can optimize storage for query operations and thus, e.g., Microservices The PACP consists of five microser- enable time series processing of sensor data. vices, whose design permits runtime replication of ser- vice instances. In detail, the services provide the archi- Infrastructure Components Figure 1 considers two tecture with the following capabilities: kinds of infrastructure components. 1 Funding by the German Federal Ministry of Transport and Service-oriented infrastructure components provide a Digital Infrastructure (grant number 03EMF0203C). single microservice with capabilities like API provision- Table 1 Initial modeling dimensions according to Combemale et al. [13] with relevance to MSA. # Modeling Stage Associated Pains According to Soldani et al. [8] Dimension D.1 Exploration Design Service Dimensioning, Size/Complexity (S/C) D.2 Communication Design Service Contracts, S/C D.3 Construction Design API Versioning, Communication Heterogeneity, Service Contracts, Mi- croservice Separation, S/C D.4 Implementation Development Microservice Separation, Overhead, Human Errors Operation Operational Complexity, Service Coordination, S/C D.5 Testing Development Integration Testing, Performance Testing, S/C D.6 Documentation Design S/C ing (A P I G a t e w a y ), discovery of other PACP microservices vices’ domain models using Domain-driven Design (DDD) (S e r v i c e D i s c o v e r y ), and data management (D o c u m e n t - [18, 1]. DDD is a model-based methodology, which we O r i e n t e d D a t a b a s e and R e l a t i o n a l D a t a b a s e ). Further- used in the PACP’s design to capture the structures and more, the PACP secures accesses via the I d e n t i t y a n d relationships of the relevant concepts from the applica- A c c e s s M a n a g e m e n t (IAM) component, which realizes user tion domain. management, authentication, and authorization of mi- Moreover, models are a means to communicate and croservices’ command and query functionalities. document, e.g., domain concepts or service contracts, On the other hand, PACP microservices interact with across teams (D.2 and D.6). In MSA, efficient commu- each other by sending asynchronous events to the cen- nication and a common architectural understanding is tralized M e s s a g e B r o k e r component (cf. Fig. 1). Following crucial since teams and their communication should be the Domain Event pattern [17], we conceive exchanged decomposed along service boundaries [4]. For the PACP, events domain events that belong to the portion of the we rely on LEMMA models and derived artifacts to share application domain for which a microservice is responsi- microservice APIs and event schemas across teams (cf. ble. To this end, the message broker integrates an event Sect. 4). schema registry and behaves as an event store. The reg- Next to domain concept definition, models can be con- istry allows centralized management of event structures structed in MSA engineering, e.g., to specify APIs and and their sharing across project partners, whereas the their versions, or reason about communication hetero- event store permits access to events in their order of geneity (D.3). appearance and thus auditing, e.g., of charging station booking processes. Development Stage Code generators may support the development of microservices (D.4) by producing boil- erplate code from models [13, 19]. We use this approach 3. Modeling Dimensions for for the PACP to reduce manual overhead and human er- Microservice Architecture rors in recurring coding tasks like connecting a service to the message broker (cf. Fig. 1). Furthermore, it enables Based on our experience in realizing the PACP (cf. Sect. 2), us to keep the model-based architecture design consis- we identify initial modeling dimensions according to tent with the implementation of microservices’ domain Combemale et al. [13] and with relevance to MSA. We data, APIs, and deployment specifications (cf. Sect. 4). consider AMLs central means to construct models for In addition, it is possible to run early integration tests these dimensions and later enable their processing. Ta- with the generated code or manually extend it, e.g., for ble 1 lists the identified modeling dimensions together subsequent performance testing (D.5). with the related stage and pains [8] in MSA engineering. The following paragraphs summarize per stage the Operation Stage For the PACP, the use of models is rationale for each dimension. also beneficial in the operation stage of MSA engineering. More precisely, we use models to harmonize the descrip- Design Stage In microservice design, models can make tion of service deployment, infrastructure operation and a microservice’s granularity explicit by reifying the struc- usage across heterogeneous technologies. The result- tures and relationships of domain concepts in the ser- ing model-based description of the PACP’s operation vice’s responsibility (cf. Dimension D.1 in Table 1). This specifics then facilitates reasoning about the architec- modeling purpose aligns to the construction of microser- ture’s operational complexity (D.4). 4. Modeling Park and Charge The C S M M team constructed the domain model in collab- oration with domain experts using DDD. Line 1 defines Case Study Microservices with the bounded context C h a r g i n g S t a t i o n M a n a g e m e n t , which LEMMA comprises three domain concepts. The E l e c t r i f i e d P a r k i n g S p a c e concept in Lines 2 to 9 This section illustrates the modeling of PACP microser- represents a parking space with a charging station. The vices (cf. Sect. 2) along the dimensions from Sect. 3 using concept is a DDD e n t i t y and thus has a domain-specific LEMMA. LEMMA specifies textual AMLs for the model- identity [18] determined by the i d field, which therefore ing of MSA-based software systems from various archi- exhibits the DDML’s i d e n t i f i e r keyword [15] (cf. Line 3). tecture viewpoints [20]. Each LEMMA viewpoint clusters In addition, the concept clusters the fields n a m e and p l u g - one or more AMLs, whose metamodels [13] formalize T y p e (cf. Lines 4 and 5), which, like i d , are of LEMMA’s MSA concepts and enable stakeholders to state their con- built-in s t r i n g type. cerns towards a microservice architecture [15]. By using Moreover, the E l e c t r i f i e d P a r k i n g S p a c e concept is a LEMMA as a concrete modeling approach for MSA, we DDD a g g r e g a t e . As such, it embeds other domain con- aim to provide insights on MSA as a driver for AML re- cepts like C h a r g i n g T y p e and P a r k i n g S p a c e S i z e in the form search w.r.t. the holistic usage of AMLs in microservice of p a r t s (cf. Lines 6 and 7), and defines a transactional design, development, and operation. boundary, e.g., for database access [18]. Consequently, Each of the following subsections presents an excerpt instances of embedded domain concepts must not ex- of one or more LEMMA models for a certain viewpoint ist without a corresponding E l e c t r i f i e d P a r k i n g S p a c e in- on the PACP’s C h a r g i n g S t a t i o n M a n a g e m e n t M i c r o s e r v i c e stance. (C S M M ; cf. Sect. 2). The complete code of all PACP models Lines 10 to 13 illustrate the DDML’s support for mod- can be found on GitHub2 . eling enumerated domain concepts. Since all concepts defined in LEMMA domain models constitute custom 4.1. Modeling Microservices’ Domain types [15], it is possible to use the C h a r g i n g T y p e enumer- Data ation as a field type and embed it in the E l e c t r i f i e d P a r k - i n g S p a c e concept. As described in Sect. 3, a microservice’s granularity shall Lines 14 to 18 model the E l e c t r i f i e d P a r k i n g S p a c e C r e - result from its responsibility in the application domain. a t e d concept as a DDD v a l u e O b j e c t and d o m a i n E v e n t [18, LEMMA specifies the Domain Viewpoint and its Domain 21]. The C S M M ’s command microservice (cf. Sect. 2) uses Data Modeling Language (DDML) [15] to allow domain the concept to inform query microservices about new experts and microservice developers the model-based parking spaces (cf. Sect. 4.4). LEMMA’s DDML provides identification and clustering of services’ domain concepts. the i m m u t a b l e keyword to protect value objects against The DDML covers modeling dimensions D.1 and D.3 (cf. state changes (cf. Line 16). As opposed to entities, DDD Table 1) as it enables DDD-based organization of domain recognizes value objects to model domain concepts that concepts in bounded contexts [18] and the separation of do not have domain-specific identities [18]. Instead, the microservice data based on these contexts [1]. identities of their instances result from the values of all Listing 1 shows an excerpt of the C S M M domain model fields and changes to the states of value object instances in LEMMA’s DDML. should require new value object instances. Listing 1: Excerpt of the C S M M domain model in LEMMA’s DDML (file “domain.data”). 4.2. Modeling Technology and Pattern 1 context ChargingStationManagement { Metadata 2 structure ElectrifiedParkingSpace { 3 string id, LEMMA specifies the Technology Viewpoint to support 4 string name, 5 string plugType, coping with MSA’s technology heterogeneity [1]. For 6 ChargingType chargingType, this purpose, the viewpoint comprises the Technology 7 ParkingSpaceSize parkingSpaceSize, 8 ... Modeling Language (TML) [14]. It covers modeling di- 9 } mensions D.4 and D.5 in the Development stage of MSA 10 enum ChargingType{ 11 FAST, engineering (cf. Table 1) by enabling the construction of 12 NORMAL technology models. These models can capture a variety 13 } 14 structure ElectrifiedParkingSpaceCreated { microservice programming languages, communication 16 immutable string name, 17 ... protocols, and operation technologies. However, it also 18 }} allows the definition of arbitrary metadata using technol- ogy aspects [14]. Such aspects may augment elements in 2 https://www.github.com/SeelabFhdo/mde4sa-2021 other LEMMA models with additional semantics regard- ing, e.g., technology-specific configuration options, but P u t M a p p i n g annotation, which elevates Java methods to also pattern concepts. handlers for HTTP P U T requests [23]. The following paragraphs describe the usage of LEM- MA’s TML for the construction of technology models Modeling Pattern Metadata with the TML Since that reify microservice technologies and pattern concepts,the TML itself does not constrain the semantics of tech- respectively. nology aspects and supports their usage on a variety of modeled elements, e.g., microservices, their interfaces, Modeling Technology Metadata with the TML In operations and containers [14], we also use them to reify Listing 2, we present an excerpt of a technology model information about concepts from design and architecture for the Spring framework3 and thus the technology on patterns relevant to MSA. More specifically, LEMMA’s which the majority of PACP microservices rely for their aspect mechanism enables to capture pattern metadata implementation. and augment modeled elements with them so that the elements become semantically recognizable as being in- Listing 2: Excerpt of the technology model for the Spring volved in the realization of a design or architecture pat- framework in LEMMA’s TML (file “Spring.tech- tern. Listing 3 shows the technology model for the CQRS nology”). pattern as used by the PACP (cf. Sect. 2). 1 technology Spring { 2 3 protocols { sync rest data formats ”application/json” Listing 3: Excerpt of the technology model for the CQRS 4 default with format ”application/json”; pattern in LEMMA’s TML (file “Cqrs.technolo- 5 6 } service aspects { gy”). 7 aspect PutMapping for operations { technology CQRS { 1 8 selector(protocol = rest); service aspects { 2 9 } aspect CommandSide for microservices { 3 10 ... string logicalService; 4 11 }} } 5 aspect QuerySide for microservices { 6 Line 1 introduces the S p r i n g technology. Next, the p r o - string logicalService; 7 } 8 t o c o l s section in Lines 2 to 5 specifies the synchronous ... 9 r e s t protocol, which represents REST-based interaction }} 10 [22] between PACP microservices and external consumers The model specifies the C Q R S technology (cf. Line 1) (cf. Sect. 2). Protocol definitions in the TML must also and defines two service-related technology aspects (cf. provide information about supported data formats. Thus, Lines 2 to 10). The C o m m a n d S i d e aspect in Lines 3 to 5 in Line 3 we express the support of the r e s t protocol for enables the augmentation of modeled microservices that the JSON data format4 and also select it as the protocol’s constitute the physical command microservices in adop- default format in Line 4. tions of the CQRS pattern (cf. Sect. 2). The Q u e r y S i d e Lines 6 to 11 cluster the s e r v i c e a s p e c t s section of aspect in Lines 6 to 8, on the other hand, supports the the Spring technology model. The section illustrates the semantic enrichment of modeled microservices, which definition of the P u t M a p p i n g aspect to reify the epony- represent physical query microservices in a CQRS sce- mous Spring annotation5 . LEMMA distinguishes be- nario. Both aspects declare the l o g i c a l S e r v i c e property tween service-related and operation-related technology (cf. Lines 4 and 7). It can store the name of the logical mi- aspects [14]. Service-related technology aspects are appli- croservice to which a set of physical CQRS microservices cable to elements of modeled microservices (cf. Sects. 4.3 belongs. and 4.4), whereas operation-related technology aspects The C o m m a n d S i d e and Q u e r y S i d e aspects provide, e.g., target elements of modeled operation nodes (cf. Sect. 4.5). model analyzers with a reliable means to recognize the Furthermore, LEMMA allows constraining aspects’ ap- command and query services of a logical CQRS microser- plicability depending on the peculiarities of target ele- vice in order to verify that all query microservices provide ments. For example, the P u t M a p p i n g aspect is applicable operations to consume update events from the command at most once to modeled microservice operations (cf. the microservice (cf. Sect. 4.4). s i n g l e v a l keyword and the f o r o p e r a t i o n s directive in Line 7). Additionally, the target operation must make use of the r e s t protocol (cf. the protocol s e l e c t o r in Line 8). 4.3. Modeling Microservices’ Application These three constraints map to the semantics of Spring’s Programming Interfaces 3 https://www.spring.io LEMMA defines the Service Viewpoint for developer 4 https://www.json.org concerns in microservice implementation [15]. The view- 5 https://docs.spring.io/spring-framework/docs/current/ javadoc-api/org/springframework/web/bind/annotation/ point specifies the Service Modeling Language (SML) for PutMapping.html the model-based expression of microservices, their in- apply the A p p l i c a t i o n aspect from the S p r i n g technology terfaces, operations and endpoints. The SML supports model to the modeled microservice. microservice separation and the design of APIs as im- Line 8 introduces the microservice’s definition. LEM- plicit service contracts [24], and thus covers modeling MA provides modifiers to constrain a microservice’s vis- dimensions D.2, D.3, and D.4 (cf. Table 1). ibility to, e.g., architecture-internal components or the Listing 4 shows an excerpt of the service model for owning team [15]. The C S M M ’s command microservice, the C S M M ’s physical command microservice in LEMMA’s however, exhibits the p u b l i c modifier so that it will be SML. The model also reifies technology choices based on reachable by architecture-external components like charg- LEMMA’s TML (cf. Sect. 4.2). ing stations (cf. Sect. 2). In addition, the service is of a f u n c t i o n a l nature. Hence, it provides a business-related Listing 4: Excerpt of the service model for the C S M M ’s com- capability to the architecture, and does not serve infras- mand microservice in LEMMA’s SML includ- tructure or generic utility purposes [15]. ing technology choices based on the TML (file Lines 10 to 13 introduce the microservice’s commands “chargingStationManagement.services”). API as the C o m m a n d s interface with a REST endpoint. The 1 import datatypes from ”domain.data” as Domain SML integrates the @ e n d p o i n t s annotation for endpoint 2 import technology from ”Spring.technology” as Spring 3 @technology(Spring) specifications that constitute combinations of a technol- 4 @Spring::_aspects.Application( ogy-specific protocol like the r e s t protocol from the im- 5 name=”ChargingStationManagementCommand”, 6 port=8071 ported S p r i n g technology model (cf. Sect. 4.2), and one 7 ) or more addresses like the URI segment “/resources/v1”. 8 public functional microservice 9 de.fhdo.puls.ChargingStationManagementCommand { Lines 14 to 21 define the c r e a t e E l e c t r i f i e d P a r k i n g - 10 @endpoints( S p a c e operation as part of the C o m m a n d s interface. Callers 11 Spring::_protocols.rest: ”/resources/v1”; 12 ) invoke the operation to trigger the creation of electri- 13 interface Commands { fied parking spaces managed by the C S M M (cf. Sect. 4.1). 14 @endpoints( 15 Spring::_protocols.rest: ”/electrifiedParkingSpace”; Lines 14 to 17 determine the URI segment and HTTP re- 16 ) quest method [23] for the REST-based invocation of the 17 @Spring::_aspects.PutMapping 18 public createElectrifiedParkingSpace( operation. While the URI segment is again configured 19 @Spring::_aspects.RequestBody as an endpoint address for the imported r e s t protocol, 20 sync in command : Domain::ChargingStationManagement. 21 CreateElectrifiedParkingSpaceCommand); the operation receives the request method via the P u t - 22 } M a p p i n g technology aspect from the Spring technology 23 ... 24 } model (cf. Listing 2). Line 18 introduces the c r e a t e E l e c - t r i f i e d P a r k i n g S p a c e operation and Lines 19 to 21 define LEMMA’s AMLs provide an import mechanism to in- its synchronous incoming parameter c o m m a n d [15]. The tegrate models from different viewpoints [15]. A model type of the parameter corresponds to a concept from the import must specify (i) the kind of the imported model el- C S M M ’s domain model that constitutes a structured com- ements (after the i m p o r t keyword); (ii) the path to the im- mand for the creation of a newly managed parking space. ported model (after the f r o m keyword); and (iii) an import Hence, the parameter also receives an application of the alias (after the a s keyword). Line 1 relies on LEMMA’s R e q u e s t B o d y aspect from the S p r i n g technology model. import mechanism to import the C S M M domain model (cf. This aspect maps to the eponymous Spring annotation7 , Listing 1) under the alias D o m a i n . The import of domain which leads to the extraction of parameter values from models by service models determines the portion of the the request bodies of inbound HTTP requests. application domain, for which a modeled microservice is responsible. Line 2 imports the Spring technology model 4.4. Modeling Asynchronous (cf. Listing 2) under the alias S p r i n g . As described in Sect. 4.2, technology model imports integrate LEMMA’s Microservice Interaction Technology Viewpoint with the Service Viewpoint so As described in Sect. 2, PACP microservices interact asyn- that modeled microservices can be augmented with in- chronously using a message broker and events. We de- formation that reflect technology choices. cided for Kafka8 as broker technology and most events Lines 3 to 24 model the C S M M ’s command microservice. originate from command microservices informing query Line 3 uses the SML’s @ t e c h n o l o g y annotation to assign microservices about state changes. the microservice the imported S p r i n g technology model. To model Kafka-based sending of such CQRS update In order to configure the name and port of the Spring events by command services, we again rely on LEMMA’s application that realizes the microservice6 , Lines 4 to 7 7 https://docs.spring.io/spring-framework/docs/current/ javadoc-api/org/springframework/web/bind/annotation/ 6 https://docs.spring.io/spring-boot/docs/current/reference/ RequestBody.html 8 html/application-properties.html https://kafka.apache.org SML as it supports the (i) specification of event produc- operation-related modeling dimension D.4 (cf. Table 1) tion and receipt by service operations; and (ii) augmen- and makes the operation infrastructure of a microservice tation of model elements with broker and pattern infor- architecture explicit. Listing 6 shows an excerpt of the mation from technology models (cf. Sect. 4.2). Listing 5 operation model for the C S M M ’s command microservice. shows an extended version of the service model for the C S M M ’s command microservice (cf. Listing 4) with ele- Listing 6: Excerpt of the operation model for the C S M M ’s ments for asynchronous event sending. command microservice in the OML (file “charg- ingStationManagement.operation”). Listing 5: Extended version of the service model for the import microservices 1 C S M M ’s command microservice (cf. Listing 4) from ”chargingStationManagement.services” as Services 2 3 with elements for asynchronous microservice import technology from ”container_base.technology” as ContainerBase 4 interaction. import nodes from ”eureka.operation” as ServiceDiscovery 5 import nodes from ”keycloak.operation” as IAM 6 1 ... import nodes from ”mongodb.operation” as Database 7 2 import technology from ”Kafka.technology” as Kafka @technology(ContainerBase) 8 3 import technology from ”Cqrs.technology” as CQRS container CommandContainer 9 4 ... deployment technology ContainerBase::_deployment.Kubernetes 10 5 @technology(Kafka) with operation environment ”openjdk:11-jdk-slim” 11 6 @technology(CQRS) deploys Services::de.fhdo.puls. 12 7 @endpoints(Kafka::_protocols.kafka: ”kafka-server1:9092”;) ChargingStationManagementCommand 13 8 @CQRS::_aspects.CommandSide(”ChargingStationManagement”) depends on nodes ServiceDiscovery::Eureka, Database::MongoDB, 14 9 functional microservice IAM::Keycloak { 15 10 de.fhdo.puls.ChargingStationManagementCommand { default values { 16 11 ... eurekaUri=”http://discovery-service:8761/eureka” 17 12 interface Commands { ... 18 13 ... } 19 14 @Kafka::_aspects.Participant( } 20 15 topic=”parkingSpaceCreatedEvents” 16 ) 17 sendParkingSpaceCreatedEvent( Lines 1 to 4 import the service model of the C S M M ’s 18 19 async out event : Domain::ChargingStationManagement .ElectrifiedParkingSpaceCreated); command microservice (cf. Listing 4) and a technology 20 }} model for container technology10 . Lines 5 to 7 import three other LEMMA operation models that specify the Lines 2 and 3 add imports for the Kafka technology PACP’s service discovery and IAM component as well model9 and the CQRS technology model (cf. Listing 3), as the database of the C S M M ’s command microservice (cf. respectively. Next, Lines 5 and 6 apply both models to Sect. 2). LEMMA supports the decomposition of opera- the command microservice. Consequently, we can con- tion models to separate definitions of centralized infras- figure an endpoint for the k a f k a protocol from the K a f k a tructure components, e.g., service discoveries, from those technology model to specify the location of the Kafka of microservice-specific components, e.g., containers. broker (cf. Line 7). Moreover, we apply the C o m m a n d S i d e Lines 8 to 20 model the C o m m a n d C o n t a i n e r to deploy aspect from the C Q R S technology model to the microser- the C S M M ’s command microservice. For this purpose, the vice (cf. Line 8) so that it is semantically recognizable as container applies the imported C o n t a i n e r B a s e technol- the physical command microservice of the logical “Charg- ogy model and leverages the provided K u b e r n e t e s deploy- ingStationManagement” microservice (cf. Sect. 4.2). ment technology11 with a Java image for its execution Lines 14 to 19 define the s e n d P a r k i n g S p a c e C r e a t e d - (cf. Lines 10 and 11). LEMMA’s support for container- E v e n t operation for sending Kafka events after the cre- based deployment also determines microservices’ techni- ation of newly managed electrified parking spaces. To cal replicability [4]. More precisely, modeled microser- this end, the P a r t i c i p a n t aspect configures the event’s vices (cf. Sect. 4.3) act as templates for runtime service topic. In addition, the operation specifies the asynchro- instances, whose replicability characteristics are to be nous outgoing parameter e v e n t [15], which is typed by determined by modeled containers. the E l e c t r i f i e d P a r k i n g S p a c e C r e a t e d domain event from Lines 12 and 13 specify that the modeled container the imported C S M M domain model (cf. Listing 1). deploys the imported C S M M command microservice. Lines 14 and 15 configure the container to depend 4.5. Modeling Microservice Deployment on the PACP’s Eureka-based service discovery12 and Keycloak-based IAM provider13 as well as the MongoDB In the following, we accompany the domain and service database technology14 for document-oriented storage of model of the C S M M ’s command microservice (cf. Sects. 4.1, 4.3, and 4.4) with an operation model for LEMMA’s Op- 10 https://www.github.com/SeelabFhdo/mde4sa-2021/blob/ eration Viewpoint [15]. The viewpoint specifies the Op- master/technology/container_base.technology 11 eration Modeling Language (OML), which covers the https://www.kubernetes.io 12 https://www.github.com/Netflix/eureka 9 13 https://www.github.com/SeelabFhdo/mde4sa-2021/blob/ https://www.keycloak.org 14 master/technology/Kafka.technology https://www.mongodb.com charging station information (cf. Sect. 2). as-needed technology augmentation of models with the Finally, the container uses the d e f a u l t v a l u e s section TML (cf. Sect. 4.2). This approach copes with MSA’s tech- of LEMMA’s OML [15] in Lines 16 to 19 to determine nology heterogeneity [1] and facilitates the reconstruc- values for technology-specific configuration options that tion of technology information from microservice im- account for all deployed microservices. More precisely, plementations. However, it requires upfront technology the e u r e k a U r i option receives the URI to the PACP’s ser- model construction, and balancing of semantic-oriented vice discovery so that the deployed C S M M command mi- and technology-oriented modeling. For example, the P u t - croservice can leverage its capabilities. M a p p i n g aspect in Sect. 4.2 reifies the eponymous Spring annotation. Yet, it targets HTTP P U T requests so that the name P u t fits better to the intended semantics. AML re- 5. Discussion search could study trade-offs between semantic-oriented and technology-oriented modeling, e.g., by comparing This section provides insights on MSA as a driver for AML the effectiveness of flexible AMLs like those of LEMMA research w.r.t. holistic architecture modeling. Therefore, with modeling languages that integrate keywords for we discuss experiences from adopting LEMMA’s AMLs MSA patterns or technologies (cf. Sect. 6). to the PACP (cf. Sects. 2 and 4) in the different stages of Behavior modeling is another area for MSA-inspired MSA engineering (cf. Sect. 3). AML research. Currently, none of LEMMA’s AMLs sup- ports behavior modeling w.r.t. service logic or data ex- 5.1. AMLs in MSA Design change as we initially perceived it technology-specific. Concerning MSA design, LEMMA’s DDML focuses on In this respect, MSA represents an interesting field to tactical DDD, i.e., the modeling of domain concepts within study the integration of technology-specific behavior bounded contexts [18] (cf. Sect. 4.1). While tactical DDD languages, e.g., programming languages, with modeling allows determination of a microservice’s granularity in languages. However, AML research might also focus terms of domain concept structures and relationships, it on adopting technology-agnostic behavior modeling lan- does not provide means to express domain-driven ser- guages, e.g., UML sequence diagrams, to MSA engineer- vice interaction. For this purpose, strategic DDD is appli- ing for a facilitated reasoning about service interactions. cable as it classifies the relationships between bounded Due to MSA’s technology heterogeneity, teams are contexts [18]. Next to DDD, there also exist alternative free to employ AMLs in MSA engineering. Hence, AML approaches like Event Storming [25], which partition research could study the collaboration of modeling and microservices and their interactions based on domain non-modeling teams. For the PACP, we implemented a events. However, all these approaches use models to ab- set of model transformations to integrate LEMMA-based stract from technical details, and foster the collaboration microservices with other teams’ components. For syn- between domain experts and developers. For instance, chronous service interactions, we support the transfor- strategic DDD relies on graphical context maps [18], while mation/derivation of LEMMA models to/from OpenAPI Event Storming combines a textual notation with box- specifications15 . For asynchronous service interactions, and-line diagrams [25]. Thus, we perceive potential for we transform/derive LEMMA models to/from Avro event AML research to study the effectiveness of these ap- specifications16 . While this approach is sufficient for the proaches and formalize them to allow automated rea- PACP, it requires dedicated transformations as well as soning of resulting models [13]. additional specification management. Furthermore, MSA enables teams to employ different approaches with varying degrees of autonomy in ser- 5.3. AMLs in MSA Operation vice design and realization [4]. For example, a team may own microservices, which incorporate shared artifacts [1] In MSA operation, the usage of markup languages like owned by other teams or which do not rely on such YAML17 is frequent for the textual specification of op- artifacts at all. Thus, AMLs for MSA must support dis- eration nodes and LEMMA’s OML (cf. Sect. 4.5) aims tributed modeling including model evolution and integra- to allow harmonization of heterogeneous textual speci- tion. To this end, LEMMA allows, e.g., model decomposi- fication approaches through models. As a result, AML tion within or across team boundaries using imports [26], research could next focus on model processing in the con- and versioning of evolvable model elements [15]. text of MSA operation. For instance, static analyzers may support in the reconstruction of MSA operation models from textual specifications. That is, because approaches 5.2. AMLs in MSA Development like Kubernetes enable holistic operation specification Technology abstraction is a key benefit of MDE and thus 15 https://www.openapis.org AMLs [13]. LEMMA enables technology-agnostic model- 16 https://avro.apache.org ing in the DDML and SML (cf. Sects. 4.1, 4.3, and 4.4), and 17 https://www.yaml.org ranging from service deployment to infrastructure con- T y p e and A r t e f a c t T y p e to capture operation nodes and figuration and usage. deployed artifacts provider-independently. A CPIM is then transformed to a provider-specific CPSM. Similarly to LEMMA’s OML (cf. Sect. 4.5), CloudML focuses on 6. Related Work operation aspects of cloud-native applications that may incorporate microservices. However, in the OML mod- To the best of our knowledge, there currently exist no eled nodes and the artifacts deployed to them always studies that investigate holistic AML adoption in MSA require technology information, which could involve design, development, and operation. Hence, we present cloud-provider-specific configuration profiles. On the work related to AMLs for MSA, thereby focusing on the other hand, CloudML ships with a definitive set of prop- modeling of heterogeneous parts of microservice archi- erties, e.g., m e m o r y for node types, to describe deploy- tectures to support holistic MDE adoption. ment. Thus, when compared to LEMMA’s OML and its Le et al. [27] present the DcSL modeling language to integration with the TML, CloudML lacks flexibility in bridge the gap between domain experts and software adding new configuration properties. Furthermore, due developers. LEMMA’s DDML (cf. Sect. 4.1) follows a sim- to LEMMA’s design as a modeling ecosystem, operation ilar notion in addressing the concerns of domain experts models in the OML can directly refer to artifact models, and microservice developers. However, DcSL focuses on i.e., microservices in LEMMA’s SML, thereby enabling UML to capture domain information in models, and nei- holistic architecture modeling that combines design, de- ther supports DDD patterns nor addresses distributed do- velopment, and operation information. main models as required in MSA engineering [1]. More- over, LEMMA’s DDML is part of an ecosystem dedicated to microservice architecture modeling, and permits do- 7. Conclusion and Future Work main concept referencing across models, e.g., to integrate the Domain Viewpoint with the Service Viewpoint (cf. This paper investigated Microservice Architecture (MSA) Sects. 4.3 and 4.4). Additionally, Le et al. do not evaluate [1] as an object of study for the research on architecture DcSL in the context of a cohesive case study (cf. Sect. 2). modeling languages (AMLs) [12] with a special focus on Terzić et al. [28] present MicroBuilder to facilitate MSA holistic AML adoption throughout MSA design, develop- engineering by MDE. The tool entails the MicroDSL lan- ment, and operation. To this end, we first presented a guage, which provides modeling concepts for data struc- case study microservice architecture (cf. Sect. 2). From tures, service endpoints, and REST APIs. MicroDSL is the case study, we derived an initial set of modeling di- evaluated by modeling the domain data and synchronous mensions [13], and identified related stages and pains [8] APIs of a web shop application. However, this evaluation in MSA engineering (cf. Sect. 3). Section 4 applied our omits the application of AMLs for the specification of Language Ecosystem for Modeling Microservice Archi- asynchronous interaction and microservice operation as, tecture (LEMMA) [15] to construct models for the case unlike LEMMA (cf. Sects. 4.4 and 4.5), MicroDSL does study’s domain data, technology choices, service APIs, not provide corresponding modeling concepts. and operation. The usage of LEMMA illustrated MSA’s MDSL [29] is a modeling language with means to de- potential to stimulate AML research w.r.t. the model- fine microservice contracts including required and pro- based organization and integration of architecture con- vided data. MDSL focuses on the expression of API cerns (cf. Sect. 5). providers and consumers with logical endpoint types. By In the future, we plan to strengthen the presented contrast, LEMMA’s SML considers microservice APIs to insights on holistic AML adoption for architecture design, constitute collections of operations, which are organized development, and operation by an empirical investigation in service-specific interfaces (cf. Sect. 4.3). Hence, MDSL of LEMMA’s applicability for MSA practitioners. Given focuses on a higher level of abstraction than our SML MSA’s current popularity, such an investigation could so that an integration of both languages seems benefi- particularly contribute to the clarification of benefits and cial. For instance, MDSL models may cluster information challenges concerning industrial AML usage. about microservice contracts in a technology-agnostic manner. These models could then be transformed to SML models, whose technology-specific extension would References allow, e.g., subsequent microservice code generation. [1] S. Newman, Building Microservices: Designing CloudML [30] is a modeling language for the deploy- Fine-Grained Systems, O’Reilly, 2015. ment of multi-cloud applications. It considers two lev- [2] T. Erl, Service-Oriented Architecture (SOA): Con- els of abstraction, i.e., the Cloud Provider-Independent cepts, Technology and Design, Prentice Hall, 2005. Model (CPIM) and the Cloud Provider-Specific Model [3] P. Di Francesco, I. Malavolta, P. Lago, Research (CPSM). The CPIM relies on generic concepts like N o d e - on architecting microservices: Trends, focus, and potential for industrial adoption, in: 2017 IEEE [16] M. Nofer, P. Gomber, O. Hinz, D. Schiereck, International Conference on Software Architecture Blockchain, Business & Information Systems Engi- (ICSA), IEEE, 2017, pp. 21–30. neering 59 (2017) 183–187. [4] I. Nadareishvili, R. Mitra, M. McLarty, M. Amund- [17] C. Richardson, Microservices Patterns, Manning sen, Microservice Architecture: Aligning Principles, Publications, 2019. Practices, and Culture, O’Reilly, 2016. [18] E. Evans, Domain-Driven Design, Addison-Wesley, [5] D. Taibi, V. Lenarduzzi, C. Pahl, Processes, moti- 2004. vations, and issues for migrating to microservices [19] F. Rademacher, S. Sachweh, A. Zündorf, Deriv- architectures: An empirical investigation, IEEE ing microservice code from underspecified domain Cloud Computing 4 (2017) 22–32. IEEE. models using DevOps-enabled modeling languages [6] J. Bogner, J. Fritzsch, S. Wagner, A. Zimmermann, and model transformations, in: 2020 46th Eu- Microservices in industry: Insights into technolo- romicro Conference on Software Engineering and gies, characteristics, and software quality, in: 2019 Advanced Applications (SEAA), IEEE, 2020, pp. IEEE International Conference on Software Ar- 229–236. chitecture Companion (ICSA-C), IEEE, 2019, pp. [20] ISO/IEC/IEEE, Systems and software engineering 187–195. — Architecture description, Standard ISO/IEC/IEEE [7] N. Dragoni, S. Giallorenzo, A. L. Lafuente, M. Maz- 42010:2011(E), 2011. zara, F. Montesi, R. Mustafin, L. Safina, Microser- [21] E. Evans, Domain-Driven Design Reference, Dog vices: Yesterday, today, and tomorrow, in: Present Ear Publishing, 2015. and Ulterior Software Engineering, Springer, 2017, [22] R. T. Fielding, Architectural Styles and the Design of pp. 195–216. Network-based Software Architectures, Ph.D. the- [8] J. Soldani, D. A. Tamburri, W.-J. V. D. Heuvel, The sis, 2000. pains and gains of microservices: A systematic grey [23] R. T. Fielding, J. F. Reschke, Hypertext Transfer literature review, Journal of Systems and Software Protocol (HTTP/1.1): Semantics and Content, RFC 146 (2018) 215–232. Elsevier. 7231, RFC Editor, 2014. [9] N. Kratzke, P.-C. Quint, Investigation of impacts on [24] O. Zimmermann, Microservices tenets, Com- network performance in the advance of a microser- puter Science - Research and Development 32 (2017) vice design, in: Cloud Computing and Services 301–310. Springer. Science, Springer, Cham, 2017, pp. 187–208. [25] M. Keeling, Design It!, Pragmatic Bookshelf, 2017. [10] D. Taibi, V. Lenarduzzi, On the definition of mi- [26] J. Sorgalla, P. Wizenty, F. Rademacher, S. Sach- croservice bad smells, IEEE Software 35 (2018) weh, A. Zündorf, Applying model-driven engineer- 56–62. IEEE. ing to stimulate the adoption of devops processes [11] A. Balalaie, A. Heydarnoori, P. Jamshidi, Migrating in small and medium-sized development organiza- to cloud-native architectures using microservices: tions (2021). a r X i v : 2 1 0 7 . 1 2 4 2 5 . An experience report, in: Advances in Service- [27] Duc Minh Le, Duc-Hanh Dang, Viet-Ha Nguyen, Oriented and Cloud Computing, Springer, Cham, Domain-driven design using meta-attributes: A 2016, pp. 201–215. DSL-based approach, in: 2016 Eighth International [12] D. D. Ruscio, I. Malavolta, H. Muccini, P. Pelliccione, Conference on Knowledge and Systems Engineer- A. Pierantonio, Developing next generation ADLs ing (KSE), IEEE, 2016, pp. 67–72. through MDE techniques, in: 2010 ACM/IEEE 32nd [28] B. Terzić, V. Dimitrieski, S. Kordić, G. Milosavlje- International Conference on Software Engineering, vić, I. Luković, Development and evaluation of Mi- volume 1, IEEE, 2010, pp. 85–94. croBuilder: a model-driven tool for the specification [13] B. Combemale, R. B. France, J.-M. Jézéquel, of REST microservice software architectures, En- B. Rumpe, J. Steel, D. Vojtisek, Engineering Model- terprise Information Systems 12 (2018) 1034–1057. ing Languages: Turning Domain Knowledge into Taylor & Francis. Tools, CRC Press, 2017. [29] S. Kapferer, O. Zimmermann, Domain-driven ser- [14] F. Rademacher, S. Sachweh, A. Zündorf, Aspect- vice design, in: Service-Oriented Computing, oriented modeling of technology heterogeneity in Springer, Cham, 2020, pp. 189–208. Microservice Architecture, in: 2019 IEEE Interna- [30] N. Ferry, A. Rossini, F. Chauvel, B. Morin, A. Sol- tional Conference on Software Architecture (ICSA), berg, Towards model-driven provisioning, deploy- IEEE, 2019, pp. 21–30. ment, monitoring, and adaptation of multi-cloud [15] F. Rademacher, J. Sorgalla, P. Wizenty, S. Sachweh, systems, in: 2013 IEEE Sixth International Confer- A. Zündorf, Graphical and textual model-driven mi- ence on Cloud Computing, IEEE, 2013, pp. 887–894. croservice development, in: Microservices: Science and Engineering, Springer, 2020, pp. 147–179.