# Investigation of Microservice-Based Workflow Management Solutions for Industrial Automation
## 2 Background and Related Work
### Microservice Architectures  
Microservice architecture originated from SOA, which was introduced by IBM in the mid-1990s [15]. Following the increase in popularity of SOA, the Organization for the Advancement of Structured Information Standards (OASIS) created the SOA reference model (SOA-RM) [16] to standardize its concepts in a common vocabulary. As SOA implementa  
Figure 2: The workflow reference model, adapted from [11].  
tions matured and the term attracted increasing attention, its definition broadened, losing precision ([[https://martinfowler.com/bliki/ServiceOrientedAmbiguity.html](https://martinfowler.com/bliki/ServiceOrientedAmbiguity.html)]([https://martinfowler.com/bliki/ServiceOrientedAmbiguity.html](https://martinfowler.com/bliki/ServiceOrientedAmbiguity.html)), accessed on 10 December 2022). However, practitioners still required precision when communicating architectural terms and architectures evolved to overcome the complexity of certain SOA deployments. Eventually, a new term, \"microservice architecture\", was coined as an evolution of the original concepts. Differences are highlighted in the communication between services--where microservice architectures promote lightweight communication protocols and simpler mechanisms for connecting services, not always relying on orchestration [17]. From a fundamental perspective, disregarding the scope of use, the two architectures can be considered equivalent for our purposes, as they share the basic principles of service orientation [18].  
The pillar of microservice architecture is the encapsulation of functionality in services that can be provided to, or consumed by, other software systems. The design of services is considered the defining feature of service-based architectures. It enables independent software development unconstrained from the rest of the systems in the architecture, by having only a few dependencies among services. Additionally, software lifecycles are decoupled, as each service can evolve at its own pace without the coupling of legacy architectures, while service functionality is independent of any other software system, the degree to which the services are responsible for their own data can vary. There are two main design approaches to data persistence within services:  
* Stateful services: Each service needs to store the communication state and keep track of the exchanges, reacting differently depending on previous requests.
* Stateless services: The services are not required to record the state of communications. Consumers will obtain the same response regardless of any previous exchanges between the systems.  
In the case of stateful services, developers can proceed in two ways: (1) designing services to carry their own database, as in microservices, or (2) have a shared database that is accessible by the authorized services, which is more common in SOA [19].  
Although microservice architectures are currently the main approach followed by companies looking to realize the automation and digitalization of their processes, there is no single correct methodology for such implementation, as each author is promoting their approach. Instead, there are several platforms that support organizations with the transition, providing the infrastructure for concrete microservice solutions, e.g., FIWARE [20], Eclipse BaSyx [21], and Eclipse Arrowhead [5; 22]. In this work, the use of the Eclipse Arrowhead reference implementation is associated with the research projects funding this study and the analysis that links the essential properties of \"look-up\", \"late binding\", and \"loose coupling\", shared by SOA and microservice architectures, to the mandatory systems of the framework [23]. A recent comparison of the most relevant initiatives related to automation and digitalization can be found in [24].