12.1 Introduction

Interconnectivity and ubiquitous computing are key components in the forthcoming age of digitalization. To support this, and to flexibly keep up with newly arising requirements, software is continuously moving from comprehensive desktop applications to smaller services that interconnect with other services and exploit user data to provide added-value experiences. This shift raises concerns for service users and service developers. For service developers, such a change in design and architecture requires engineering of scalable systems that can be developed and maintained independently. This is reflected in the microservices paradigm currently used within many software projects. In microservice architectures, the individual services contribute small parts of domain functionality. The backbone of such microservice architectures is built up from independently functioning base services providing different platform functionality. Such architectures supply millions of users with services. To scale, cloud computing techniques are used providing the necessary scalability and elasticity. The resulting architectures can compose different services to added-value services based on large sets of user data. For service users, employing added-value services requires provision of personal data to many different, yet partially interconnected services. Each of these may store copies of the data and share this with the services they use. This requires the user to abandon control of their data as well as consistently changing their data throughout various services.

In this chapter we discuss a system-of-systems architecture that centers services around the user as opposed to provider-driven services. For creating such architecture, we support the developer with a model-driven and generative methodology supporting reuse of existing services, automated conversion between different data models, and integration of ecosystems facilitating service composition, user data access control, and user data management. To this end, we motivate the need for flexibly composable cloud services by example (Section 12.2), before we identify challenges for such architectures (Section 12.3). Afterwards, we introduce preliminaries (Section 12.4), present our conceptual building blocks for a system-of-systems architecture (Section 12.5), and explain how code generation can facilitate development of composed added-value services (Section 12.6). The subsequent sections discuss related work (Section 12.7) and our approach (Section 12.8). Finally, we conclude this contribution (Section 12.9).

12.2 Example

This section gives an example scenario to demonstrate the supported forms of use cases. The overall scenario is a person who wants to simplify everyday life processes in order to improve work-life balance. To achieve this, the person already uses several specialized apps on her smartphone. Fig. 12.1 shows systems participating in this scenario. All actions are initiated by the person using her smartphone. In general the person is in good health but likes to participate in several preventive checkups that are recommended by her health insurance. As these preventive checkups often have irregular or long time intervals, her health insurance has a monolithic app where recommendations for checkups are conveniently published. This app uses the Health Insurance Service denoted in Fig. 12.1. She regularly uses this app to inform herself about upcoming preventive checkups. If an examination by her doctor is indicated by the health insurance app, she negotiates an appointment with the doctor. The doctor also has a standalone app to make appointments online. The corresponding service is the Doctor Service in Fig. 12.1. Additionally to the preventive checkup service, the health insurance company also offers a bonus program to reward health supporting behavior of its customers. Our person lives in a larger city and therefore she needs to plan carefully how to get to the doctor's office just in time for her appointment. She can choose from different available mobility offerings performed by the local public transportation company, the new car sharing company that implements a taxi service with autonomous cars or just use her own car. Depending on time and personal preferences she favors one service over the others. As denoted in Fig. 12.1 each, the autonomous taxi and the public transportation company, offer a dedicated service, which is available through a standalone app, to let customers check availability and book trips. Unlike buses, autonomous taxies don't need to stick to a predefined route, and the autonomous taxi internally uses a routing planer for the optimal driveway. The Route Planner has an integrated map annotated with additional information like special streets only available for certain types of vehicles. To overcome high exhaust fumes' concentrations in big cities, bus lanes may also become available for autonomous taxies, or streets may be closed for vehicles exceeding a certain size. Including this, route planning becomes much more dynamic due to high flexibility of available streets. The Traffic Analyzer internally uses several data sources to calculate utilization of all streets.

This data is then extended to a utilization forecast. As a result, the Traffic Analyzer Service is able to provide detailed information about expected time adjustments for routes. In combination with the Route Planner, the Traffic Analyzer Service can be used for a better route selection and estimate the required time for a route. These two services are used in the background by the mobility apps, and our person doesn't come directly in touch with them.

