Michael Gysel
email: michael.gysel@lifetime.hsr.ch

Lukas Kölbener
email: lukas.koelbener@lifetime.hsr.ch

Wolfgang Giersche
email: wolfgang.giersche@zuehlke.com

Olaf Zimmermann

Service Cutter: A Systematic Approach to Service Decomposition

Keywords: functional partitioning, loose coupling, knowledge management, microservices, service interface design guidelines, service granularity, service quality

Decomposing a software system into smaller parts always has been a challenge in software engineering. It is particularly important to split distributed systems into loosely coupled and highly cohesive units. Service-oriented architectures and their microservices deployments tackle many related problems, but remain vague on how to cut a system into discrete, autonomous, network-accessible services. In this paper, we propose a structured, repeatable approach to service decomposition based on 16 coupling criteria distilled from the literature and industry experience. These coupling criteria form the base of Service Cutter, our method and tool framework for service decomposition. In the Service Cutter approach, coupling information is extracted from software engineering artifacts such as domain models and use cases and represented as an undirected, weighted graph to find and score densely connected clusters. The resulting candidate service cuts promise to reduce coupling between and promote high cohesion within services. In our validation activities, which included prototyping, action research and case studies, we successfully decomposed two sample applications with acceptable performance; most (but not all) test scenarios resulted in appropriate service cuts. These results as well as early feedback from members of the target audience in industry and academia suggest that our coupling criteria catalog and tool-supported service decomposition approach have the potential to assist a service architect's design decisions in a viable and practical manner.

Introduction

In 1972, D. L. Parnas reflected "On the Criteria to Be Used in Decomposing Systems into Modules" [START_REF] Parnas | On the Criteria to Be Used in Decomposing Systems into Modules[END_REF]. Since then, functional decomposition has remained an important topic in software engineering. As software systems grew and became more complex, software engineers started to distribute modules and procedures over networks, e.g., as remote objects, components or Web services [START_REF] Alonso | Web Services -Concepts, Architectures and Applications[END_REF]. Architectural styles such as Service-Oriented Architecture (SOA) aim at tackling the many design challenges of such distributed systems; however, designing service interface boundaries at the right level of granularity remained an important challenge for SOA practitioners [START_REF] Dahan | The Known Unknowns of SOA, Blog Post[END_REF][START_REF] Zimmermann | Elements of Service-Oriented Analysis and Design[END_REF]. While partial solutions have been found, two of the related Research Problems (RP) remained open: (RP1) The architecturally significant requirements and stakeholder concerns to be addressed during service (de-)composition are still not understood fully and have not been documented consistently and comprehensively yet. (RP2) A requirements-driven, repeatable, and scalable service decomposition method, to be supported and partially automated by service design tools, has been missing until now.

In this paper, we collect architecturally significant requirements for service decomposition and introduce Service Cutter, our knowledge management method and supporting tool framework that assist software architects when they make service design decisions (note that we do not intend to fully automate this decision making process, but rather support it). The remainder of the paper presents our solutions to RP1 and RP2 as well as their validation in the following way: Section 2 scopes the context of our work and the research problems solved, and defines our basic service decomposition terminology. Section 3 presents our first research contribution, a coupling criteria catalog for service decomposition; Section 4 then defines a novel service decomposition process and an extensible tool architecture that integrates existing graph clustering algorithms to derive candidate service cuts from system specification artifacts. Section 5 presents an implementation of the tool architecture and our validation, which includes action research, two case studies, and performance measurements; Section 6 discusses strengths and weaknesses of Service Cutter and presents initial industry feedback. Section 7 concludes and highlights future work.

Context, Problem and Supporting Definitions

The impact of service boundary design is far-reaching. Loosely coupled, but highly cohesive services are crucial for the maintainability and scalability of software and allow architects and developers to choose a suitable technology independently for each particular business problem and context. Nevertheless, the decomposition of a monolithic application into services still is not fully understood, even with the rise of microservices [START_REF] Zimmermann | Microservices Tenets: Agile Approach to Service Development and Deployment[END_REF], a contemporary incarnation of SOA principles and patterns combined with modern software engineering practices such as continuous, independent deployment. For instance, a popular introduction to microservices states that "deciding how to partition a system into a set of services is very much an art." [START_REF] Richardson | Microservices: Decomposing Applications for Deployability and Scalability, InfoQ article[END_REF] Microservices advocates suggest leveraging Domain-Driven Design (DDD) [START_REF] Evans | Domain-Driven Design: Tackling Complexity in the Heart of Software[END_REF] to obtain service boundaries: For instance, instances of the DDD pattern aggregate establish composed services that are aligned to consistency constraints, and services derived from bounded contexts are aligned to domain model boundaries or team organization structures. Both of these two DDD strategies are suitable approaches to service identification (assuming that one knows how to find aggregates and bounded contexts in the requirements). However, our collective industry experience and a literature review indicate that many more stakeholder concerns have to be taken into account during service decomposition -in particular, architecturally significant requirements including software quality attributes [START_REF] Cervantes | A Principled Way of Using Frameworks in Architectural Design[END_REF]. We believe that this process can and should be approached in a more structured way. This leads to our first hypothesis:

The driving forces for service decomposition can be presented to architects in a comprehensive and comprehensible coupling criteria catalog.

This criteria catalog, which will be introduced in the next section, assembles 16 decomposition criteria commonly used by architects to frame and guide their architectural decisions. We distilled it in an iterative and incremental way, leveraging consecutive project retrospectives, interviews, and a coupling criteria workshop.

A systematic collection of design knowledge can serve as the foundation for partial automation of analysis and design. This observation leads to our second hypothesis:

Based on the coupling criteria catalog, a system's specification artifacts can be processed in a structured and partially automated way to suggest service decompositions that promote loose coupling between and high cohesion within services.

To investigate whether these two hypotheses hold true, we conceptualized and developed Service Cutter, a tool framework architecture and prototype to analyze software engineering artifacts, including use cases and domain models, and to suggest candidate service decompositions.

Service Cutter and its presentation in this paper use the following terminology:

Service. The term service can be defined both on a logical and on a physical level:

1. A service is the technical authority for a specific business capability [START_REF] Dahan | The Known Unknowns of SOA, Blog Post[END_REF]. 2. A service is accessed remotely through some invocation interface and communication protocol, either synchronously or asynchronously [START_REF] Fowler | Inversion of Control Containers and the Dependency Injection Pattern[END_REF].

In order to provide capabilities, a service requires resources. We identified three types of resources that serve as the building blocks of services in our approach:

1. Data. A service may have ownership over a subset of a system's data [START_REF] Zimmermann | Microservices Tenets: Agile Approach to Service Development and Deployment[END_REF]. It then is the only authority allowed to change this data, notifying other services on such changes. The data is often, but not always, stored in a database (then called application state); data exposed at the service interface constitutes its published language [START_REF] Evans | Domain-Driven Design: Tackling Complexity in the Heart of Software[END_REF].

Operations.

A service can encapsulate business rules and calculation (processing) logic. Operations are often, but not always, based on the data owned by the service.

3.

Artifacts. An artifact is a snapshot of data or operation results transformed into a specific format. An example is a business report such as monthly sales figures by geography, which was assembled using operations and data.

To facilitate a systematic approach to service decomposition, we generalize these resources with the concept of a nanoentity shown in Figure 1: Service decomposition then can be defined as the process of identifying a set of services and assigning all nanoentities to one (and only one) of these services. A coupling criterion represents a particular driving force for service decomposition; such criteria capture architecturally significant requirements and arguments why two nanoentities should or should not be owned and exposed by the same service. Software System Artifacts (SSAs) represent the analysis and design artifacts that contain information about coupling criteria; scoring priorities weigh the coupling criteria. A service cut is the output of a single execution of the service decomposition process.

