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.
MSA emerged from Service-oriented Architecture (SOA) [2, 3] and promotes to decompose software architectures into microservices. A microservice is a service [2] that puts particular emphasis on (i) cohesion by fulfilling a single, distinct task; (ii) independence in terms of its implementation, data management, testing, deployment, and operation; and (iii) responsibility w.r.t. its interaction with other components and ownership by exactly one team [1, 4]. pected to benefit a software architecture’s (i) performance eficiency because microservices are independently scalable; (ii) maintainability by allowing targeted modification or replacement of functionality given microservices’ high cohesion and loose coupling; and (iii) reliability due to microservices’ constrained functional scope and their self-responsibility for fault handling [5, 1, 6, 7]. plexity of a software architecture because it poses significant challenges concerning architecture design, development, and operation [8]. For example, regarding design, MSA requires microservice identification and afnEvelop-O (F. Rademacher); (J. Sorgalla); (P. Wizenty); (S. Trebbau) 0000-0003-0784-9245 (F. Rademacher); 0000-0002-7532-7767 (J. Sorgalla); 0000-0002-3588-5174 (P. Wizenty) and identify modeling dimensions [13] to employ AMLs in the context of MSA. Second, we illustrate AML adoption for certain modeling dimensions of the case study using the Language Ecosystem for Modeling Microservice Architecture (LEMMA), which is a set of AMLs for MSA, that we developed in our previous work [14, 15]. With both contributions, we aim to provide insights on MSA as a driver for AML research w.r.t. holistic architecture modeling, i.e., the usage of AMLs throughout architecture design, development, and operation.
On the other hand, MSA tends to increase the com- support the specification of operation infrastructure. Our
Section 2 introduces the case study microservice architecture. Section 3 derives modeling dimensions from the case study. In Section 4, we apply LEMMA to certain modeling dimensions by using its AMLs to express various parts of the case study architecture. Section 5 discusses the resulting insights on holistic architecture modeling for MSA. Sections 6 and 7 present related work and conclude the paper, respectively.
the Park and Charge Platform (PACP), which we will use throughout the paper as a case study to illustrate and discuss holistic architecture modeling in the context of MSA. The PACP constitutes one of the deliverables of the PuLS research project1. PuLS aims to increase the accessibility of charging stations for electric vehicles by enabling citizens to ofer spare stations on private ground for use by other owners of electric vehicles. In addition, charging stations are equipped with sensors to contribute in urban air quality monitoring.
In PuLS, we design, develop, and operate the PACP to handle charging station ofering and booking, and the storage and analysis of air quality indicators. The PACP is a microservice architecture to ensure (i) scalability of the solution across city quarters; (ii) modifiability to foster innovation through quick functionality integration; and (iii) technology heterogeneity, in particular of programming languages used by project partners. Figure 1 shows the PACP’s design.
The following paragraphs describe the microservices and infrastructure components of the PACP.
vices, whose design permits runtime replication of service instances. In detail, the services provide the architecture with the following capabilities:
Digital Infrastructure (grant number 03EMF0203C). • 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 : Manages charging station information like location, charging type, and plug type, and receives data from charging stations. • 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 functionality for citizens to ofer spare charging stations on private ground for use by others under certain 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 implements functionality to search for spare charging stations. • 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 purpose, the service maintains a Blockchain [16] to prevent manipulation during booking, and subsequent charging and billing processes. • 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 handling of air quality indicators, e.g., CO2 pollution, temperature, and humidity, and therefore interacts with a municipal Environment Monitoring System.
The listed PACP microservices constitute logical microservices in the sense of the Command Query Responsibility Segregation (CQRS) pattern [17]. CQRS decomposes a microservice into a command part and query parts. The command part handles incoming requests that result in state changes, e.g., database updates, and the query parts execute state queries, e.g., database reads. To this end, the command part sends state changes to query parts, which then incorporate the changes into their data models. For the PACP, the usage of CQRS has two benefits. First, query operations are much more frequent than write operations, and CQRS permits separate scaling of command and query parts because we realize them as physically segregated microservices. Second, we can optimize storage for query operations and thus, e.g., enable time series processing of sensor data.
Infrastructure Components Figure 1 considers two kinds of infrastructure components.
Service-oriented infrastructure components provide a single microservice with capabilities like API provisioning (A P I G a t e w a y ), discovery of other PACP microservices (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 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 ). Furthermore, the PACP secures accesses via the I d e n t i t y a n d A c c e s s M a n a g e m e n t (IAM) component, which realizes user management, authentication, and authorization of microservices’ command and query functionalities.
On the other hand, PACP microservices interact with each other by sending asynchronous events to the centralized M e s s a g e B r o k e r component (cf. Fig. 1). Following the Domain Event pattern [17], we conceive exchanged events domain events that belong to the portion of the application domain for which a microservice is responsible. To this end, the message broker integrates an event schema registry and behaves as an event store. The registry allows centralized management of event structures and their sharing across project partners, whereas the event store permits access to events in their order of appearance and thus auditing, e.g., of charging station booking processes.
we identify initial modeling dimensions according to Combemale et al. [13] and with relevance to MSA. We consider AMLs central means to construct models for these dimensions and later enable their processing. Table 1 lists the identified modeling dimensions together with the related stage and pains [8] in MSA engineering.
The following paragraphs summarize per stage the rationale for each dimension. vices’ domain models using Domain-driven Design (DDD) [18, 1]. DDD is a model-based methodology, which we used in the PACP’s design to capture the structures and relationships of the relevant concepts from the application domain.
Moreover, models are a means to communicate and document, e.g., domain concepts or service contracts, across teams (D.2 and D.6). In MSA, eficient communication and a common architectural understanding is crucial since teams and their communication should be decomposed along service boundaries [4]. For the PACP, we rely on LEMMA models and derived artifacts to share microservice APIs and event schemas across teams (cf. Sect. 4).
Next to domain concept definition, models can be constructed in MSA engineering, e.g., to specify APIs and their versions, or reason about communication heterogeneity (D.3).
Development Stage Code generators may support the development of microservices (D.4) by producing boilerplate code from models [13, 19]. We use this approach for the PACP to reduce manual overhead and human errors in recurring coding tasks like connecting a service to the message broker (cf. Fig. 1). Furthermore, it enables us to keep the model-based architecture design consistent with the implementation of microservices’ domain data, APIs, and deployment specifications (cf. Sect. 4). In addition, it is possible to run early integration tests with the generated code or manually extend it, e.g., for subsequent performance testing (D.5).
oration with domain experts using DDD. Line 1 defines 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 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 conaim 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 exof 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 inon 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 modcan 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 enumerData 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.
1 context ChargingStationManagement { 2 structure ElectrifiedParkingSpace<entity, aggregate> { 3 string id<identifier>, 4 string name, 5 string plugType, 6 ChargingType chargingType<part>, 7 ParkingSpaceSize parkingSpaceSize<part>, 8 ... 9 } 10 enum ChargingType{ 11 FAST, 12 NORMAL 13 } 14 structure ElectrifiedParkingSpaceCreated<valueObject, 15 domainEvent> { 16 immutable string name, 17 ... 18 }}
coping with MSA’s technology heterogeneity [1]. For this purpose, the viewpoint comprises the Technology Modeling Language (TML) [14]. It covers modeling dimensions D.4 and D.5 in the Development stage of MSA engineering (cf. Table 1) by enabling the construction of technology models. These models can capture a variety of MSA-related technology information concerning, e.g., microservice programming languages, communication protocols, and operation technologies. However, it also allows the definition of arbitrary metadata using technology aspects [14]. Such aspects may augment elements in other LEMMA models with additional semantics regarding, 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 LEMMA’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 techrespectively. 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 inListing 2: Excerpt of the technology model for the Spring volved in the realization of a design or architecture patframework 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 protocols { 3 sync rest data formats ”application/json” 4 default with format ”application/json”; 5 } 6 service aspects { 7 aspect PutMapping<singleval> for operations { 8 selector(protocol = rest); 9 } 10 ... 11 }} Listing 3: Excerpt of the technology model for the CQRS pattern in LEMMA’s TML (file “Cqrs.technology”). technology CQRS { service aspects { aspect CommandSide for microservices { string logicalService; } aspect QuerySide for microservices { string logicalService;
Line 1 introduces the S p r i n g technology. Next, the p r o - } t o c o l s section in Lines 2 to 5 specifies the synchronous ... r e s t protocol, which represents REST-based interaction }} [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 adopdefault 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 scemous Spring annotation5. LEMMA distinguishes between service-related and operation-related technology (ncaf.riLoi.nBeost4haansdpe7c).tsItdceacnlasrteortheethleo gniacma leSoefrtvhiec elopgriocaplemrtyiaspects [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 target elements of modeled operation nodes (cf. Sect. 4.5). moTdheel aC nomamlyaznedrSsi dweitahnda rQeuleiarbySlei dme eaasnpsectotsrpecroovgindiez,eet.hge.,
Furthermore, LEMMA allows constraining aspects’ ap- command and query services of a logical CQRS microserplicability 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
4https://www.json.org 5https://docs.spring.io/spring-framework/docs/current/ javadoc-api/org/springframework/web/bind/annotation/ PutMapping.html LEMMA defines the Service Viewpoint for developer concerns in microservice implementation [15]. The viewpoint specifies the Service Modeling Language (SML) for 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. LEMplicit service contracts [24], and thus covers modeling MA provides modifiers to constrain a microservice’s visdimensions 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 chargLEMMA’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 infrasmand 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 23 i@tmpeocrhtnotleocghy(nSoplroignygf)rom ”Spring.technology” as Spring specifications that constitute combinations of a technol4 @Spring::_aspects.Application( ogy-specific protocol like the r e s t protocol from the im56 npaomret==8”C0h7a1rgingStationManagementCommand”, 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”. 89 pdubel.fihcdfo.upnucltsi.oCnhaalrgmiincgrSotsaetrivoincMeanagementCommand { 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 1112 )Spring::_protocols.rest: ”/resources/v1”; invoke the operation to trigger the creation of electri13 interface Commands { ifed parking spaces managed by the C S M M (cf. Sect. 4.1). 1145 @Senpdrpionig:nt:_sp(rotocols.rest: ”/electrifiedParkingSpace”; Lines 14 to 17 determine the URI segment and HTTP re16 ) quest method [23] for the REST-based invocation of the 1178 @pSupbrliincgc:r:e_aatsepEelcetcst.rPiuftiMeadpPpairnkgingSpace( operation. While the URI segment is again configured 19 @Spring::_aspects.RequestBody as an endpoint address for the imported r e s t protocol, 2210 sCyrnecatienElceocmtmrainfdie:dDPaormkaiinng:S:pCahcaerCgoimnmgaSntda)t;ionManagement. 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 2234 }... 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 diferent 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 comements (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 Microservice Interaction Sect. 4.2, technology model imports integrate LEMMA’s Technology Viewpoint with the Service Viewpoint so As described in Sect. 2, PACP microservices interact asynthat modeled microservices can be augmented with in- chronously using a message broker and events. We deformation that reflect technology choices. cided for Kafka 8 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
html/application-properties.html
javadoc-api/org/springframework/web/bind/annotation/ RequestBody.html 8https://kafka.apache.org
tion and receipt by service operations; and (ii) augmentation of model elements with broker and pattern information from technology models (cf. Sect. 4.2). Listing 5 shows an extended version of the service model for the C S M M ’s command microservice (cf. Listing 4) with elements for asynchronous event sending.
1 ... 2 import technology from ”Kafka.technology” as Kafka 3 import technology from ”Cqrs.technology” as CQRS 4 ... 5 @technology(Kafka) 6 @technology(CQRS) 7 @endpoints(Kafka::_protocols.kafka: ”kafka-server1:9092”;) 8 @CQRS::_aspects.CommandSide(”ChargingStationManagement”) 9 functional microservice 10 de.fhdo.puls.ChargingStationManagementCommand { 11 ... 12 interface Commands { 13 ... 14 @Kafka::_aspects.Participant( 15 topic=”parkingSpaceCreatedEvents” 16 ) 17 sendParkingSpaceCreatedEvent( 18 async out event : Domain::ChargingStationManagement 19 .ElectrifiedParkingSpaceCreated); 20 }}
Lines 2 and 3 add imports for the Kafka technology model9 and the CQRS technology model (cf. Listing 3), respectively. Next, Lines 5 and 6 apply both models to the command microservice. Consequently, we can conifgure an endpoint for the k a f k a protocol from the K a f k a technology model to specify the location of the Kafka broker (cf. Line 7). Moreover, we apply the C o m m a n d S i d e aspect from the C Q R S technology model to the microservice (cf. Line 8) so that it is semantically recognizable as the physical command microservice of the logical “ChargingStationManagement” microservice (cf. Sect. 4.2).
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 E v e n t operation for sending Kafka events after the creation of newly managed electrified parking spaces. To this end, the P a r t i c i p a n t aspect configures the event’s topic. In addition, the operation specifies the asynchronous outgoing parameter e v e n t [15], which is typed by 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 the imported C S M M domain model (cf. Listing 1).
In the following, we accompany the domain and service 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 Operation Viewpoint [15]. The viewpoint specifies the Operation Modeling Language (OML), which covers the
master/technology/Kafka.technology operation-related modeling dimension D.4 (cf. Table 1) and makes the operation infrastructure of a microservice architecture explicit. Listing 6 shows an excerpt of the operation model for the C S M M ’s command microservice. Listing 6: Excerpt of the operation model for the C S M M ’s command microservice in the OML (file “chargingStationManagement.operation”). import microservices from ”chargingStationManagement.services” as Services import technology from ”container_base.technology” as ContainerBase import nodes from ”eureka.operation” as ServiceDiscovery import nodes from ”keycloak.operation” as IAM import nodes from ”mongodb.operation” as Database @technology(ContainerBase) container CommandContainer deployment technology ContainerBase::_deployment.Kubernetes with operation environment ”openjdk:11-jdk-slim” deploys Services::de.fhdo.puls.
ChargingStationManagementCommand depends on nodes ServiceDiscovery::Eureka, Database::MongoDB, IAM::Keycloak { default values { eurekaUri=”http://discovery-service:8761/eureka” ... } }
command microservice (cf. Listing 4) and a technology model for container technology10. Lines 5 to 7 import three other LEMMA operation models that specify the PACP’s service discovery and IAM component as well as the database of the C S M M ’s command microservice (cf.
Sect. 2). LEMMA supports the decomposition of operation models to separate definitions of centralized infrastructure components, e.g., service discoveries, from those of microservice-specific components, e.g., containers.
Lines 8 to 20 model the C o m m a n d C o n t a i n e r to deploy the C S M M ’s command microservice. For this purpose, the container applies the imported C o n t a i n e r B a s e technology model and leverages the provided K u b e r n e t e s deployment technology11 with a Java image for its execution (cf. Lines 10 and 11). LEMMA’s support for containerbased deployment also determines microservices’ technical replicability [4]. More precisely, modeled microservices (cf. Sect. 4.3) act as templates for runtime service instances, whose replicability characteristics are to be determined by modeled containers.
Lines 12 and 13 specify that the modeled container deploys the imported C S M M command microservice.
Lines 14 and 15 configure the container to depend on the PACP’s Eureka-based service discovery12 and Keycloak-based IAM provider13 as well as the MongoDB database technology14 for document-oriented storage of
10https://www.github.com/SeelabFhdo/mde4sa-2021/blob/ master/technology/container_base.technology 11https://www.kubernetes.io 12https://www.github.com/Netflix/eureka 13https://www.keycloak.org 14https://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 techof LEMMA’s OML [15] in Lines 16 to 19 to determine nology heterogeneity [1] and facilitates the reconstrucvalues for technology-specific configuration options that tion of technology information from microservice imaccount 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 5. Discussion sneaamrcehPcuotufitlsdbsetuttdeyr ttoratdhee-oifsntbeentdweedensesme manatnictisc.-oArMienLtreedThis section provides insights on MSA as a driver for AML and technology-oriented modeling, e.g., by comparing research w.r.t. holistic architecture modeling. Therefore, the efectiveness of flexible AMLs like those of LEMMA we discuss experiences from adopting LEMMA’s AMLs with modeling languages that integrate keywords for to the PACP (cf. Sects. 2 and 4) in the diferent stages of MSA patterns or technologies (cf. Sect. 6). MSA engineering (cf. Sect. 3). Behavior modeling is another area for MSA-inspired AML research. Currently, none of LEMMA’s AMLs supports behavior modeling w.r.t. service logic or data ex5.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 landoes not provide means to express domain-driven ser- guages, e.g., UML sequence diagrams, to MSA engineervice 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 synbetween domain experts and developers. For instance, chronous service interactions, we support the transforstrategic DDD relies on graphical context maps [18], while mation/derivation of LEMMA models to/from OpenAPI Event Storming combines a textual notation with box- specifications 15. 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 efectiveness of these ap- specifications 16. While this approach is suficient 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 diferent 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 opartifacts 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 specition. To this end, LEMMA allows, e.g., model decomposi- ifcation 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 conand 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
AMLs [13]. LEMMA enables technology-agnostic modeling in the DDML and SML (cf. Sects. 4.1, 4.3, and 4.4), and 15https://www.openapis.org 16https://avro.apache.org 17https://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 ifguration 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 modeled nodes and the artifacts deployed to them always require technology information, which could involve cloud-provider-specific configuration profiles. On the other hand, CloudML ships with a definitive set of properties, e.g., m e m o r y for node types, to describe deployment. Thus, when compared to LEMMA’s OML and its integration with the TML, CloudML lacks flexibility in adding new configuration properties. Furthermore, due to LEMMA’s design as a modeling ecosystem, operation models in the OML can directly refer to artifact models, i.e., microservices in LEMMA’s SML, thereby enabling holistic architecture modeling that combines design, development, and operation information.
studies that investigate holistic AML adoption in MSA design, development, and operation. Hence, we present work related to AMLs for MSA, thereby focusing on the modeling of heterogeneous parts of microservice architectures to support holistic MDE adoption.
Le et al. [27] present the DcSL modeling language to bridge the gap between domain experts and software developers. LEMMA’s DDML (cf. Sect. 4.1) follows a similar notion in addressing the concerns of domain experts and microservice developers. However, DcSL focuses on UML to capture domain information in models, and neither supports DDD patterns nor addresses distributed domain models as required in MSA engineering [1]. Moreover, 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, developengineering 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 dievaluated 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 Archiasynchronous 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 modelifne microservice contracts including required and pro- based organization and integration of architecture convided 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.
CloudML [30] is a modeling language for the deployment of multi-cloud applications. It considers two levels of abstraction, i.e., the Cloud Provider-Independent Model (CPIM) and the Cloud Provider-Specific Model (CPSM). The CPIM relies on generic concepts like N o d e [1] S. Newman, Building Microservices: Designing
Fine-Grained Systems, O’Reilly, 2015. [2] T. Erl, Service-Oriented Architecture (SOA): Con
cepts, Technology and Design, Prentice Hall, 2005. [3] P. Di Francesco, I. Malavolta, P. Lago, Research 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, Derivarchitectures: 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 EuMicroservices 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, Comnetwork 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. Sachcroservice bad smells, IEEE Software 35 (2018) weh, A. Zündorf, Applying model-driven engineer56–62. IEEE. ing to stimulate the adoption of devops processes [11] A. Balalaie, A. Heydarnoori, P. Jamshidi, Migrating in small and medium-sized development organizato 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 EngineerA. 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. MilosavljeInternational Conference on Software Engineering, vić, I. Luković, Development and evaluation of Mivolume 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, EnB. 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. Soltional Conference on Software Architecture (ICSA), berg, Towards model-driven provisioning, deployIEEE, 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 ConferA. 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.