Several apps available on the smartphone, bringing vital services to the users, have to be used separately. Common data must be manually shared between apps, and personal preferences are only collected specifically for each app's use cases. The person from the previously described scenario uses apps where available. In everyday life a combination of different apps and services is often desired. The composition is done manually using the smartphone. Different apps are used in specific order, and data, like personal data or results from previous service calls, is transferred from one app to another. Necessary steps in terms of data transformation and service composition are shown in Fig. 12.2 and described in the following paragraph. Each swimlane in the activity diagram in Fig. 12.2 corresponds to the respective service from Fig. 12.1.

Upcoming preventive checkup recommendations are received through the health insurance app. The person must read the information and decide if this checkup is applicable to her. If this is the case, the app connected to her doctor is used to start an appointment negotiation. In order to be able to use this app, she had to give her personal contact information to the app provider. Even worse she must put a list of her doctors at the app's disposal. This allows her to contact the doctors via the app.

To start an appointment negotiation, she must manually transfer the information from the health insurance app, check general availability in her calendar, and send the appointment request. Attached to that, she has to transfer her personal (timing) preferences into the appointment request because the app only supports appointment preferences in terms of weekdays or availability in the morning, midday or afternoon. The doctor receives this request for an appointment and can check which open slots he can offer. Our person checks if a slot fits well into her time schedule and confirms that slot if applicable. Otherwise she answers with slightly adjusted preferences maybe aiming at appointments a bit more in the future. This is repeated until a suitable slot is found and confirmed. If a suitable slot for an appointment is found, the doctor sends the appointment details to her. The appointment is then displayed in the app and the time information has to be transferred into a calendar item in her calendar app. In doing so, three subsequent steps are initialized. First, the doctor receives a confirmation which appointment was ultimately chosen, which may trigger necessary preparations for the doctor's staff. Second, the health insurance app is used to gather detailed information about available vouchers in the bonus program. Third, our person has to look how to reach the doctor's office. Several providers, like local public transportation or an autonomous taxi service, are present, and each one has a dedicated app available to inform about service details. As our person wants to compare service offerings, she has to use each app but this must be done separately. The apps need information like date and time, home- and doctor's address, and personal preferences. They are very similar for each app but have to be manually entered again. Each app presents a list of mobility offers matching her request. By manually switching between the apps, she can choose the offer most suited for her. As the health insurance app already indicated that the upcoming examination is covered by the bonus program, she does not only need to compare different offers of the mobility services, or consider which offers are eligible for the voucher. As the last option she could also user her own car. Finally, she has to book the chosen offer which includes that she has to enter her personal payment information and submit it to the service provider behind the app. Again, her personal data is spread into another system, and no integrated mechanisms allow her to keep track which data she entered where.

As shown and described in Fig. 12.2, apps on smartphones are already supporting everyday life. However, many apps lack interconnections, so that identical information must be manually transferred from app to app.

12.3 Challenges