Coupling Criteria Catalog

We conducted a literature review, reflected on past projects, and met for a workshop to assemble our collective, precompiled architecture design experience. We consolidated the results of these knowledge gathering activities in a coupling criteria catalog in an iterative and incremental manner. Our coupling criteria catalog aims at serving as a comprehensive, yet not complete collection of architecturally significant requirements and decision drivers for service decomposition. Note that we strived for consensus, clarity, and compactness; hence, not all candidate criteria made it into the catalog. We grouped the CC into four categories in the catalog (to improve readability):

1. Cohesiveness: Criteria describing certain common properties of mutually related nanoentities that justify why these nanoentities should belong to the same service. An example of a cohesiveness argument is that all nanoentities involved in the realization of a use case should belong to a single service to simplify use case execution.

Compatibility:

Criteria indicating divergent characteristics of nanoentities. A service should not contain nanoentities with incompatible characteristics. Examples of such characteristics are "high", "eventually", and "weak" for the criterion Consistency Criticality; these data consistency management options are mutually exclusive.

Constraints:

Criteria specifying high-impact requirements that enforce that certain groups of nanoentities a) must jointly constitute a dedicated service or b) must be distributed amongst different services. The fact that a set of nanoentities has to be modified jointly and atomically, e.g. in the same database transaction, forms a strong requirement that justifies to be represented as constraint criterion in the catalog.

Communication:

Criteria exclusively pertaining to the technical cost of remoting, e.g., mutability. Immutable resources do not require complex synchronization means.

All 16 CC are recorded in a common card layout inspired by pattern languages and agile practices. The usage of such C3s makes the catalog structure recognizable and the catalog extensible. Table 2 and Table 3 present two examples of filled-out C3 instances: 1

CC-1 Identity & Lifecycle Commonality

Description

Nanoentities that belong to the same identity and therefore share a common lifecycle (create, read, update, delete).

System Specification Artifacts (SSAs)

-Entity-Relationship Models -Domain-Driven Design Entity pattern instances

Literature

Entity definition in Domain-Driven Design [START_REF] Evans | Domain-Driven Design: Tackling Complexity in the Heart of Software[END_REF]: Some objects are not defined primarily by their attributes. They represent a thread of identity that runs through time and often across distinct representations.

Type Cohesiveness

Table 3. The "Semantic Proximity" CC.

CC-2 Semantic Proximity Description

Two nanoentities are semantically proximate when they have a semantic connection given by the business domain.

The strongest indicator for semantic proximity is coherent Eliciting CC instances to reflect the non-functional requirements of a specific software product is a key aspect of analysis and design. Hence, software architects can leverage the CC catalog to establish a common terminology for their design discussions as well as architecture documentation. Moreover, our CC catalog can serve as the basis of a structured, repeatable way to identify, make, and capture related decisions [START_REF] Zimmermann | Architectural Decision Guidance across Projects[END_REF]; it serves as ubiquitous language [START_REF] Evans | Domain-Driven Design: Tackling Complexity in the Heart of Software[END_REF] for service decomposition.

Service Decomposition Concepts and Tool Architecture

To allow architects to leverage the CC catalog and receive service decomposition advice, we created the Service Cutter tool framework. Service Cutter derives candidate service cuts from user-prioritized coupling criteria (obtained from SSAs) to achieve loose coupling between services and high cohesion within services. To do so, additional design concepts are required, which will be introduced in this section.

Decomposition input. The input to Service Cutter is a machine-readable representation of selected software engineering artifacts that represent intermediate stages of analysis and design. To represent these artifacts, we introduce System Specification Artifacts (SSAs). SSAs serve as data sets from which the Service Cutter can extract the required coupling criteria information. Examples of SSA types are use cases, DDD entities/aggregates, and Entity-Relationship Models (ERMs); e.g., information about CC-2 Semantic Proximity comes from these two SSA types. We designed additional SSA types to supply information that is not contained in existing ones (e.g., shared owner groups, predefined services, separated security zones and security access groups). The Service Cutter wiki provides detailed explanations and a reference of these nine types of SSAs (called "user representations" in the prototype). 2Figure 3 specifies the dependencies of coupling criteria and SSAs. For instance, information about CC-16, Security Constraint, can be obtained from the SSA "separated security zones". Security zones group nanoentities by their diverging privacy requirements, e.g. sensible personal information vs. unclassified, public data. Algorithm integration. We then employ clustering algorithms on this graph to find candidate service cuts. Our concepts and tool architecture are designed to be general enough to allow the inclusion of multiple algorithms; e.g., a programming interface is provided which can be implemented for any clustering algorithm that is based on undirected, weighted graphs. At present, we included Java implementations of two algorithms, namely Girvan-Newman [START_REF] Newman | Finding and evaluating community structure in networks[END_REF] and the Epidemic Label Propagation (ELP), originally defined by Raghavan and later refined by Leung et al. [START_REF] Raghavan | Near linear time algorithm to detect community structures in large-scale network[END_REF]. A comparison of and rationale for the selection of these two different approaches can be found in [START_REF] Gysel | Service Cutter -A Structured Way to Service Decomposition[END_REF]. For instance, the two algorithms differ from each other in their (non-)deterministic behavior; only one of them required a number-of-clusters in parameter.

Results of a deterministic algorithm like Girvan-Newman can be reproduced by running the algorithm repeatedly using the same input data. The impact of different input data, scoring values and priorities can therefore be analyzed as the algorithm itself does not include a random element. A non-deterministic algorithm like ELP (Leung) complicates analysis, as changes in the results do not always result from input changes. Furthermore, results always need to be safely persisted and reloaded since they cannot be reproduced reliably. An element of randomness is not necessarily a disadvantage: Running multiple algorithm cycles presents different solutions and outlines where the difficult architectural decisions reside.

Providing the number of clusters as a parameter to the algorithm has the advantage of analyzing the service decomposition with any possible number of services. This feature can be used to better understand the structure and coupling between parts of the system when running the algorithm with varying input. Requesting a high number of services, for instance, may indicate how services can be decomposed further; a small predefined service number allows systems to gradually emerge from a monolithic architecture to service orientation. However, algorithms requiring the number of services as input shift the responsibility to answer this critical question back to the user; as architects are often prejudiced on the number of services their system should be composed of, this is not always desirable. Letting Service Cutter suggest not only the content of each service, but also the number of services (as ELP does) challenges the user to reassess his/her ideas against the suggested candidate service cuts.

Priority scoring. The analysis and processing of coupling criteria uses a weighted graph and scorers. The weight on an edge between two nanoentities is the sum of all scores per CC multiplied by their priorities. Table 4 illustrates the calculation: The score is a number from -10 to +10. A score of +10 expresses that these two nanoentities should definitely reside in the same service according this coupling criterion. A score of -10 therefore represents the opposite extreme, i.e., that the nanoentities should be placed into different services. The calculation is performed for every link between nodes with coupling information; Figure 5 shows an example. The calculation depends on the involved coupling criteria; the scorers map coupling criteria to actual numbers used to construct the weighted graph. Table 5 maps CCs to the five types of scorers that differ in their calculation logic:

Semantic Proximity Semantic Proximity Scorer

The joint access to a pair of nanoentities is counted and mapped to an even distribution between 0 and 10.

Structural Volatility Consistency Criticality Storage Similarity Content Volatility Availability Criticality Security Criticality

Characteristics Scorer

To achieve homogenous services, this scorer sets a penalty of -1 to -10 to relations with diverging requirements.

Security Constraint Separated Group Scorer

