Keywords

1 Introduction and Related Work

In the IoT era, message-oriented middleware (MOM) and machine to machine (M2M) communication play a crucial role: According to Gartner, in 2016, 6.4 billion of connected “things”, i.e. IoT devices, worldwide will be in use – a rise of 30% compared to 2015 [1]. To meet the increasing demand for high-quality communication products, substantial research and development efforts have been made leading to significant advances in the discipline of communication technologies during the last decade [2], e.g. in the area of IT-security [3], or practical methodologies [4].

A plurality of IoT relevant norms, industrial (de facto) standards, and products exist, e.g. Advanced Message Queuing Protocol (AMQP) by OASIS [5] and ISO [6], Java Messaging Service by JCP [7] (JMS is part of the Java Enterprise API), and MQ Telemetry Transport (MQTT) by OASIS [8]. The integration of heterogeneous system components using these standards and communication products is possible via a middleware layer. Nowadays, concepts and implementations of MOM are well-accepted and well-established in practice. From a technological standpoint, MOM often comprise components like message and resource broker, transaction manager, persistence service/DBMS, request scheduler etc.

But the IoT paradigm also “raises a number of new challenges in the software engineering domain” [9]. Requirements, e.g. in the form of business or domain processes, need to transformed to architectural concepts and software design specification that take IoT aspects, e.g. mobility of IoT devices, security of IoT data, or performance, into account [10, 11]. New or advanced software architectures, modeling languages, and modeling methods are helpful to take these new IoT aspects into account and reduce the complexity of the different components.

This paper addresses some of the challenges: It presents a model-based approach for developing middleware for IoT and Enterprise applications with a focus on enterprise integration patterns (EIP) [12]. Existing approaches focus on certain aspects of middleware, e.g. [13, 14], but they do not take advantage of UML, UML Profile, EIP patterns, and/or M2M transformations.

2 Development of MOM: A Model-Based Approach

2.1 Introduction to Model-Based Software Development

