Business Object Centric Microservices Patterns

Abstract

A key impediment towards maturing microservice architecture conceptions is the uncertainty about what it means to design fine-grained functionality for microservices. Under a traditional service-oriented architecture (SOA), the unit of functionality for software components concerns individual business domain objects and encapsulated operations, enabling desirable architectural properties such as high cohesion and loose-coupling of its components. However, at present it is not clear how this SOA design strategy should be refined for microservices nor, more generally, how design considerations for different degrees of granularity apply, in a consistent and systematic way, for large SOA systems to smaller microservices. This paper proposes microservice patterns, as a contribution to the maturity of microservice architectures, through the refinement of the functional structure of SOAs. The patterns are derived by considering the splitting of business object (BO) operations and salient types of BO relationships, which influence software structure (as captured in UML): object association, exclusive containment, inclusive containment and specialisation (i.e., subtyping). The viability of the patterns for evolving large SOA systems into microservices is demonstrated through automated microservices discovery algorithms, on two open-source enterprise systems used widely in practice, Dolibarr and SugarCRM.

Defining and measuring microservice granularity—a literature overview

“…Average of network. The average network bandwidth consumption for the entire system; Kb/s used by system or microservice ( De Alwis et al, 2019 ).…”

Microservice Remodularisation of Monolithic Enterprise Systems for Embedding in Industrial IoT Networks

“…Such semantic relationships are highlighted by Pẽrez-Castillo et al's experiments [15], in which the transitive closure of strong BO dependencies derived from databases was used to recommend software function hierarchies, and by Lu et al's experiments [16], in which SAP ERP logs were used to demonstrate process discovery based on BOs. Also, our own previous research on microservice discovery based on BO relationship evaluation [17,18] showed the impact of considering semantic structural relationships in software remodularisation. However, to date, techniques related to semantic structural relationships have not been integrated with static syntactic techniques at the method level.…”

“…More recently, semantic knowledge available through BOs of enterprise systems has been exploited to improve the feasibility of applications' architectural analysis [16]. Our previous research on MS discovery from enterprise systems for cloud deployments, involving analysis of source code and systems logs, similarly exploits knowledge of BO relationships [17,18]. This was based on class-level feature set extractions for software remodularisation analysis: structural inheritance relationships (class supertypes and subtypes), structural interaction relationships (class level creations and invocations), structural class similarity (intra-class level), and class semantic properties (class and BO dependencies for BOs managed through classes).…”

Remodularization Analysis for Microservice Discovery Using Syntactic and Semantic Clustering

“…Such semantic relationships are highlighted by the experiments conducted by Pẽrez-Castillo et al [12], in which the transitive closure of strong BO dependencies derived from databases was used to recommend software function hierarchies, and by the experiments conducted by Lu et al [13], in which SAP ERP logs were used to demonstrate process discovery based on BOs. Research conducted by De Alwis et al [14,15] on MS discovery based on BO relationship evaluation shows the impact of considering semantic structural relationships in software remodularization. However, to date, techniques related to semantic structural relationships have not been integrated with syntactic structural relationships and structural class similarity techniques.…”

“…In this matrix, again, rows correspond to classes, and columns correspond to unique words identified in step three of the algorithm that appear in the corresponding classes. The values in uwcount are then used in the sixth step to calculate the cosine similarity between the documents using COSINECAL function (see lines [12][13][14]. First, this function normalizes the term frequencies with the respective magnitude L2 norms.…”