Sets a score of -10 to all nanoentities that belong to a group other than the current one.

Predefined Service Constraint

Exclusive Group Scorer Same as Cohesive Group, but also adds a penalty of -10 to nanoentities not in the group.

Mutability Network Traffic Suitability

Not defined and implemented yet.

A detailed description of the scorers in Service Cutter can be found in [START_REF] Gysel | Service Cutter -A Structured Way to Service Decomposition[END_REF].

Evaluation via Prototyping, Case Studies, Action Research

We validated our research results via implementation, case study, and action research. Service Cutter's current implementation supports a basic feature set that realizes the structured approach of splitting a system into discrete, loosely coupled services:

• 14 out of 16 coupling criteria from Section 3 are implemented (see Table 5).

• All nine System Specification Artifacts (SSAs) that represent user input (see Figure 3 in Section 4) can be imported in the form of custom JSON files. • Seven criteria priorities, in the prototype casually defined as "T-Shirt sizes" (IGNORE, XS, S, M, L, XL, XXL) allow users to characterize the context of a system by valuating the coupling criteria in relation to each other. • The suggested candidate service cuts and their dependencies are visualized.

• The published language [START_REF] Evans | Domain-Driven Design: Tackling Complexity in the Heart of Software[END_REF] of a service pair (including the data transferred to and from the invoked service) is exposed via the involved nanoentities.

Figure 6 features a candidate service cut for the "cargo tracking" domain model from [START_REF] Evans | Domain-Driven Design: Tackling Complexity in the Heart of Software[END_REF]. This candidate service cut consists of three services A, B and C (larger squares), each owning a set of (cohesive) nanoentities represented as small squares: Arrows between two services (e.g., Service A and Service B) indicate a dependency between them. The resulting published language, which characterizes the amount of coupling between these services in terms of the shared understanding about the nanoentities that are exposed at the service boundary, is also shown.

Release 1.1 of the Service Cutter implementation is available on GitHub3 . This prototype consists of two components implemented in Java and JavaScript (using Spring Boot, Spring MVC, AngularJS, and JHipster), RESTful HTTP Web services wrapping the scoring logic, and a Web application for input and output visualization.

Validation approach and results. To further validate the implemented concepts, we assessed the candidate service cuts of the following two case studies:

1. A fictitious "Trading System" for which we forward-engineered the requirements, drawing on industry experience with financial services software. 2. The DDD sample application "Cargo Tracking" that accompanies the DDD book [START_REF] Evans | Domain-Driven Design: Tackling Complexity in the Heart of Software[END_REF]; we reverse engineered the requirements for this scenario from the existing implementation that is available on SourceForge. 4To objectify the validation and have a comparison baseline, we defined expected service cuts for both systems according to our experience in service design; to reduce bias, we developed a service design checklist for this task. 5 Next, we defined three result categories in order to rate the candidate service cuts:

A: Excellent service cut. The cut (i.e., suggested service decomposition) does not follow the way we expected, but we find reasons why the cut makes sense from an architect's perspective. It therefore improves our own view of the analysed system. B: Expected service cut. The cut meets and therefore validates our expectations.

C: Unreasonable service cut.

There is a mismatch between the cut and the expected one, and we do not find any reasons why this cut would be beneficial.

To be able to assess the quality of the output of Service Cutter, we use a four-level classification: An excellent output contains zero unreasonable service cuts and at least one excellent service cut (i.e., a cut in category A). A good output contains zero unreasonable service cuts (C). An acceptable output contains at most one unreasonable service cut (C). A bad output contains two or more unreasonable service cuts (C).

Table 6 summarizes the decomposition results for both systems. Both algorithms, Girvan-Newman and ELP (Leung), were able to produce acceptable or good service cuts (but not in all cases): Table 6. Assessment of service cuts for analyzed systems (case studies).

Evaluated Application Girvan-Newman ELP (Leung) Trading System

Good output Good (note: in some exceptional cases, Leung produced acceptable and excellent output) Cargo Tracking System Bad output Acceptable

Both test systems contain approximately 20 nanoentities. To analyze Service Cutter's performance behavior with more complex systems, we conducted additional performance tests. These tests are derived from the trading system; all nanoentities and SSAs were replicated and scaled up 60 times to create larger and more complex domain models and graphs. These load tests measure the runtime for graph creation and clustering algorithm and leave out data import and visualization. The tests were conducted on a Windows 10 developer notebook with an Intel i5 2.2GHz CPU and 8GB RAM as documented in detail online. 6 Figure 7 shows the test results. The calculation for systems with up to 600 nanoentities is done in less than five seconds, which we consider reasonable. Around 75% of the time used is consumed by graph creation whereas the clustering algorithm only uses around 25% of the time. Hence, our Java code building the graph based on the imported data could be analyzed and improved to improve runtime performance even further.

6

Discussion: User Feedback, Pros and Cons, Related Work User feedback. We presented the Service Cutter concepts and their implementation to more than 20 members of the target audience (i.e., software engineers and architects with experience in designing SOAs), and one of the authors of the paper applied Service Cutter to a single project case (as a form of technical action research). The systematic overall approach was appreciated and considered to be promising; it was pointed out that Service Cutter cannot only be used in an SOA context, but also be used to split modules without remote interfaces (with adjusted CC priorities). The template-based coupling criteria cards were generally appreciated, but some of the current texts were assessed to be too terse (by one provider of feedback); a more elaborate, but not yet verbose wording was requested. The naming of some coupling criteria in our catalog also was challenged. An example is "CC-13 Network Traffic Suitability", which covers the more common and basic concept of throughput (which in turn is one facet of the top-level quality attribute performance). Furthermore, system and process assurance audit compliance [START_REF] Julisch | Compliance by Design -Bridging the Chasm between Auditors and IT Architects[END_REF] was suggested to be added as a compatibility criterion; further research is required to investigate how to integrate such a composite and complex, possibly even recursive criterion into Service Cutter.

Finally, our selection of two clustering algorithms was questioned, and it was suggested to only integrate deterministic algorithms that do not require the number of clusters as a parameter. This critique pertains to the current tool implementation only; the Service Cutter concepts from Sections 3 and 4 do not rely on any particular algorithm. Due to the generality of our concepts and the modular, extensible architecture of their implementation, we expect the effort to integrate other algorithms into the Service Cutter framework to be in the range of a few person days per algorithm.

Seconds

Nanoentities

According to the feedback of our industry project partner, who leads an architect and developer community in professional services, Service Cutter and its underlying reasoning represent a sound framework to prepare and back architectural decisions. More specifically, it allows architects to study the impact of weight variations on the resulting candidate service cuts. Questions like "what, if security wasn't an issue here" can be answered easily by changing the respective scoring priority of criterion "security criticality". When used with care, Service Cutter can improve the credibility of architects involved in critical architecture assessments (evaluations) significantly. The SSAs and coupling criteria can also be used to educate junior architects or students on the driving forces of service decomposition.

Benefits. From our internal and external validation activities, we can conclude that Service Cutter offers a number of advantages to service architects: The coupling criteria catalog indeed collects relevant architecturally significant requirements and decision drivers for service decomposition, and it does so in an accessible, reusable, and extensible way. It therefore contributes to the body of reusable architectural decision knowledge as envisioned in our previous work [START_REF] Zimmermann | Architectural Decision Guidance across Projects[END_REF].

Service Cutter suggests candidate service cuts that are obtained from commonly used analysis and design artifacts, such as use cases and domain models, via a nanoentity abstraction and the coupling criteria. By expecting several such analysis and design artifacts, Service Cutter challenges its users (i.e., service architects) to reflect which stakeholder input and non-functional quality characteristics are relevant for his/her system (and architecture design process). Hence, service architects might use these artifacts as a checklist and stimulus for the requirement engineering.