The general pattern for model-based development uses a PIM (platform independent model, e.g. a domain model, that is transformed into a PSM (platform specific model) if the meta-models of the PIM and the PSM are not identical (otherwise it is called a PIM-PIM transformation). The PSM serves as an input (PIM) for the next transformation(s). Transformation types are model-to-model (M2M), model-to-text (M2T), or text-to-model (T2M). Typically, the last step of a forward-engineering approach is the code-generation (model-to-text transformation), so that a PSI (platform specific implementation, i.e. code) is created (s. OMG’s Model Driven Architecture [15]). A PIM as an input or source artefact for a transformation is considered platform independent, because it conforms only to its own meta-model (language specification) and is independent from the meta-model of the output or target model (PSM). Therefore, a PIM-PSM transformation involves two meta-models (source and target MM).

As the modeling language, the GPML (general purpose modeling language) UML was chosen [16]. The UML meta-model (language specification) is MOF-conform [17] and provides a lightweight extension mechanism: A UML Profile extends UML meta-model elements by defining a set of Stereotypes so that new domain ortechnological aspects can be included in the modeling. The possibility to create a DSML (domain specific language) for MOM/IOT (heavy-weight approach) was evaluated, but at the end, the existing UML diagrams were considered sufficient.

Figure 1 gives an overview of the approach used in this paper: Domain models, like business processes (UML activity diagrams or BPMN models) and domain class diagrams are used as a starting point (PIM). A UML Profile for MOM/IoT is developed and applied. The system or software architect then prepares the models for the model-to-model transformation: Certain model elements can be marked with Stereotypes. The transformation result is a first software design model (PSM), e.g. class or component diagrams. With the EIP Profile (application of enterprise integration patterns), design models are prepared for code generation (model-to-text transformation).

Fig. 1.
figure 1

Model-based software development approach

Full size image

Different code generators for each target platform exist, e.g. Java Enterprise application, Apache Camel routes for middleware services (MOM). Generated code artefacts (PSI) are used for further manual programming.

The tool chain is based on the Eclipse modeling project [18]: Papyrus (UML Profiling and Modeling), QVTo as the Operational QVT implementation (model-to-model transformations), and Acceleo as the MOFM2T implementation (code generation).

2.2 Example PIM (Domain Model)

To exemplify the approach, an example scenario from the manufacturing domain is used: the quality control (QC) of a production material. Figure 2 shows a detail of the domain class model for the quality control (test) for a production material that usually produces a QC result dataset. A material can be tested several times.

Fig. 2.
figure 2

Example domain class model for the production material quality control (class attributes and operations are omitted)

Full size image

The process is modeled as a UML activity diagram (Fig. 3): The QC procedure is initiated by a control app that activates a transport robot. The material is delivered to the QC unit where the material quality check takes place. The result of the QC procedure is sent to the transport robot and the control app.

Fig. 3.
figure 3

Example process model for the quality control (simplified UML activity diagram)

Full size image

Data flow elements (data object, output/input PIN) in the process model can be linked with domain class elements. For example, the type specification attribute for the qc_result data flow is set to the class QCResult (Fig. 4). This model element connection is later analyzed and used for the transformation, e.g. class operations with the appropriate parameters can be generated.

Fig. 4.
figure 4

Input PIN in the activity diagram with a connection to the domain class QCResult

Full size image

This “weaving” of model elements across different model types is not only important for model transformations, but also for model validation (consistency checking). The following MOM Profile also uses this technique for the combination of behavioral and structural model elements as a preparatory step for the creation of design models.

2.3 MOM Profile Definition and Application

The MOM Profile is used for the UML activity diagrams and class models. It provides Stereotypes for mainly two different architectural components: Normal application software and MOM components. This differentiation is important for the M2M transformation. A detail of the MOM Profile is shown in Fig. 5. Process elements have a reference to the structural definition (class, package, or component).

Fig. 5.
figure 5

Detail of the MOM Profile (simplified model)

Full size image

Since partitions in an activity diagram can be interpreted as a structural element and used for M2M transformations, it seems questionable why an additional reference to an element of a structural model (class model, component diagram) is necessary. The reason is that an activity is a composite for a partition (that inherits from ActivityGroup ). Therefore, a Partition cannot be “reused” in other activities (Fig. 6).

Fig. 6.
figure 6

Detail from the UML meta-model for activity diagrams [16, p. 404]

Full size image

The application of the MOM Profile gives software architects the possibility to model architectural aspects while creating or modifying the class model: For the control app, a new package is introduced and – like the classes RobotControl and QCControl – marked with the Stereotype «App Component». The class QCOntrol is created and marked as a «MOM Component» (Fig. 7).

Fig. 7.
figure 7

Architectural class diagram with dependencies

Full size image

Also, the activity diagram is modified by applying the MOM Profile. Figure 8 shows the new partition for the MOM that acts as a message broker between the different system units, i.e. ControlApp , TransportRobot , and QCControl communicate with each other via the MOM MaterialQCService .

Fig. 8.
figure 8

Marked activity diagram with app and MOM process components

Full size image

The last step before M2M transformations can take place is the creation of references between partitions in activity diagrams and classes or packages in the class model, so that different activity diagrams (partitions) can reference the same app or MOM component (structural elements). Figure 9 depicts the creation of this connection (or weaving) with the attribute (tagged value) of the Stereotype (the partition is on the left side, the package is on the right side, and the componentRef is in the middle).

Fig. 9.
figure 9

Connection between marked partition and package

Full size image

2.4 Model-to-Model Transformation

The model-to-model transformation mapping needs to be specified before it can be implemented as an operational QVT transformation with QVTo. Rules for the mapping are formulated, e.g. a class in the source model marked with the Stereotype «App Component» will be transformed into a new controller and view class (Table 1).

Table 1. Detail of the M2M transformation mapping specification
Full size table

Mapping functions are defined in operational QVT for classes that are marked with the Stereotype «MOM Component»: A package and a class with a consumer operation are created for each MOM component (Fig. 10). The execution of M2M transformations lead to several software design models (PSM from the viewpoint of the domain model): For every component (app, MOM), a separate package is generated: App components are transformed into packages with classes for the view and controller (MVC) and MOM components are transformed to new packages with a handler for each communication channel (Fig. 8).

Fig. 10.
figure 10

QVTo transformation specification for MOM classes (detail)

Full size image

The following class model is a detail of the result of the M2M transformation (Fig. 11). This PSM represents a first version of a software design model.

Fig. 11.
figure 11

Model-to-model transformation: generated class model

Full size image

2.5 EIP Profile Application and Code Generation

The software architect can manually modify design models concerning implementation aspects. In this case, implementation-oriented design decisions for the MOM service package are demonstrated: The cyclic dependency between the package controlApp and QCControlService will be eliminated (Fig. 11) by applying the enterprise integration pattern (EIP) Publish-Subscriber-Pattern which is part of the EIP Profile for UML class diagrams (Table 2).

Table 2. Icons and Stereotypes for the EIP Profiles
Full size table

The class QCResultHandler is marked with the Stereotype «Publish-Subscribe Channel» and the controller (package controlApp ) becomes a subscriber. This leads to a unidirectional dependency of the package controlApp from the MOM service component in the package qcControlService (Fig. 12).

Fig. 12.
figure 12

Class diagram (detail) with applied “Publish-Subscriber Channel” EIP

Full size image

When the class model is ready for code generation (M2T transformation), a code generator for the app and MOM components is used: With the MOFM2T [20] implementation Acceleo, code generation templates for the PSI were developed. Figure 13 shows a detail of a template for the target platform (API) Apache Camel [21].

Fig. 13.
figure 13

Acceleo template for the code generation of Apache Camel routes (detail)

Full size image

3 Conclusion

The model-driven approach for MOM development presented in this paper is a first proof-of-concept. The method consists of the following steps:

  • Domain Modeling, e.g. creation of UML class model and activity diagram (PIM)

  • MOM Profile application for domain model elements (PIM markup)

  • Model-to-Model transformation (PIM to PSM): creation of software design models

  • Design model modification and EIP Profile application for code generation

  • Model-to-Text transformation (code generation: PSM to PSI)

The approach has proven useful, because most of the code for the MOM layer can be generated and it allows manual modifications of software design models. M2M reduces the complexity of the transformation specifications for the code generation: The UML (Profiles, activity diagrams, and class models) have been successfully used. In the future, more EIP patterns and model types will be included in the Profile.