## 4 Model and Design of SPIDEP Platforms
### Variants of Software Architectures
#### 4.2.1 SPIDEP SOA Variant: Platform Design  
The first proposed platform (SPIDEP-SOA) is intended to manage the interactions between users (consumers in the upper layer) and health services (software functionalities in the lower layer), according to the changing needs of the platform (technology, demand and security), as shown in Figure 1.  
Next, we will briefly outline our first variant of the platform, which consists of six layers focused on the management of services under the computational paradigms (i.e., Edge and Cloud) [23], as follows:  
* Consumers: This layer allows interaction and exchange between the health professionals of the different homes (nurses and assistants), the hospitals in charge of each region (general physicians) and the eHealth applications (SPIDEP or others). * Edge layer: Establishes HTTP connections with the APP for the asynchronous sending of medical data in the Cloud (i.e., the Cloud layer) [33], whose data come from the different users and their sets of biometric sensors (i.e., blood pressure, pulse rate, body temperature, oxygen saturation and electrodermal activity) [23]. It should be noted that this communication is encrypted by the security layer. * Cloud layer: This layer performs heavyweight computations; that is, it helps consumers discover, route and deploy health services and infrastructure. In addition, this layer consists of the three sections of infrastructures and resource, support functions and control system. Additionally, different algorithms are used to achieve various objectives (e.g., error tolerance and load balancing) [74]. * Service layer: Contains services for the end users like medical personnel and nursing home administrative staff with their respective profiles. * Security layer: Ensures access control and consumer authentication through established security policies, whose objective is to determine the user privileges for certain resources and/or specified levels of services. * Management system: This layer mainly controls the flow of messages between the different layers. In addition, it is responsible for executing the real-time adaptation of the services (versatility) according to demand, e.g., automatically adding a new instance, monitoring the status of the different components that integrate the platform or other monitoring tasks. It should be noted that this variant of SPIDEP was a refactoring of the legacy application [23] whose purpose was the modernization of existing services oriented to our current software attribute (i.e., versatile high-performance) [64]; however, the strengths and weaknesses of SOA must be considered. Considering the above, the strengths of SOA are the following:  
* Provides a higher level of compression related to the abstraction of the interfaces than MSA (decoupling) [62], since SOA traditionally has the integration of an enterprise service bus (ESB) [75], which facilitates the interaction between the services of the platform. * Offers extensive knowledge that has been established over more than a decade, which has proven to be effective and reusable in building platforms. It is thus easier for developers to ensure the quality of service required by the organization [76]. Figure 1: General scheme of the services applied in the SPIDEP platform under the SOA variant (SPIDEP-SOA). * Suitable for large and heterogeneous systems consisting of many applications, non-independent services and shared components [33; 77]. It provides a roadmap for the adoption of its principles, which allows developing or transforming the capabilities of an organization's software system into reusable services for greater flexibility and agility [78]. However, when applying SOA, the following weaknesses or difficulties must be considered:
* Message exchange is traditionally synchronous (wait-to-connect); i.e., it depends on the state of the ESB [33].