The candidate service cuts verify and/or challenge the architect's expectations regarding the number of services and their interface definitions. Both green field scenarios and iterative approaches for migrating a monolith to services are supported. 7Drawbacks and liabilities. The benefits that we could observe during our evaluation activities come at a price; usage of Service Cutter concepts and their implementation during these activities has unveiled some (expected) drawbacks and liabilities.

Significant effort is required to enter SSAs (such as use cases and domain models) in JSON; in future versions, we plan to import them, e.g., from UML modeling tools.

We are aware of the risk of a "pseudo accuracy" effect. It is subject to debate whether service design work, dealing with rather diverse requirements (some of which are hard to quantify) can really be delegated to algorithms that look for an aggregated optimal solution. Architects traditionally apply their tacit knowledge and "gut feel" when making the relate decisions; they are biased. This discussion can be seen as the SOA variant of the more general discussion on "a rational design process: how and why to fake it" [START_REF] Parnas | A Rational Design Process: How and Why to Fake it[END_REF]. However, we believe our approach to be valuable even when being confronted with a healthy amount of skepticism -relevant design questions are asked and related criteria listed, and the relation between these concerns and the user input in SSAs is unveiled. Furthermore, a checklist effect occurs; discussions among collaborating architects are stimulated.

Other drawbacks and liabilities concern framework architecture design and extensibility. First and foremost, the clustering algorithms that are currently integrated possibly should be complemented with additional ones due to the only partially satisfying evaluation results. Algorithmic complexity is a major source of performance limitations and therefore has to be taken into account in any such future algorithm selection decisions; fortunately, clustering algorithms with linear complexity exist.

As the Service Cutter framework continues to evolve, additional validation and evaluation activities work will be required. For instance, it has to be verified that the tool performance does not degrade significantly when processing even larger amounts of user input that go beyond scaled up sample data and case studies (e.g., complex domain models from enterprise information systems).

Related work.

Quality attribute-driven design has been an important research topic in the software architecture community for many years [START_REF] Cervantes | A Principled Way of Using Frameworks in Architectural Design[END_REF][START_REF] Parnas | On the Criteria to Be Used in Decomposing Systems into Modules[END_REF]; the specific requirements and constraints of service-oriented architectures and microservices have also been investigated and related methods proposed [START_REF] Erradi | SOAF: An Architectural Framework for Service Definition and Realization[END_REF][START_REF] Papazoglou | Service-Oriented Design and Development Methodology[END_REF][START_REF] Zimmermann | Elements of Service-Oriented Analysis and Design[END_REF]. Such methods are complementary to the approach presented in this paper, providing an overall frame for the use of Service Cutter, as well as input for coupling criteria, SSAs, and priority scores.

Other research areas in service-oriented computing include service discovery and runtime topology lookup (e.g., in clouds), dynamic service matchmaking, service composition into business processes and workflows, quality-of-service awareness, policies, and agreement, as well as service management. These efforts have different goals than Service Cutter, which aims at assisting architects making design decisions; however, well-crafted service cuts can be seen as a prerequisite for the successful application of any advanced service-oriented computing concepts and technologies. In our future work, we therefore consider to include additional criteria and SSAs that represent the concepts from these research efforts as they mature.

Summary and Outlook

In this paper, we presented Service Cutter, a systematic approach to system decomposition, which has been a relevant problem since the very origins of program modularization and software engineering. Service Cutter advances the state of the art a) with the concept of coupling criteria cards, b) 16 instances of such cards (harvested from practical experience and the literature), and c) an extensible service decomposition tool framework architecture that integrates graph clustering algorithms and features priority scoring starting from nanoentities and nine types of analysis and design specifications (including domain models and use cases). This structured and extensible combination of a criteria-driven method with supporting architectural knowledge and a design optimization and visualization tool paves the way towards the desired engineering approach to service interface and service granularity design. We evaluated Service Cutter via implementation (integrating two existing graph clustering algorithms), a combination of action research and case study investigations, and load tests. The validation results and additional user feedback indicate that the proposed semi-automated approach to service decomposition works as designed and has the potential to benefit practitioners significantly. While the suggested service cuts did not always meet all early adopters' expectations, artifact input and coupling criteria were regarded adequate; the proposed decomposition process was appreciated.

While our early experiences with the presented structured, partially automated (i.e., tool supported) approach are promising, work remains to be done both on the conceptual (research) level, as well as on the implementation (engineering) level. For instance, further enhancements of Service Cutter may include seamless integrations of the analysis and design tool chain members so that SSAs can be extracted from other tools automatically. We discussed other directions for future work in Section 6; related development issues are tracked in the open source release of Service Cutter.

Figure 1 .

 1 Figure 1. Data, operations and artifacts generalized into the nanoentity concept.

Figure 2

 2 lists the 16 Coupling Criteria (CC) in the final catalog version:

Figure 2 .

 2 Figure 2. Coupling Criteria (CC) catalog compiling 16 CC in four categories.

Figure 3 .

 3 Figure 3. Dependencies between System Specification Artifacts (SSAs) and CC. Decomposition process.Figure 4 specifies the service cutting process in BPMN:

  Figure 4 specifies the service cutting process in BPMN:

Figure 4 .

 4 Figure 4. Serving decomposition process (human vs. automated/tool-supported tasks).Service Cutter processes the provided SSA instances and extracts nanoentities as well as coupling criteria instances from them. Prioritized coupling criteria and SSAs are transformed into an undirected, weighted graph; nodes represent nanoentities, and the weights of edges indicate how cohesive and/or coupled two nanoentities are.

Figure 5 .

 5 Figure 5. Weighted edges representing the coupling connect the nanoentities.

Figure 6 .

 6 Figure 6. Screenshot of Service Cutter presenting a candidate service cut.

Figure 7 .

 7 Figure 7. Performance test results: service cut calculation (scaled up sample application)

Table 1 .

 1 Table 1 introduces this Coupling Criterion Card (C3) template: A template for Coupling Criterion Cards (C3).

	[Coupling Criteria Identifier and Name]
	Description	[A brief summary of the Coupling Criterion (CC) w.r.t. its
		impact on/usage of nanoentities.]
	System Specificati-
	on Artifacts (SSAs)

[Requirements engineering input and software architecture concepts/deliverables pertaining to this coupling criterion.] Literature [References to books, articles, and/or blog posts.] Type Cohesiveness | Compatibility | Constraint | Communication Characteristics [Defines a set of possible values for this CC. Only applies to CC of type Compatibility. E.g., "critical", "normal", "low"].

Table 2 .

 2 The "Identity & Lifecycle Commonality" CC.

Table 4 .

 4 An exemplary calculation of the weight of an edge.

	Coupling Criterion	Score	Priority Result
	CC-1: Semantic Proximity	4	1	4 * 1 4
	CC-7: Availability Criticality	2.5	5	2.5 * 5	12.5
	CC-9: Consistency Constraint	8	3	8 * 3 24
		Total weight 4 12.5 24 40.5

Table 5 .

 5 Coupling criteria and the scorers calculating the weight of the edges.

	Coupling Criterion	Scorer Type
	Identity & Lifecycle Commonality	Cohesive Group Scorer
	Shared Owner	Nanoentities in a cohesive group should remain
	Latency	together in one service. All relations between
	Security Contextuality	nanoentities in a group are scored +10.
	Consistency Constraint

https://github.com/ServiceCutter/ServiceCutter/wiki/User-Representations

https://github.com/ServiceCutter/ServiceCutter

https://sourceforge.net/projects/dddsample/

https://github.com/ServiceCutter/ServiceCutter/wiki/Decomposition-Questionnaire