Our notion of services follows the W3C, for which “[a] service is an abstract resource that represents a capability of performing tasks that form a coherent functionality from the point of view of providers entities and requesters entities” (https://www.w3.org/TR/ws-gloss/). This entails that a service fulfills a single (coherent) functionality, it is used by requesters, and it may use different providers. Requesters and providers may be persons or other services (i.e., services are meant to be composable). Additionally, services yield a description detailing the interfaces and the semantics of the service. The interfaces define the possible interaction in terms of messages or data types consumed and produced by the service whereas the semantics of the service describes the functionality of the service and the effect of using the service. A single service is a standalone system that relies on other services to fulfill its functionality. This allows for detached development of such a service.

12.4 Preliminaries

Large distributed systems, such as the Internet-of-Things, consist of heterogeneous, interacting, software modules that capture various domain expertise. Engineers developing services for such systems must cope with the complexity of integrating solutions formulated by respective domain experts in different general programming languages (GPLs). Integration of these solutions requires comprehension of multiple GPLs, their libraries and communication mechanisms, although these express similar concepts (such as the data types to exchange or the interfaces of services). This lack of conceptual abstraction ultimately increases engineering efforts [18].

Model-driven engineering (MDE) [24,56] is a software development paradigm that lifts abstract models to primary development artifacts. Such models can be domain-specific, focus on important concepts, and avoid the notational noise [58] of GPLs. To this effect, possible models for specific concerns are characterized by domain-specific languages (DSLs), which, for instance, capture concepts of data structures (UML class diagrams [41]), software architectures [35,36], or system behavior [1,54]. In MDE, models are used for communication, documentation, analysis, and ultimately execution. For the latter, models are either interpreted at run-time [2,18] or translated into GPL artifacts using code generators embodying software engineering expertise [10]. As such models further can be independent of GPL details, they are available for translation into different GPLs and enable us to reuse domain expertise with different programming languages, ecosystems, and services [46]. Multiple domains, including automotive [2,26], avionics [17], robotics [6,45] have employed MDE with various success [34,57].

A prominent kind of DSLs for the description of hierarchical software architectures are architecture description languages (ADLs) [34,35]. One of these languages is the MontiArc [29] component & connector (C&C) ADL, which provides concepts for atomic components and composed components, component interfaces of typed, directed ports, and connectors between these interfaces to architecture developers. Components are black boxes that compute behavior: Atomic components either encapsulate models of other DSLs to describe their behavior or are linked to GPL artifacts [47]. Composed components contain a hierarchy of subcomponents and their behavior emerges from the interaction of their subcomponents. These subcomponents can be atomic or composed again, allowing for architectures of arbitrary complexity with direct access to specific functionality where required. The components exchange messages via their typed ports, which rely on UML/P class diagrams [48] to describe the messages' structures. The encapsulation of components and the flexibility of class diagrams enable for a detached and agile [49] development of components and facilitate a post-deployment integration. With these, service developers can engineer services as components that provide and require services via their stable interfaces of typed ports reuse other services via hierarchical composition. Consequently, cloud-based distributed systems have adopted ADLs for description of services in form of software components as well [11,23,40]. These ADLs feature modeling concepts specific to cloud-based architectures, such as replicating components of message contexts for stateless systems. However, important challenges, such as data migration and privacy-control have yet to be addressed in such systems-of-systems.

Fig. 12.3 depicts a C&C architecture that describes a public transportation service at its top and the related data structures at its bottom. The service enables users to calculate transportation plans based on starting location and destination and considers the user's personal preferences to optimize route calculation. The added-value service Public-TransportationService is composed from three other services. Two of these are specific to the public transportation service, the third (TrafficAnalyzerService) is incorporated from another service provider. This form of tight coupling via integration hides the public transport service's dependency from the traffic prediction service encapsulation ensures it appears as a single, reusable service to potential users. The service also interacts with a banking service and a persistency service (both supplied by different service provides as well) via their public interfaces of typed ports. This loose coupling enables service developers to reuse other services without changing the configuration of their services. The PersistencyService employs the replicating subcomponent Persistence, which replicates itself whenever necessary.

12.5 System-of-Systems Approach

As stated before, modern cloud-computing architectures are made up of several services [33]. These services are composed from other fundamental services to added-value service, relying on personal data. The overall service landscape of such a cloud-computing is huge and quite heterogeneous. The necessary service compositions are manually implemented and specific to the desired service combination. For alleviating the manual composition of services the different integration and communication challenges, as described have to be tackled.

For this we follow the typical distinction of Infrastructure-as-a-Service (IaaS), Platform-as-a-Service (PaaS), and Service-as-a-Service (SaaS) [59]. Within this contribution we do not consider IaaS and assume that there is always sufficient infrastructure available that can be used on demand in order to be elastic. For the distinction between PaaS and SaaS, we consider PaaS as the layer containing common services used for developing services of the SaaS layer. The SaaS Services are used by persons and typically have some sort of GUI whereas the PaaS services are used by those services in order to ease development [59]. Service provider want to offer high quality functionality, thus the services within our architecture have to be elastic regarding high workloads and responsive to provide such a quality. Furthermore, it should be developed with minimal costs. These requirements pose additional requirements to the service developer. The developer needs to increase reuse of developed services since it is not feasible to reimplement every bit of the desired functionality and the parts that have to be implemented must be easily implementable.

We consider persistency, privacy, service lookup and data transformation services as available platform services. These services can be replicated on demand but are, just like other services, developed in a standalone manner. We start out with the introduction of the Persistence service utilized by our architecture, followed by Data Conversion-, Privacy-, and Personal Data service.

12.5.1 Persistence Service

The Persistence service, as shown in Fig. 12.4, offers the functionality to store data. Most applications and services need to be able to store data in order to be able to make it available again to other users or services. In general object oriented or relational databases [31] and NoSQL databases, such as Apache Cassandra and MongoDB [50] can be distinguished. Each paradigm has its benefits and drawbacks. Relational databases, such as Oracle or PostgreSQL, are especially suited to store structured data. Most of those relational databases are able to fulfill the ACID principles [27] and can therefore ensure consistency. On the downside they may not keep up with processing a huge amount of data. Relational databases organize data in tables with different columns. Each entry of a table is represented as a row. Each data field of a data entry becomes an entry of a column in the corresponding row. Different types of data entries are stored in different tables and merged via join operations. In contrast, NoSQL databases are well suited to process large amounts of data by relaxing the CAP-theorem [8] in terms of not ensuring consistency. Thus, they are the de facto standard supporting digitalization where big data approaches become even more important. They basically provide key value storage functionality and do not support relational structures. On the downside, joins between data are costly.

Nevertheless, both approaches are not mutually exclusive. Moreover, a hybrid approach is necessary that selects the best approach for a certain type of data. This may also lead to splitting up a data model into a structured and a volume part.

The Persistence service consists of the Persistence component that contains several subcomponents, as shown in Fig. 12.4. As stated before we envision a description of a service interface in order to compose them. This description can be sent once to the persistence component where it is used as input for the ServicePersistenceGenerator. This generator generates service specific components and ports within the Persistence component. Thus, each service has an incoming and an outgoing port in order to store or retrieve data. Via the incoming port an Operation is sent. This Operation has a Type that specifies the CRUD type of the operation. Additionally, it has a service specific Payload containing the data. The service specific component ServiceAPersistence receives the Operation and transforms the specific payload into a CommonPayload. This CommonPayload is passed on to the DistributionLogic component. The DistributionLogic component decides which database to use based on the incoming payload. The DistributionLogic communicates this decision to the IaaSStorageConnector that directly communicates with a database. In Fig. 12.4 three service ports are given as an example. The RDBS service port is able to store data in a relational database, and the NoSQL service port is able store data in a NoSQL database. For reading data, an Operation with Type read is sent to the Persistence component. The data is loaded into a service independent result from the database and transformed into a service specific result in the ServiceAComponent.

The Persistence service consists of service specific parts and parts necessary for fulfilling the functionality. The latter parts can be implemented once whereas the service specific parts are generated out of an abstract description of a service using the Persistence service. It should be noted that there is not one single Persistence service but several instantiations. For realizing the Digital Me, the Persistence service is necessary since it enables storing the data transparently from the location. Especially since the PersonalData service can instantiate its own Persistence service that stores data in a trusted location.

12.5.2 DataConversion Service

The DataConversion service, as shown in Fig. 12.5, transforms data from one data model to another. This is needed since data models typically do not match. For this the DataConversion service follows the same idea as the Persistence service that was shown in Fig. 12.4. It also uses the common interface description of a using service that can be uploaded to the DataConversion component. The description is delegated to the DatamodelManagement subcomponent that contains two different generator components: the TransformationGenerator and the AdapterGenerator. Both generator components produce parts of the service specific components contained in the DataConversion component. Such service components, i.e., ServiceATransformation and ServiceBTransformation, are located within the DataConversion component. This transformation is able to transform the service specific data model into a generic metamodel. The metamodel itself consists of a Root that contains several Components. The components are designed with a composite pattern. Thus, it has a subclass Directory that can contain multiple components and a subclass Entry that may have a Value. Each Entry has a name, each Value a name and a value. This metamodel is based on the Internet-of-Things data model [30]. The metamodel allows storing heterogeneous kinds of data by using the datatype as the Entry name and each field as a Value. This transformation from and to a metamodel is part of the generated functionality of the service specific components. They make use of the transformation into the metamodel for transforming from and to the different service data models. This is transparent to other services. Other services are able to simply use the service once they have uploaded their interface description. Thus, they can exchange data between different services. This exchange is possible since we use a generative approach, which is presented in the next section. That generative approach connects to services via the DataConversion component by interrupting the data flow with a connection from the incoming port of one service to the outgoing port of the other service. The DataConversion service that is shown in Fig. 12.5 may use the Persistence service in order to store the data of different services in a metamodel data format. The concept of transforming into the metamodel as well as the generation of such transformations has been applied in the COOPERATE research project and has been presented in [21]. It should be noted that the DataConversion service itself is stateless and may therefore have multiple instances and even its own instance of a persistence service.

Within the cloud-architecture we use the DataConversion component to interconnect different services supporting the Digital Me in composing services as needed.

12.5.3 Privacy Service

The PrivacyService component depicted in Fig. 12.6 enables connected components to exchange data without the need to expose confidential personal data, like contact addresses. The core functionality is based on the ServiceADataDelivery component. An external component, like ServiceB, connects to the ServiceADataDelivery component port and on the other side the concrete ServiceA is connected. ServiceA has registered at the TokenRegistry and a Token is created. ServiceB uses this Token to establish a connection to ServiceA. Using this indirection in communication between components, components like ServiceA do not have to expose their personal long term contact details to foreign components. This supports the Digital Me by allowing communication by distributing tokens. These tokens could be made publicly available in order to retrieve offers from other services. Unlike the permanent contact address tokens can be easily revoked and such prevent further communication with this token. Additionally, the tokens can have attached limitations, like an expiration date, or the token can only be used by a certain components. Limitations are defined in the TokenRequest and are then connected to the resulting Token. For each component, a DataDelivery component can be generated by the DataDeliveryGenerator component.

12.5.5 PersonalData Service

Fig. 12.7 shows the PersonalData service. This service uses the previously introduced DataConversion and Persistence services. The PersonalData service is the implementation of the Digital Me as digital representation of a user within the cloud-architecture. The service itself can be instantiated locally, e.g., on the user's phone or remote in a trusted location. Within this paper we assume that the personal data service and especially the Persistence service used by the PersonalData service run on the user's phone. It should be noted that the previously explained services are instantiated multiply. Thus, there is not one single persistence service but several, as stated before. Services querying personal data may use this service. Thus, they post a read Operation to the PersonalData component. This Operation is delegated to the data conversion where it is transformed into the data format of the personal data. The data is loaded from the respective databases transformed back and handed back to the service as a Result.

Overall the fundamental PaaS services of the presented cloud-architecture provide a set of typically used functionality. A service that wants to use other services by composition can connect to those services via the DataConversion service which transforms the data adequately in order to communicate between the different services. If the services want to use personal data of a specific user, they can find the PersonalData service via the LookUp service. Within the PersonalData service the querying service is authenticated and authorized by the Security service. The data is loaded by the Persistence service. On its way back to the querying service the loaded data is transformed into the services data format and anonymized before it is returned. By this the service user can easily reuse the existing services and compose new services.

12.6 Generative Approach

The services, as described in Section 12.5, only provide basic functionality such as persistence and lookup, each of which is developed by a different service provider. In order to develop a new service for the scenario described in Section 12.2, such basic services have to be composed. However, there are two major issues that have to be tackled when developing a new service: specification of exchanged data and service composition.

Assuming the higher-level service to negotiate an appointment for a person with a doctor, the mobility service is to be developed, as shown in Fig. 12.8. The first step is to define the data that is exchanged by the involved parties. In a privacy-aware environment, users specify what information is exchanged. For example, Fig. 12.1 shows the usage scenario and what information is allowed to be exchanged. First, the doctor is allowed to use a person's address (TAddress) and negotiate appointments (Appointment). Second, a person is allowed to access the doctor's address (DAddress) but not his appointments. Third, the mobility service is allowed to use a person's address, the doctor's address, and the date of the appointment. Finally, the health insurance may access the appointment date (AppointmentDate). Such specification of the exchanged data is the foundation for the service developer to develop a new higher-level service.

The next step is the design of the architecture of the overall service by the service developer. One possible description of this new service is shown in Fig. 12.8. It is described using the MontiArc ADL. Such an abstract description can manually be realized by implementing the necessary functionality using the basic services. However, when manually implementing such a new service, the service developer has to write glue code for service composition and afterwards adapt services if required. Existing service composition approaches help in realizing such an implementation, such as [22,53], which give an overview of existing composition approaches.

Another way of developing a new higher-level service is a generative approach. The main idea is to develop such new services by systematically transforming abstract representations into executable source code. This is done by employing a code generator. The example shown in Fig. 12.9 shows a high-level view on the system neglecting privacy, type safety, and even communication concerns. For example, the DoctorPrivacyService requires the address in a different format, which is not considered in the high level. Clearly, such implementation details have to be implemented manually by service providers, when choosing not to use a generative approach.

In order to reduce the required implementation efforts, a generative approach can automatically synthesize a more detailed description of a service, which is based on the aggregation of basic services and respects the particular needs of each basic service. Given the abstract description in Fig. 12.8, a more detailed description as shown in Fig. 12.9 can be generated.

Using the abstract description of each basic service, which specifies how to use the service, type conversion, as well as communication conversion, can be established. For example, in Fig. 12.9 the DoctorPrivacyServiceWrapper can negotiate an appointment with the PersonPrivacyServiceWrapper only by using the LookUp service, which ensures that the digital representation of a Person is used.

A generative approach provides essential advantages. First, for each PrivacyService shown in Fig. 12.9 a wrapper is generated, which ensures data conversion and provides additional components to implement business logic, e.g., AppointmentHandler in the DoctorPrivacyServiceWrapper. Hence, the service developer can focus on implementing business logic rather than composition of services. Conversion between different formats can automatically be ensured by adding additional components such as the AddressRequestConverter component, which concerts Appointment into the required format for the PersonPrivacyServiceWrapper component. Second, in a generative approach targeting a privacy-aware environment, additional LookUp components can automatically be added.

12.7 Related Work

The related work of our approach domes from different research directions. In Section 12.3 we already described the challenges we faced, such as service composition, technology abstraction, service and data integration, as well as trusted use of personal data. In addition to these challenges, we make use of ADLs as well as generative approaches. For discussing related work, we keep up the identified challenges.

12.8 Discussion

Our approach enables service users to model data access without explicit knowledge about the implementation details facilitating reuse of platform independent models in an agile development environment. However, it does not ensure that the services once granted access to a specific data do neither copy it, nor pass it on. Approaches to data tracing have been presented for homogeneous, enclosed systems, such as the Android Kernel [14]. Whether their practices are feasible for heterogeneous cloud-based services is subject to current research. Having the Digital Me as a single data store for user data introduces a possible bottleneck and honeypot to the ecosystem. However, research big data management and security to fix this is ongoing.

While we presented our approach following a scenario, the approach is not limited to it. The presented basic components are generic regarding the scenario but provide necessary functionality in any software ecosystems. The presented components may not be complete and may have to be extended due to changes in technology or research. Nevertheless, the presented methodology enables providing new components. Additionally, existing components might be extended or updated due to new requirements. This has to be done by the provider of such components. Nevertheless, the design and methodology of the overall approach remain and benefit greatly from the generative approach taken. These benefits are a reduced time-to-market and a significantly improvement in certifying the generated code by certifying the code generator. However, a generative approach can only automatically synthesize wrapper components if the underlying components do exist, such as the basic components presented in Section 12.3. For instance, in cases where no converter is present in the basic services, a service shell is synthesized, allowing service providers to implement the required functionality. A possible approach is to automatically generate OSGi Plugins, which realize the conversion allowing for easy adaptation.

Another disadvantage is that, whenever additional business logic is required such as negotiation of appointments, the business logic has to be implemented manually by the service provider. However, the granularity of the employed modeling languages [25] may not provide a sufficient abstraction such that additional approaches are required to add the wanted granularity. This can, e.g., be achieved by using handwritten extensions such as proposed in [19,20], where an overview of possible handwritten extension approaches is presented.

12.9 Conclusion

We have presented a vision of model-driven cloud architecture engineering that relies on reusable service components. It enables developers of cloud services and architecture to efficiently build upon existing services. These services exist in the context of ecosystems providing important base services to support reuse, service composition, and user data management. For the latter, the notion of a Digital Me provides benefits for all participating roles: it facilitates data access control and data update for service users and it liberates service developers from providing data management features. Furthermore, it always yields the most up-to-data user data available. Using a generative approach, services for the digitized world can be developed on a more efficiently on a better suitable, namely higher, level abstraction. This ultimately enables each role, participating in service development, to contribute their domain expertise to dedicated challenges and facilitates service component reuse.