The Service-oriented Process for Reengineering and DevOps (SPReaD) is an instantiation of the Mainstream SOA Methodology (MSOAM) [5, 6]. MSOAM is a reference model for SOA project delivery, providing a set of generic activities and practices that needs to be customized for its usage. We organized the MSOAM activities on a reengineering process based on the software engineering process framework described by Pressman and Maxim . Their framework identifies five generic phases applicable to all software projects: (i) Communication, (ii) Planning, (iii) Modeling, (iv) Construction and (v) Deployment. In the context of SPReaD, the Modeling phase is divided into Analysis and Design, the Construction phase is divided into Code and Test and the Deployment phase is divided into Delivery and Support and Feedback. The diagram in Fig. 1 presents an overview of the SPReaD process structure; the MSOAM activities are represented as blue rectangles.
SPReaD, as depicted in Fig. 1, comprises a Software Reengineering Process followed by a DevOps process. The rengineering part of SPReaD consists of a Reverse Engineering phase followed by a Forward Engineering phase. The Reverse Engineering phase corresponds to the Analysis activity, whereas the Forward Engineering phase comprises the Design, Code and Test activities. Moreover, the DevOps part of the process consists of a CI + CDE + CD phase followed by a Monitoring phase, corresponding, respectively, to the Delivery activity, and to the Support and Feedback activity.Footnote 3
The phases of SPReaD described above are applied iteratively to plan, model, build, and deliver one or more service inventories, which determine the scope and goal of a given iteration. In the next sections, we further detail the Modeling, Construction and Deployment phases of SPReaD. Due to space limitations, the Communication and Planning phases will not be covered in this article.
The Modeling phase comprises the Analysis and Design activities. We further detail these activities next in Sections 3.1.1 and 3.1.2. The Design activity is the begin of the Forward Engineering part of the reengineering process; it comprises the Service-Oriented Design and Service Logic Design activities.
In the context of SPReaD, the analysis activity corresponds to the Reverse Engineering part of the Software Reengineering process; it includes the Service Inventory Analysis and Service Oriented Analysis activities. Figure 2 details these activities.
The Service Inventory Analysis activity is responsible for producing the conceptual definition of service inventories. These inventories are documented in the Service Inventory Blueprint artefact, which describes main services of the target system. In the context of SPReaD, the Service Inventory Analysis comprises three main practical steps: (i) Identify Bounded Contexts, (ii) Identify Service Candidates, and (iii) Apply Context Mapping.
In the first and second steps, we employ the Bounded Context technique borrowed from Domain-Driven Design (DDD) . Bounded context is used in DDD to isolate a domain-specific responsibility on an explicit interface boundary which decides which models to share with other contexts [20, 21]. This technique is employed to delimit the applicability of certain models and keep them logically unified and consistent. It is applied over the business services identified in the legacy monolithic application, i.e., the different Web pages (view and middle-tier components) and models of the legacy system. These are then labelled and conceptually isolated into bounded contexts. In this process, legacy services and entity models that contain multiple responsibilities are separated into distinct elements. In the end, each bounded context corresponds to one candidate microservice, where each service of the legacy system corresponds to a capability to be offered by the identified microservice. These are then organized into Service Inventory Blueprints indicating the main domain contexts. An inventory may contain one or more bounded contexts depending on the inventory’s business scope.
In the third step, we employ another DDD technique called Context Mapping. In a monolithic architecture, the communication between the components of the legacy system can happen unrestrictedly, as they all share the same core. Since we are decomposing this core in separate bounded contexts that are distributed into services, it is necessary to devise communication strategies between them, which can take different forms. Thus, we employ Context Mapping, which performs an integration pattern  to classify the relationship between external contexts and internal contexts.
The Service Oriented Analysis activity is responsible for creating new software documentation (Class Diagrams, Relational Entity Diagrams, Use Cases, etc.) to support the Forward Engineering process. This documentation helps explaining the scope of each inventory and its candidate services. The activities associated with analysis follow a set of practices, which are described in the sequence.
Having identified inventories and their candidate services, the practice to be adopted in service-oriented analysis is the beginning of the decomposition of the legacy service. This decomposition occurs by extracting the service logic from the Web page components (View and Middle-tier) in two focuses of analysis: one focus to identify behaviors and models that satisfy the logic associated with the graphical interface; and the other focused on service logic, which identifies the capabilities and business entities of the service. This results in artefacts as user interface prototypes, and service contracts and design. These are then used for the re-specification, re-design, re-architecture and re-codification of new user interfaces and service logic.
Figure 3 illustrates the flow of activities from Service Oriented Design and Service Logic Design. Service-Oriented Design aims to re-design the software solution with a focus on reuse, as well as redefining the software architecture to express the new design features. In support of re-design, we adopt the service layer pattern  where services are categorized as: a) entity services, which is a reusable service with an agnostic functional context associated with one or more related business entities; b) task service, which is a non-agnostic functional context that generally corresponds to the logic of the single-purpose parent business process; c) utility service, which is also a reusable service with an agnostic functional context, but this type of service is intentionally not derived from specifications and business analysis models.
In turn, the activity of Service Logic Design is responsible for completing the service logic, by defining a set of information such as the version of the service, its access policies, contract schemes and routes for accessing APIs, etc.
The result of Design is the specification of the service architecture components in terms of its modeling through structural diagrams, such as UML component and class diagrams. In addition, the set of metadata created will allow the construction of service contracts, which will facilitate the discovery of its capabilities.
SPReaD follows a design approach based on service layers and micro-task segregation. Figure 4 exposes the definition of what a microservice structure should look like. It is composed of an API layer that is responsible for handling HTTP/REST requests, including authentication and authorization in accessing resources, through facades to orchestrate the service logic. The API layer contains façades based on the service layers pattern. The application layer adopts the CQRS standard approach (Command Query Responsibility Segregation) , to separate the application into two flows: a writing stream called Command, in which we can find domain models and services to deal with business logic; and a Query flow, in which data transport objects (DTOs) that correspond to the service consumers’ query operations reside. The cross-cutting layer provides a set of cross-domain components to abstract infrastructure resources, as well as to deal with the state maintenance of service objects.
Based on this model, the implementation of each microservice can be standardized to reflect a product with greater autonomy. In addition, the reduced and specialized scope of each microservice, as well as better componentization of the application layers and abstraction of the cross-cutting layer favor its portability and maintainability. Finally, by transferring the state of objects to infrastructure layers and adopting strategies for separating the application flows in writing and reading by adopting CQRS, the system gains a potential to achieve wide horizontal scalability and significantly improve its performance.
This phase involves the activities of code and test, which are related, respectively, to the activities of Service development, in which the actual service is implemented; and Service test, where software testing techniques are employed. They complete the forward engineering cycle within the software reengineering process.
Figure 5 details the flow of the service development activity. SPReaD is based on two approaches for service implementation: Service API Implementation and Software Migration.
The first approach, Service API Implementation concerns the development of the service contract defined by the Service Oriented Design in a scenario where the desired capability is not provided by an existing component of the legacy system. Based on the service contract, the service logic is designed and implemented, followed by the application of security concerns over the developed service.
The Software Migration activity is applied to legacy software in order to transport the service to a new software structure. For this, two techniques can be applied: the functional decomposition or wrapping . Functional decomposition is used to extract entities and service logic from the legacy software. Those are encapsulated into business components that correspond to the designed service architecture. The wrapping technique is used to encapsulate legacy software with high complexity and an associated high migration cost. These usually involve shared resources, classes for infrastructure access, or external services. Finally, access to the migrated components is regulated by the creation of a service facade, which hides all the complexity in the software.
In some cases, the service contract needs to be made available before the service logic itself. For example, external teams hired to develop the front-end may demand access to the contract to proceed with the construction of GUI’s (Graphic User Interfaces). In this scenario, the Web API is made available before the construction of the business component.
The SPReaD process does not define any specific step for the Service Test as different approaches can be employed according with the practices of the development team and the resources available. The use of unit tests is the basic recommended approach, with integration testing becoming necessary as the number of services deployed grows. This is also a situation that might require the availability of Web API before the construction of business components. Finally, black-box testing is used with those services that encapsulate legacy components.
The deployment phase involves the activities delivery and support and feedback. They are responsible for managing the deployment of services into production and their monitoring. The delivery activity is based on the MSOAM’s activity of service deployment and maintenance, while support and feedback is based on MSOAM’s service usage and monitoring, and service discovery.
The delivery activity corresponds to the service deployment and maintenance phase of MSOAM and explores the use of DevOps technique (continuous integration, continuous deployment, and continuous delivery). Figure 6 details this activity.
It starts by performing a continuous integration pipeline, which includes the integration of source code followed by its compilation (build application), automated tests and code analysis. These create reports containing integration and compilation information, indicators regarding test coverage and calculated technical debt.
When those activities succeed, the resulting package is delivered to an homologation environment (continuous delivery). In case continuous deployment practices are in place, the resulting package is deployed on a production environment. Otherwise the deployment in production is a manual process and thus this phase of the process is considered as ended.
Support and feedback
The support and feedback activity, detailed in Fig. 7, is mainly concerned with services that have been deployed and used in production environment. It includes MSOAM’s service usage and monitoring, service discovery, and service versioning and retirement.
Service usage and monitoring is concerned with the collection, storage, processing, and visualization of different information about the services. It can include metrics used for performance, billing, scalability, and business logic-related information, such as logging. These are used by operations teams as means of monitoring the supporting infrastructure and by management teams to understand business dynamics through service consumption.
Service discovery concerns the provision of a repository, i.e., a service registry, where all services from the different inventories can be discovered. In essence, such repository allows the registration and querying of service metadata exposing the business capabilities and details of the active service instances, such as services contracts and endpoints.
The last activity, service versioning, and retirement, is responsible for supporting changes in existing services, such as changes to its logic or contract, with minimal disruption to existing service consumers. This requires version control tools and mechanisms, as well as tracking. Regarding versioning, the use of specifications such as Semantic Versioning plus the adoption of code version control tools such as Git can assist in managing service changes. With regard to tracking, the use of Service Catalogs in addition to the use of monitoring tools such as the ELK stackFootnote 4 can indicate whether certain services continue to be used and by which customers, facilitating the planning of withdrawing services without consumption.