https://github.com/ServiceCutter/ServiceCutter/wiki/Runtime-Performance-Tests

Explained on GitHub: https://github.com/ServiceCutter/ServiceCutter/wiki/Usage-Scenarios


Antonio Brogi

Andrea Canciani

Jacopo Soldani

Fault-aware application management protocols

Keywords: Management protocols, fault modelling, finite state machines

We introduce fault-aware management protocols, which permit modelling the management behaviour of application components by taking into account the potential occurrence of faults, and we show how such protocols can be composed to analyse the behaviour of a multicomponent application and to automate its management. We also illustrate a way to recover applications that are stuck because a fault was not properly handled and/or because a component is behaving differently than expected.

Introduction

Automating the management of composite applications is currently one of the major concerns of enterprise IT [START_REF] Leymann | Cloud computing[END_REF]. Such applications typically integrate various heterogeneous components, whose deployment, configuration, enactment, and termination must be suitably coordinated.

A convenient way to represent the structure of a composite application is a topology graph [START_REF] Binz | Automated Discovery and Maintenance of Enterprise Topology Graphs[END_REF], whose nodes represent the application components, and whose arcs represents the dependencies among such components. More precisely, each topology node can be associated with the requirements of a component, the operations to manage it, and the capabilities it features. Inter-node dependencies associate the requirements of a node with capabilities featured by other nodes.

In [START_REF] Brogi | Modelling and analysing cloud application management[END_REF] we have shown how the management behaviour of topology nodes can be modelled by management protocols, specified as finite state machines whose states and transitions are associated with conditions defining the consistency of the states of a node and constraining the executability of management operations. Such conditions are defined on the requirements of a node, and each requirement of a node has to be fulfilled by a capability of another node. As a consequence, the management behaviour of a composite application can be easily derived by composing the management protocols of its nodes according to the dependencies defined in its topology. [START_REF] Brogi | Modelling and analysing cloud application management[END_REF] does not deal with deal with the potential occurrence of faults, which however must be considered when managing complex composite applications [START_REF] Cook | How complex systems fail[END_REF]. Indeed, an application component may be affected by faults caused by other components on which it relies (e.g., a component is shutdown or uninstalled while another component is relying on its capabilities).

In this paper we propose a fault-aware extension of management protocols, to permit modelling how nodes behave when faults occurs. We also illustrate how to analyse and automate the management of composite applications in a fault-resilient manner. Namely, we show how the fault-aware management behaviour of a composite application can be determined by simply composing the management protocols of its nodes according to the application's topology. We then describe how to determine whether a plan orchestrating the application management is valid, which are its effects (e.g., which capabilities are available after executing it, or whether it may generate faults while being executed), and how this also permits finding management plans from given application configurations to achieve specific goals.

Even if application components are described by fault-aware management protocols, the actual behaviour of components may differ from their described behaviour (e.g., because of some bug). We show how the unexpected behaviour of a component can be modelled by automatically completing its management protocol, and how this permits analysing the (worst possible) effects of a misbehaving component on the rest of an application. We also illustrate a way to recover applications that are stuck because a fault was not properly handled and/or because of misbehaving components.

The rest of the paper is organised as follows. Sect. 2 provides an example motivating the need for fault-aware management protocols. Sect. 3 illustrates such protocols and to compose them to analyse an application's management in presence of faults. Sect. 4 describes how to deal with faults caused by the unexpected behaviour of component(s), and how to recover stuck applications. Sects. 5 and 6 discuss related work and draw some concluding remarks.

Motivating example

Consider a toy application composed by a web-based front-end and a back-end, both deployed on an apache server, which in turn is installed on a debian operating system. Fig. 1 illustrates the topology of such application, according to the TOSCA [START_REF]OASIS: Topology and Orchestration Specification for Cloud Applications[END_REF] graphical notation.

