## 2 Background  
SoA has been a widely accepted and employed avenue for developing complex and distributed applications that usually connect through the Internet. The integration mechanisms supported through process models that are intuitive and graphical actually present an invaluable approach to development. They leverage the world market of web services that provide any kind of functionality and that are already written, tested, and published. The need to create more flexible and scalable systems leads to moving attention from developing monolithic applications to independently functioning microservices. With each managing their own data storage, microservices, which are potentially written in different languages, use lightweight protocols, such as HTTP and REST. As the focus is independent deployment, scaling, and testing, microservices require a bare minimum centralized management [14; 15]. Our previous work focused mainly on the structure dimension [16], which actually corresponds to the decomposition view of Software Architecture approaches. We later realized that our research neglected an analysis of an important issue--dynamic modeling.This need has been addressed in UML through sequence diagrams or activity diagrams and in SoA by the process model. Another very powerful concept offered by the SPL approaches, namely the domain conceptions presented through feature models and variability, has also been inspirational. SPL constitutes an environment for the construction of a set of software systems from core assets by feature management, thus making it easier to satisfy specific requirements. Common assets lie at the core of the development; therefore, the handling of these assets is crucial, in addition to variability management in the creation of a final product. Ref. [17] specified a requirement for a framework with two distinct processes: domain engineering and application engineering, with the first one being for the characterization and realization of necessary assets and the latter for the production of distinctive applications under the guidance of variability. A final product is created as a result of systematic decisions on variability resolution throughout the development phases. Each design decision corresponds to a variation point by incorporating/eliminating features. Delayed design decisions improve the efficiency of SPL by allowing the core assets to be used along with changing requirements [18]. This can be supported through variability, especially with later resolution times. Some early approaches have been used for utilizing domain feature models in order to resolve variability; however, they were complicated because variability was accommodated in an already populated feature model. The Orthogonal Variability Model (OVM) [17] and Covamof [19] are some of the pioneering variability models that stand alone outside of feature models. In an effort to orchestrate these concepts in the environments to further develop complex software more easily, some research was conducted regarding methodology. The decomposition of the structural view governing the components or the web services was later supported by configuring a process model for the integration and flow-control specifications. The latter addition enabled the ordering of method invocations to complete the definition of executable systems. Although today no development process should dictate a linear order of tasks, such as that of Waterfall, some priority for the modeling dimensions that would correspond to the abstraction levels of design was necessary. To support our expectations, the limited studies conducted in Ref. [20] showed that the process model can have a priority over the component model, as has practically been the case in the SoA world, in which an implied two-level architecture is the hidden de facto standard: A process model at the top commands the web services at the bottom.