Each inter-node dependency is explicitly represented by a relationship connecting a node's requirement with another node's capability (e.g., the server requirements of front-end and back-end are connected with the app-rte capability of apache). A relationship can represent a vertical containment dependency (e.g., apache is installed on debian), or an horizontal dependency, specifying that a component requires another, without stating that the former is contained in the latter (e.g., front-end must connect to back-end's endpoint to work properly).

Suppose for instance that all nodes have been deployed, started, and properly connected each other (i.e., all components are in their running state). What happens if the stop operation of back-end is executed? The back-end application component is stopped, and this generates a fault in the front-end, which becomes unable to serve requests to its clients, simply because the connection dependency with back-end is not working any more. Furthermore, even if back-end is restarted, the front-end has to re-connect to the back-end.

Even worse is the case when a node presents an unexpected behaviour. Suppose again that the application is up and running, and that the apache server unexpectedly crashes. Such a crash results in faulting also the nodes contained in apache (viz., front-end and back-end), which are suddenly killed, and potentially enter in an inconsistent state that makes them unusable from there onwards.

Both the above mentioned cases fail because a node stops providing its capabilities while other nodes are relying on them to continue to work. In the first case this happens because of the invocation of a management operation that stops a node while other nodes are depending on it. In the second case a node unpredictably fails1 .

3 Modelling and analysing application management in presence of faults

Fault-aware management protocols

Let N be a node modelling an application component. Management protocols [START_REF] Brogi | Modelling and analysing cloud application management[END_REF] permit modelling the management behaviour of N by describing whether and how the management operations of N depend (i) on other operations of the same node, and/or (ii) on operations of other nodes providing the capabilities that satisfy the requirements of N . The first kind of dependencies is described by specifying relationships between states and management operations of N . More precisely, to describe the order in which the operations of N can be executed, we employ a transition relation τ specifying whether an operation o can be executed in a state s, and which state is reached by executing o in s.

The second kind of dependencies is described by associating transitions and states with (possibly empty) sets of requirements to indicate that the corresponding capabilities are assumed to be provided. More precisely, the requirements associated with a transition t specify which are the capabilities that must be offered to allow the execution of t. Instead, the requirements associated with a state of N specify which capabilities must (continue to) be offered by other nodes in order for N to (continue to) work properly. To complete the description, each state s of N is also associated to the capabilities provided by N in s.

We hereby define a fault-aware extension of management protocols [START_REF] Brogi | Modelling and analysing cloud application management[END_REF], to permit describing how N reacts when it is in a state assuming some requirements to be satisfied, and some other node(s) stop(s) providing the capabilities satisfying such requirements. We introduce a new transition relation ϕ to model the explicit fault handling of N , i.e. how N changes its state from s to s when some of the requirements it assumes in s stop being satisfied.

Definition 1. Let N = S N , R N , C N , O N , M N be a node, where S N , R N , C N ,
and O N are the finite sets of its states, requirements, capabilities, and management operations, and M N = s N , ρ N , χ N , τ N , ϕ N is a finite state machine defining the fault-aware management protocol of N , where2 :

-s N ∈ S N is the initial state, -ρ N : S N → 2 R N is a function indicating which requirements must hold in each state s ∈ S N , -χ N : S N → 2 C N is a function indicating which capabilities of N are offered in a state s ∈ S N , -τ N ⊆ S N × 2 R N × O N × S N is
-ϕ N ⊆ S N × 2 R N × S N
is a set of triples modelling the explicit fault handling for a node, i.e. s, F, s ∈ ϕ N denotes that the node will change its state from s to s if the requirements in F stop being satisfied. Example 1. Fig. 2 shows the management protocols of the nodes composing our motivating scenario (where thicker arrows represent τ , and lighter arrows represent ϕ).

M front-end M back-end M apache M debian
Consider for instance the management protocol M apache , which describes the behaviour of the apache node. In its initial state (not-installed) apache does not require nor provide anything. In the installed and started states it instead assumes the os requirement to (continue to) be satisfied. If the os requirement is faulted, then apache returns to its initial state (thus requiring to be installed and started again). The started state is the only one where apache concretely provides its app-rte capability. Finally, note that all apache's operations can be performed only if the os requirement is satisfied.

Consider now the management protocol M back-end , which describes the behaviour of the back-end node. When back-end is installed or running, it assumes the capability satisfying its server requirement to (continue to) be provided. What happens if such capability stops being provided?

The management protocol of a node may leave unspecified how the component will behave in case some requirements stop being fulfilled in some states. To explicitly model that, management protocols can be completed by adding transitions for all unhandled faults, all leading to a "sink" state s (that requires and provides nothing) 3 .

Definition 2. Let N = S N , R N , C N , O N , M N be a node, where M N = s N , ρ N , χ N , τ N , ϕ N is
its fault-aware management protocol. The management protocol M N can be completed by replacing S N and ϕ N with:

-S N = S N ∪ {s }, with s ∈ S N and ρ(s ) = χ(s ) = ∅, and -ϕ N = ϕ N ∪ { s, F, s | s ∈ S N ∧ ∅ = F ⊆ ρ(s) ∧ s, F, s ∈ ϕ N }.
In the following we will assume fault-aware management protocols to be automatically completed as defined above.

Example 2. The completion of the management protocol M back-end (Fig. 2) is shown in Fig. 3: We add a "sink state" back-end , and two transitions reacting to the unsatisfaction of the server requirement when back-end is in its installed or running states. The extension of the other management protocols in Fig. 2 is even simpler: Since they handle all potential faults, their extension only consists in adding a sink state to each of them (i.e., front-end is added to the front-end's states, while apache and debian are added to those of apache and debian, respectively).

Composition of fault-aware management protocols

Let A = T, b be a generic composite application, where T is the finite set of nodes (application components) in the application topology 4 , and where the connection among nodes is described by a (total) binding function

b : N ∈T R N → N ∈T C N
associating each node's requirement with the capability satisfying it.

Since A defines a composition of the nodes in T that coordinate through the binding b among requirements and capabilities, we model the behaviour of A by simply composing the management protocols of the nodes in T .

First, we generalise the notion of global state of A [START_REF] Brogi | Modelling and analysing cloud application management[END_REF] by introducing pending faults. To simplify notation, we shall denote with ρ(G) the set of requirements that are assumed to hold by the nodes in T when A is in G, with χ(G) the set of capabilities that are provided by such nodes in G, and with b(R) the set of capabilities bound to the requirements in R. Formally:

-

ρ(G) = N ∈T {ρ N (s) | s ∈ G ∧ s ∈ S N }, -χ(G) = N ∈T {χ N (s) | s ∈ G ∧ s ∈ S N }, and -b(R) = r∈R {b(r)}.
We define the global state of an application A as a set G containing the current state of each of its nodes. We also define a function P to denote the set of pending faults in G, which are the requirements that are assumed in G while the corresponding capabilities are not provided.

G ⊆ N ∈T S N ∧ ∀N ∈ T : ∃!s ∈ G ∩ S N .
The set P (G) of pending faults in G is defined as follows:

P (G) = {r ∈ ρ(G) | b(r) ∈ χ(G)}.
We denote by G the initial global state of A, where each node of T is in its initial state (viz., G = N ∈T {s N }).

The management behaviour of a composite application A is defined by a labelled transition system over its global states, which consists of two simple inference rules, (op) for operation execution and (fault) for fault propagation.

= S N , R N , C N , O N , M N with M N = s N , ρ N , χ N , τ N , ϕ N .
The fault-aware management behaviour of A is modelled by a labelled transition system whose configurations are the global states of A, and whose transition relation is defined by the following inference rules:

s ∈ G s, H, o, s ∈ τ N P (G) = ∅ b(H) ⊆ χ(G) G o -→ (G -{s}) ∪ {s } (op) s ∈ G s, F, s ∈ ϕ N F ⊆ P (G) G ⊥ -→ (G -{s}) ∪ {s } (fault)
The (op) rule defines how the global state of A is updated when a node performs a transition s, H, o, s . Such transition can be performed when there are no pending faults (viz., P (G) = ∅), and the requirements needed to perform the transition are satisfied in G (viz., b(H) ⊆ χ(G)). As a result, the global state G is updated with the new state of N (viz., G = (G -{s}) ∪ {s }), potentially triggering faults to be handled (if

P (G ) = ∅).
The (fault) rule instead models fault propagation. It defines how the global state G of an application A is updated when executing a fault handling transition s, F, s of a node N . Such transition can be executed if the faults it handles are pending in G (viz., F ⊆ P (G)), and its effects on the whole application A are the following: The state of N is updated (viz., G = (G -{s}) ∪ {s }), novel faults may be triggered, while the faults in F are not pending any more.

Analysing an application's fault-aware management behaviour

The management behaviour defined in Def. 4 permits analysing and automating the management of a composite application. For instance, we can easily define which sequences (or, more in general, which workflows) of management operations can be considered valid in a global state of an application.

G 0 of A iff ∃G 1 , G 2 , ...G n : G 0 o1 -→ G 1 o2 -→ G 2 o3 -→ . . . on -→ G n where G o -→ G G o -→ G G o -→ G G ⊥ -→ G G o -→ G
A workflow W orchestrating the management operations in A is valid in G 0 iff all its sequential traces are valid in G 0 . Example 3. Consider the workflow in Fig. 4.(a), which permits restarting the backend and front-end of our motivating application (Figs. 1 and2). Suppose also that the application is in the following global state: debian is running, apache is started, back-end and front-end are running. It is easy to check that the workflow is valid in the considered global state since both its sequential traces are valid in such global state.

Consider, for instance, the sequential trace performing back-end's stop before frontend's stop. The modelling introduced in Sects. 3.1 and 3.2 can be exploited for various other purposes besides checking whether a plan is valid. For instance, validity may not be enough, as different sequential traces of a plan may reach different global states. It is thus interesting to characterise deterministic plans. Definition 6. Let G be a global state of a composite application A. A valid workflow plan W for A is deterministic from G if and only if all its sequential traces reach the same global state G .

The way to check whether a given plan is valid or deterministic is obviously a visit of the graph associated with the transition system of an application's management behaviour (Def. 4). It is worth highlighting that, thanks to the constraints on management protocols and to the way they are combined, such a graph is finite and thus its visit is guaranteed to terminate.

It is also interesting to compute the effects of a valid workflow W on the states of an application's components, as well as on the requirements that are satisfied and the capabilities that are available. Such effects can be directly determined from the global state(s) reached by performing the sequential traces of W .

Moreover, the problem of finding whether there is a workflow which starts from a global state G and achieves a specific goal (e.g., bringing some components of an application to specific states, or making some capabilities available) can also be solved with a visit of the graph associated with the transition system of an application's management behaviour.

Finally, our model allows to characterise an interesting property that an application may exhibit. If it is possible to reach the initial global state G from any global state G that is reachable from G itself, then it is always possible to generate a plan for any reachable goal from any reachable global state. This ensures an application's recoverability, meaning that whatever global state G we reach from the initial global state G (by executing whatever operation or performing whatever ⊥-transition), we can always get back to G, thus always permitting to reset the application.

Modelling the unexpected

Unexpected behaviour of a component

The analysis described in Sect. 3 assumes that each application component behaves according to its specified management protocol, thus not taking into account components that behave unexpectedly because of mismatches between their modelled and actual behaviour (e.g., because of bugs).

The unexpected behaviour of a component can be modelled by automatically completing its management protocol by adding a "crash" operation that leads the node to the sink state s .

Definition 7. Let N = S N , R N , C N , O N , M N be a node, where M N = s N , ρ N , χ N , τ N , ϕ N is
its fault-aware management protocol. The management behaviour of N can be extended to include unexpected behaviour by replacing O N and τ N with:

-O N = O N ∪ { }, and -τ N = τ N ∪ { s, ρ(s), , s | s ∈ S N } 5 .
The operation, combined with the analyses presented in Sect. 3.3, permits analysing the management behaviour of an application also in presence of misbehaving components: Indeed, the possible unexpected behaviour of a node is modelled by transitions which lead the nodes to their sink state s , where we (pessimistically) assume that the node is not offering any capability any more. This permits us to analyse the (worst possible) effects of a misbehaving node on the rest of the application by simply observing whether and how the global state of the application changes.

Example 4. Consider the back-end's management protocol (Fig. 2), extended by adding back-end as illustrated in Example 2. The extension described in Def. 2 simply consists in adding "crash" transitions starting from not-installed, installed, and running, and leading to back-end (Fig. 5). The management protocols of front-end, apache and debian can be extended analogously.

The above extension permits, for instance, determining the effects of a "crashing" back-end when the whole application is up and running (Fig. 6). By invoking backend's , the global state is changed by updating the state of back-end, and by filling the set of pending faults with the backend requirement of front-end (since it is assumed and connected to the back-end's endpoint capability, which is no more provided). The pending fault is then consumed by a ⊥-transition, which updates front-end's state. transitions can be fired only if the requirements in ρ(s) are satisfied so as to ensure the well-formedness [START_REF] Brogi | Modelling and analysing cloud application management[END_REF] of management protocols. Note that this is not a restriction since such requirements are satisfied are satisfied in s (by Defs. 1 and 2). More interestingly, we may wish to recover an application having a component that is behaving unexpectedly. More precisely, from the global state reached after injecting a failure (by invoking the "crash" operation ), we may wish to find a "recovery" plan whose execution permits reaching a given recovery goal (e.g., the global state in which the failure was injected). Notice that, such a recovery plan cannot be determined by simply visiting of the graph associated with the labelled transition system modelling the management behaviour of an application, as the faulted node is stuck in its sink state (since no transition outgoes from such state).

Hard recovery

Recovery plans can be generated automatically, and the underlying idea is quite simple. When a node N is stuck 6 in state s , it can be "hard reset" by the node N in which it is contained (i.e., by the node in which it is installed or deployed). More precisely, by resetting the container node N , all nodes it contains (among which we have the stuck node N ) are forcibly reset to their initial state and can be re-installed and started to return up and running.

Due to space limitations, we hereby show how to recover the global state directly on our motivating example after the fault injection of Example 4.

Example 5. Our objective is to enforce the hard reset of a node N stuck in its sink state s , by restarting the node in which N is contained. This can be naturally modelled with fault-aware management protocols, provided that the topology is extended with an alive capability to explicitly represent the node containment:

-Since front-end and back-end are contained in apache, (i) we add an alive requirement to front-end and back-end, (ii) we add an alive capability to apache, and (iii) we connect the alive requirements of front-end and back-end alive requirement with the alive capability of apache. -Since apache is contained in debian, (i) we add an alive requirement to apache, (ii)

we add an alive capability to debian, and (iii) we connect the alive requirement of apache to the alive capability of debian.

The updated topology permits to container nodes to witness whether they are still installed (by providing their alive capability), and to contained nodes to check whether they continue to be installed (by assuming their alive requirement). More precisely, it is possible to update the management protocols as shown in Fig. 7, which illustrates the updated protocols of back-end and apache 7 . In each state (other than the initial one), apache and back-end assume their alive requirement, i.e. they assume their containers to continue to be installed. apache is also providing its alive capability in such states, to witness to the nodes it contains (i.e., front-end and back-end) that it continue to be there. Additionally, whenever their alive requirement is removed, apache and backend return to their initial state. This models the fact that, whenever a container is uninstalled, the nodes it contains are uninstalled along with it.

M back-end M apache
With the above updates we are now able to recover the application from the stuck global state in Fig. 6. Essentially, back-end is stuck in back-end , and the only way to get out of it is to remove its alive requirement, which in turn means to shutdown and uninstall apache (to make it stop providing its alive capability). This results in killing also the front-end, which goes back to its initial state. Afterwards, we can re-install and start the apache server, setup and run the back-end and front-end nodes, and connect the front-end (to the back-end).

It can be easily verified that the above listed operations build up a valid workflow permitting the application to be again up and running from the global state reached in Example 4. As we already mentioned, such a plan can simply be determined with a visit of the graph associated with the transition system defined by management behaviour of the application. The only requirement is to use a modelling of the applications that is updated as we discussed at the beginning of this example.

Related work

The problem of automating composite application management is one of the major trends in today's IT [START_REF] Leymann | Cloud computing[END_REF]. Our previous work [START_REF] Brogi | Modelling and analysing cloud application management[END_REF][START_REF] Brogi | Modelling the behaviour of management operations in cloud-based applications[END_REF], as well as Aelous [START_REF] Di Cosmo | Aeolus: a Component Model for the Cloud[END_REF], permit automatically deploying and managing multi-component cloud applications. The underlying idea of both approaches is quite simple: Developers describe the behaviour of their components through finite-state machines, and such descriptions can be composed to model the management behaviour of a composite application. Engage [START_REF] Fischer | Engage: A deployment management system[END_REF] is another approach for processing application descriptions to automatically deploy applications. The approach presented in this paper extends [START_REF] Brogi | Modelling and analysing cloud application management[END_REF][START_REF] Brogi | Modelling the behaviour of management operations in cloud-based applications[END_REF], and differs from [START_REF] Di Cosmo | Aeolus: a Component Model for the Cloud[END_REF] and [START_REF] Fischer | Engage: A deployment management system[END_REF], since it permits explicitly modelling faults and injecting failures in application components, analysing their effects, and reacting to them to restore a desired application state.

The rigorous engineering of fault-tolerant systems is a well-known problem in computer science [START_REF] Butler | Rigorous Development of Complex Fault-Tolerant Systems[END_REF], with many existing approaches targeting the design and analysis of such systems. For instance, [START_REF] Johnsen | Incremental fault-tolerant design in an object-oriented setting[END_REF] proposes a way to design objectoriented systems by starting from fault-free systems, and by subsequently refining such design by handling different types of faults. [START_REF] Qiang | Automatic fault localization for BIP[END_REF] and [START_REF] Betin Can | Eliminating synchronization faults in air traffic control software via design for verification with concurrency controllers[END_REF] instead focus on fault-localisation, thus permitting to redesign a system to avoid the occurrence of such a fault. These approaches differ from ours because they aim at obtaining applications that "never fail", since all potential faults have been identified and properly handled. Our approach is instead more recovery-oriented [START_REF] Candea | Recovery-oriented computing: Building multitier dependability[END_REF], since we focus on applications where faults possibly occur, and we permit designing applications capable of being recovered.

Similar considerations apply to [START_REF] Grunske | Model-driven safety evaluation with state-event-based component failure annotations[END_REF], [START_REF] Kaiser | A new component concept for fault trees[END_REF], and [START_REF] Alhosban | Bottom-up fault management in service-based systems[END_REF], which however share with our approach the basic idea of modelling faults in single components and of composing the obtained models according to the dependencies between such components (i.e., according to the application topology). [START_REF] Durán | Robust and reliable reconfiguration of cloud applications[END_REF] proposes a decentralised approach to deploy and reconfigure cloud applications in presence of failures. It models a composite applications as a set of interconnected virtual machines, each equipped with a configurator managing its instantiation and destruction. The deployment and reconfiguration of the whole application is then orchestrated by a manager interacting with virtual machine configurators. [START_REF] Durán | Robust and reliable reconfiguration of cloud applications[END_REF] shares with our approach the objective of providing a decentralised and fault-aware management of a composite application, by specifying the management of each component separately. However, it differs from our approach since it does permits specifying inter-component dependencies, but it is not possible to describe whether they are "horizontal" (i.e., a component requires another to be up and running) or "vertical" dependencies (i.e., a component is installed/deployed on another). Additionally, it focuses on recovering virtual machines that have been terminated because of environmental faults, while we also permit describing how components react to application-specific faults. [START_REF] Liggesmeyer | Improving system reliability with automatic fault tree generation[END_REF] proposes an approach to identify failures in a system whose components' behaviour is described by finite state machines. Even though the analyses are quite different, the modelling in [START_REF] Liggesmeyer | Improving system reliability with automatic fault tree generation[END_REF] is quite similar to ours. It indeed relies on a sort of requirements and capabilities to model the interaction among components, and it permits "implicitly" modelling how components behave in presence of single/multiple faults. Our modelling is a strict generalisation of that in [START_REF] Liggesmeyer | Improving system reliability with automatic fault tree generation[END_REF], since a component's state can change not only because of requirement unsatisfaction but also because of invoked operations, and since it permits "explicitly" handling faults (i.e., fault handling transitions are distinct from those modelling the normal behaviour of a component). Similar considerations apply to [START_REF] Chen | Fault propagation formal modeling based on stateflow[END_REF], whose modelling is also based on finite state machines with input and output channels (which permit fault communication and propagation by components).

UFIT [START_REF] Hajisheykhi | UFIT: A tool for modeling faults in UPPAAL timed automata[END_REF] is a tool for verifying fault-tolerance of systems. It permits modelling systems' behaviour with timed automata, some of whose transitions explicitly represent how the system reacts to the occurrence of faults. Even if it models fault transitions in a way similar to ours, UFIT differs from our approach since it targets standalone systems and does not provide any mechanism to easily compose the automata modelling the behaviour of multiple systems.

Other approaches worth mentioning are [START_REF] De Lemos | An architectural support for self-adaptive software for treating faults[END_REF] and [START_REF] Nagatou | A model-checking based approach to robustness analysis of procedures under human-made faults[END_REF]. The way in which our approach models fault-awareness by relying on the interactions between components, as well as the idea of analysing/recovering faults through sequences of atomic transactions (until a desired state is reached), are indeed inspired by [START_REF] De Lemos | An architectural support for self-adaptive software for treating faults[END_REF]. Instead, the idea of relying on fault injection to determine the effects of unpredictable faults is inspired by [START_REF] Nagatou | A model-checking based approach to robustness analysis of procedures under human-made faults[END_REF].

In summary, to the best of our knowledge, the approach we propose in this paper is the first that permits automatically orchestrating the management of composite applications under the assumption that faults possibly occur during such management, thus requiring to explicitly model how an application reacts to their occurrence. It does so by following the common idea of modelling each component separately, and of deriving the management behaviour of a composite application by properly combining the behaviour of its components.

Conclusions

Management protocols [START_REF] Brogi | Modelling and analysing cloud application management[END_REF] are a modular and reusable way to model the management behaviour of application components, and to automate the management of a complex applications composed by multiple components.

In this paper we have extended management protocols by taking into account the possibility of faults suddenly occurring, as well as of misbehaving components. More precisely, we have shown how to include faults in management protocols, and how to model components' unexpected behaviour. We have also shown how to derive the fault-aware management of a composite application by simply composing the protocols of its components. Finally, we have discussed how the proposed modelling permits automating various analyses (e.g., determining whether a workflow orchestrating the management of an application is valid, which are its effects, whether it generates faults, or recovering an application that is stuck because of a faulted/misbehaving node).

The presented approach can be exploited for developing engines capable of automatically orchestrating the management of composite application in a faultresilient manner. Indeed, given a desired application configuration, an orchestrator can automatically execute the sequence of operations needed to reach such configuration, and it can maintain such configuration even if faults or unexpected behaviours suddenly occur.

Please note that, even if some of the analyses we presented in Sects. 3 and 4 have exponential time complexity in the worst case, they still constitute a significant improvement with respect to the state-of-the-art, as currently the management of the components of a complex application is coordinated manually (e.g., by developing ad-hoc scripts), and it is hardly reusable since it is tightly coupled to such application.

It is important to observe that our approach can be easily adapted to cope with applications whose topologies are dynamic. Indeed, to deal with applications whose components may dynamically (dis)appear, we only need to add such components to the application topology, and to update the binding function relating requirements and capabilities. A formalisation of what above is in the scope of our immediate future work.

Another (obvious) extension for future work is to validate the approach we presented in this paper on concrete case studies. In this perspective, we plan to provide tools permitting to model and analyse fault-aware management protocols. More precisely, we plan to (i) properly extend Barrel [START_REF] Brogi | Modelling and analysing cloud application management[END_REF], an open source tool exploiting management protocols for describing and analysing the management of composite TOSCA applications, and (ii) to develop a prototype automatically generating concrete workflows orchestrating the fault-aware management of TOSCA applications.

We also plan to extend the analyses that can be performed on fault-aware management protocols. For instance, we plan to devise techniques permitting to improve our analyses by determining fragments of the topology that can be managed independently from the rest of the topology. This would permit a smarter and more efficient reasoning, as the search space could be reduced by focusing only on the interested fragment(s).

Fig. 1 .

 1 Fig. 1. Motivating example.

Fig. 2 .

 2 Fig. 2. Examples of management protocols.

Fig. 3 .

 3 Fig. 3. Example of completed management protocol.

Definition 3 .

 3 Let A = T, b be a composite application, and let N = S N , R N , C N , O N , M N . A global state G of A is a set of states such that:

Definition 4 .

 4 Let A = T, b be a composite application, and let N

Definition 5 .

 5 Let A = T, b be a composite application. The sequence o 1 o 2 ...o n of management operations in A is valid in a global state

Fig. 4 .Fig. 4 .

 44 Fig. 4. Examples of (a) valid workflow and (b) valid sequence of operations.

5

 5

Fig. 5 .

 5 Fig. 5. Example of a management protocol including unexpected behaviour.

Fig. 6 .

 6 Fig. 6. Example of fault injection and subsequent global state update.

Fig. 7 .

 7 Fig. 7. Example of management protocols with alive requirements and capabilities.

  a set of quadruples modelling the transition relation, i.e. s, H, o, s ∈ τ N denotes that in state s, and if the requirements in H are satisfied, o is executable and leads to state s , and

Misbehaving components can be detected via monitoring (e.g., by exploiting watchdogs or heartbeat services). We shall not deepen into details, as component monitoring is outside of the scope of this paper.

The constraints to ensure a deterministic semantics of fault-aware management protocols can be trivially formalised by extending those presented in[START_REF] Brogi | Modelling and analysing cloud application management[END_REF]. In the following we consider management protocols that satisfy such requirements.

It is easy to prove that the proposed completion preserves the determinism of a management protocol.

For simplicity, and without loss of generality, we assume that, given two nodes in a topology, the names of states, requirements, capabilities, and operations are disjoint.

In general, hard recovery can be exploited for recovering a desired global state whenever a node is stuck in its sink state.

We omit the updated protocols of front-end and back-end due to space limitations, and since their update is analogous to that of back-end and apache.

Acknowledgements. This work has been partly supported by the project Through the fog (PRA 2016 64) funded by the University of Pisa.