CA-BPEL: A New Approach to Facilitate the Development and Execution of Context-Aware Service Orchestrations

The proliferation of smartphones and sensor-based networks has led to a greater need for context-aware applications and pervasive business processes. One of the key approaches that seek to satisfy this need is context-aware service composition. Service composition can be achieved in two ways, i


Introduction
The proliferation of smartphones and advances in technologies such as RFID and sensor-based networks have led to an increase in the popularity of context-aware applications and pervasive business processes (Baldauf et al., 2007;Sheng et al., 2014). Context-aware applications and processes exploit contextual data and information associated with the user and environment entities to automate user activities or make better decisions (Faieq et al., 2021). There exists a wide range of contextual information, e.g., the user's geographical and temporal situation, the user's mood, the user's device battery status, available mobile networks, and the weather status (Moradi et al., 2020;Yigitbas et al., 2020).
Context plays an increasingly important role in business process management (BPM) literature (Vom Brocke et al., 2021). Considering context awareness is critical for managing business processes successfully (Janiesch and Kuhlenkamp, 2019;Vom Brocke et al., 2021). Gartner (2019) identified real-time situational awareness as an essential capability of next-generation intelligent BPM suites (Gartner, 2019;Zhao et al., 2021). Kerpedzhiev et al. (2021) explored the capabilities of future BPM systems through a Delphi study and emphasized that process context management (including context specification, detection, monitoring and change handling) is a central capability that should be covered by future BPM systems (Kerpedzhiev et al., 2021;Vom Brocke et al., 2021).
According to Gartner (2022), composable applications are among the top 12 strategic technology trends in 2022. The composition of services is one of the common strategies for implementing business processes (Nikoo et al., 2020). Service composition, which refers to a combination of multiple services into a more extensive composite service, is classified into choreography and orchestration (Papazoglou and van den Heuvel, 2007). Service orchestrations can be implemented using "standard executable business process languages" such as Business Process Execution Language (BPEL) and Business Process Model and Notation (BPMN) (Lübke and Pautasso, 2019). WS-BPEL, which is a popular standard language to specify enterprise-wide service orchestrations (Botangen et al., 2020;Nikoo et al., 2020), is the "first standard language, emphasizing the fully executable aspect of process models" (Lübke and Pautasso, 2019).
Pervasive context-aware service composition (CASC) enables users to employ dynamic yet composed web services that take contextual information into account (Zhou et al., 2011). In the service composition domain, context refers to any information associated with service users, service requesters, service providers, or the execution environment that may affect the composite service execution (Laleh, 2018). A tourism context-aware recommendation service is an example of a real-world CASC that recommends a customized tourism programme according to the contextual information of tourists, tourism service providers and weather conditions (Baidouri et al., 2012).
Embedding the context into an orchestrated service enhances the business process flexibility (Vom Brocke et al., 2021;Zhou et al., 2011); however, the development and execution of context-aware service composition may be practically complicated and time-consuming. The reasons include diversity and heterogeneity of context concepts and sources, the need to comply with the service composition standards, the temporal and uncertain nature of context values, and the limited resources (such as memory and battery life) of the devices running the applications (Moradi et al., 2020;Sheng et al., 2014). Accordingly, this paper aims to introduce a technique to address the complexity of CASC development and execution.
To achieve this goal, we propose to follow a model-driven development (MDD) approach to generate WS-BPEL-compliant service compositions that are fully compatible with standard service composition execution engines (Hagin, 2011;Ibrahim, 2012). Although the MDD technologies seem to produce promising results for standard service compositions, we may face various challenges when applying them in the CASC domain, since they do not consider contextual information while service compositions are developed or executed (Ibrahim, 2012). Some studies (Furno and Zimeo, 2014;Kocurova, 2013;Schefer-Wenzl and Strembeck, 2013) have used a proprietary solution, inconsistent with industry-accepted standards, making their acceptance a severe challenge. Several existing techniques (Cherif et al., 2016;Furno and Zimeo, 2014;Hagin, 2011) have also embedded contextual information into composite services. For example, Hagin (2011) provided a CASC approach, in which context is exposed as an independent web service, and a WS-BPEL-compliant composite service is integrated into a context service. Our investigations revealed that related studies either support limited dimensions of contextual concepts or have weaknesses in embedding context awareness into a standard composite service. Additionally, no experimental confirmation is reported that the current techniques can reduce the complexity of CASC development and execution.
To resolve the limitations of existing studies, this paper proposes a new solution to facilitate the CASC development and execution. In the first step of this research, we investigated existing studies in the CASC domain and proposed 13 requirement specifications (R1 to R13). To meet R1 to R13, we followed both MDD and Context-as-a-Service (CaaS) approaches and presented a new approach called CA-BPEL (Context-Aware Business Process Execution Language). The CA-BPEL approach facilitates CASC development and execution by introducing a new middleware called PCASO (Pervasive Context-Aware Service Orchestration). CA-BPEL also utilizes standard WS-BPEL-compliant tools along with our previous framework, called CaaSSET (Context-as-a-Service Set of Engineering Tools) (Moradi et al., 2020).
In the CaaSSET work (Moradi et al., 2020), we elaborated on a novel MDD framework in the CaaS domain, along with its five components. CaaSSET (Moradi et al., 2020) focused on modelling, developing and delivering context as a web service. CaaSSET is related to the context service provider layer. However, this research focuses on the context service consumer layer and provides a new solution to facilitate CASC development and execution. Hence, the main contributions of this paper are as follows: • Requirements R1 to R13: By reviewing existing works in the CASC domain, an initial list of requirement specifications is proposed. This list is revised during the development of the CA-BPEL approach. Finally, we propose 13 requirement specifications (R1 to R13) for CASC development and execution. • CA-BPEL approach: CA-BPEL leverages both MDD and CaaS approaches to facilitate CASC development and execution. Our proposed approach is a non-invasive one that incorporates context awareness features into a WS-BPEL model without altering the original meta-model of the WS-BPEL language. • PCASO middleware: It consists of a reference model and five intermediate web services. PCASO enables developers to turn a standard composite service into a WS-BPEL-compliant context-aware composite service. PCASO also facilitates the interoperability of standard composite services and context web services.
To evaluate CA-BPEL, we compare it with 14 baseline techniques. We also show the usefulness of CA-BPEL in the context of CASC by conducting a demonstration in the tourism domain. The judgment on the convenience of CASC development and execution is entirely dependent on satisfying the ease of context service development and delivery by the CaaSSET toolset. Hence, we evaluate this toolset by conducting a usability survey.
The remaining sections of this paper are organized as follows. In Section 2, the methodology and scope of our research are explained. Section 3 presents the research background and literature. Section 4 introduces a list of 13 requirement specifications. Our proposed solution to satisfy the identified requirements is explained in Section 5. Section 6 shows the advantages and usefulness of the CA-BPEL approach by conducting a tourism demonstration, along with a usability evaluation survey. Finally, Section 7 concludes the paper and presents some ideas for future work.

Research Method and Scope
Research methodology: The methodology of this research is based on the Design Science Research Methodology (DSRM) presented by Peffers et al. (2007). Figure 1 shows the six steps of the mentioned methodology and the techniques used in each step.  Peffers et al. (2007) Our methodology begins in the first step with the explanation of the research problem and identifying the challenges related to CASC development and execution. In the second step, an initial list of requirement specifications is provided. In the third step, the proposed research solution is designed and implemented based on the initial requirement list. Note that our proposed research artifact is revised according to the evolutional and incremental development method, and after several revision stages, we present the final version of the proposed artifact. In the fourth step, we use our proposed artifact to develop a contextaware composite service in the field of tourism that can be executed on a standard service composition engine. In the fifth step, the proposed research solution is evaluated. In the final step, conclusions are made, suggestions for future work are presented and research results and achievements are published.
Research scope: Service composition is classified into service choreography and service orchestration. In service choreography, there exist equivalent services that can communicate together without any central coordinator service. In contrast, in the service orchestration approach, there is a coordinator service that orchestrates the underlying services (Papazoglou and van den Heuvel, 2007). WS-BPEL is a de facto standard language to specify enterprise-wide service orchestrations (Botangen et al., 2020). Due to the various applications of service orchestration in the management of business processes and the widespread acceptance of the WS-BPEL standard by industries and universities (Lübke and Pautasso, 2019, Botangen et al., 2020;Nikoo et al., 2020), this research focuses on WS-BPEL-compliant context-aware service orchestration. Thus, context-aware service choreography is out of the research scope and may be the subject of future research. Hence, whenever this paper refers to service composition, it means service orchestration.

Background
This section briefly reviews the research background and literature, including contextual data and information, CASC, CaaS and MDD. Salber et al. (1999) defined context as "any information that can be used to characterize the situation of an entity". They also defined the entity (context-aware object) as an object, person or place relevant to a user's interaction with an application.

Contextual data and information
Context is classified into two general categories: primary and secondary (Perera et al., 2014). Primary context refers to context elements (contextual data), and secondary refers to high-level contexts (contextual information) (Moradi et al., 2020). Moradi et al. (2020) defined the context element as a set of context attributes, dealing with low-level contextual data and the high-level context as "the state of a context-aware object (entity) from a specific perspective". For example, data received from GPS sensors (e.g., longitude: 5677183.0 and latitude: 51.528308) is the context element, while the geographical location (e.g., the current city: London) that is inferred by data processing is the high-level context (Perera et al., 2014;Moradi et al., 2020).

Context-aware service composition (CASC)
Combining several services to build a composite service is called service composition. The resulting composite service can be re-composed with other services to create more abstract yet useful composite services (Papazoglou and van den Heuvel, 2007). The proliferation of context-aware applications has increased the need for CASC development. In CASC, contextual information is considered while services are composed. This kind of composite service will be more flexible than standard composite services since the service composition adapts itself to the user entity's current situation (Zhou et al., 2011).

Context-as-a-Service (CaaS)
Developing a standalone context-aware application that manages all aspects of the context model is costly, time-consuming and complex (Chabridon et al., 2013;Moore et al., 2014;Vahdat-Nejad, 2014). Hence, the CaaS idea has been proposed, which enables developers to focus on consuming context services instead of developing context management components from scratch. In this approach, context service provision is outsourced to third-party context service providers (Hynes et al., 2009;Moore et al., 2014;Yigitbas et al., 2020). Several approaches, such as CoaaS (Hassani et al., 2018), CDQL (Hassani et al., 2019), NGSI (Open Mobile Alliance, 2012), NGSI-LD (ETSI, 2019), and CaaSSET (Moradi et al., 2020), have proposed solutions and architectures to facilitate CaaS delivery. In our previous work on CaaSSET (Moradi et al., 2020), we suggested four improvements to the CoaaS (Hassani et al., 2018) architecture for achieving a lightweight CaaS platform with the least dependence on the context broker layer. Figure 2 shows that the proposed architecture is divided into four main layers: context service providers, context service consumers, context brokers and context sources (Moradi et al., 2020).  Moradi et al. (2020) In this architecture (Moradi et al., 2020), each context service provider may host and manage one or more context services and deliver each context service as an autonomous context web service. The context source is an optional layer located below the context service provider layer that provisions the values of context elements for one or more context services. Context sources are classified into four general categories: sensor, middleware, web service and profiled (repository). In the proposed architecture, we redefined the context service scope to cover the key contextual concepts of the context service and their associated relationships and features. In our terminology, "context service is an interface that abstracts its underlying context sources and provides context elements and high-level contexts, which are related to one or more context-aware objects (entities)" (Moradi et al., 2020).

Model-driven development (MDD)
To facilitate context service development, we can leverage various approaches, one of which is the MDD approach (Chabridon et al., 2013). In software engineering, abstraction is a well-known method to overcome complexity. MDD considers models as first-class citizens and uses a higher layer of abstraction in software development (Bézivin, 2004;Brambilla et al., 2012). In the MDD approach, we typically create a domain-specific language (DSL) that focuses on resolving problems in a particular domain. A DSL has significant potential to increase the productivity of its users because it is designed to facilitate the modelling and development of specific requirements (Brambilla et al., 2012).
The first prerequisite for developing a DSL is to define the key concepts and relationships of the problem domain as a meta-model (Bézivin, 2004). In addition to the definition of an abstract syntax for a DSL, we should define the layout and symbols of our modelling tools, called concrete syntax (Brambilla et al., 2012). The MDD approach allows developers to design a model using a textual or graphical modelling tool. This model is then (semi-)automatically transformed into executable code using model transformation techniques (Brambilla et al., 2012).

MDD in self-adaptive context-aware applications
Recently, various studies applied the MDD approach for developing complex context-aware applications, which can adapt themselves to the context of use. For instance, in the area of human-computer interaction (HCI), studies such as Yigitbas et al. (2020) and Abrahão et al. (2021) have used MDD to facilitate the development of context-aware self-adaptive user interfaces (SAUIs). Yigitbas et al. (2020) proposed a new approach, in which context information is modelled and transformed into a context service. The user interface (UI) model and the adaptation model are also defined and transformed into an executable UI and adaptation service, respectively. This approach finally allows runtime user interface adaptation based on the latest contexts of the user, environment and usage platform.

Requirement List
By reviewing existing works in the CASC domain, an initial list of requirement specifications was proposed. Note that this initial list of requirements has been prepared with the assumption that our proposed solution uses the Context-as-a-Service (CaaS) approach. This initial list was gradually revised during the development of CA-BPEL and finally, we proposed 13 requirement specifications (R1 to R13) for CASC development and execution. Table 1 shows the 13 requirement specifications classified in three categories: service composition and execution, embedding context awareness into composite services, and context service development and delivery.

Proposed CA-BPEL Approach
The CA-BPEL approach enables designers to develop and deliver context web services independent of composite services. CA-BPEL enables developers to build a context-aware composite service compatible with standard service composition engines. In the CA-BPEL approach, the contextual concepts are not embedded into the meta-model of a standard service composition language (such as WS-BPEL). Instead, the context concepts are exposed as a context web service, and service compositions call the context web service similar to other standard web services. Figure 3 depicts the general architecture of the CA-BPEL approach. CA-BPEL consists of three components: the PCASO middleware, the CaaSSET framework (Moradi et al., 2020) and standard WS-BPEL-compliant tools. As seen in Figure 3, the position of these three components (i.e., CaaSSET, PCASO and standard WS-BPEL tools) are marked from left to right with the letters A, B and C, respectively.
The main audience of CA-BPEL is business process developers who want to build context-aware business processes by embedding context awareness into standard service orchestrations. They are experts in modelling and developing WS-BPEL-compatible service orchestrations, but aim to avoid the complexities associated with the development of a context service and the difficulties involved in integrating a context service with a standard service orchestration.
In CA-BPEL, we use free standard WS-BPEL tools available on the market to develop and execute standard composite services. Developers can use the standard WS-BPEL development tools to model and build a composite service that reuses the context web service generated by the CaaSSET framework. Developers can also use the new proposed PCASO middleware to embed the interoperability and context awareness features into a standard composite service. By leveraging the CA-BPEL approach, developers can build a WS-BPEL-compliant context-aware composite service that is executable on standard service composition engines. We introduced the CaaSSET framework in our previous work (Moradi et al., 2020). CaaSSET consists of a reference model, a meta-model and a toolset, containing a graphical modelling tool, code generation tools and an API. Developers can use the CaaSSET toolset to graphically model a context service and transform it into an executable context web service. The CaaSSET API is equipped with a context repository and allows context delivery as a REST web service and run-time access to the context values.
It should be noted that the public artifacts of CA-BPEL, such as the CaaSSET Eclipse plug-in, are available at the GitHub repository 1 of CA-BPEL. The context web service of TourismCS, generated by the CaaSSET framework (Moradi et al., 2020), can also be accessed via the GitHub repository.

PCASO middleware
The PCASO middleware allows developers to simply turn a standard composite service into a contextaware composite service. PCASO is fully compatible with the standard WS-BPEL language. WS-BPEL is typically used to model composite services and is known as the accepted standard of service composition execution engines. PCASO also facilitates the interoperability of standard composite services and context web services.
The PCASO middleware consists of a reference model and five intermediate web services. We depicted the PCASO reference model in Figure 4. The reference model refers to partitioning the functions into several elements and drawing the data flow of each element (Armstrong, 2014). The PCASO web services include a context evaluation service, a context service adapter, context trigger services (a periodic pull service and a push notification service) and a context listening service.

PCASO context service adapter
A context service is typically implemented using the SOAP or REST technologies. In the PCASO reference model, instead of establishing a direct connection between a composite service and a context service, these services are connected through the PCASO context service adapter. PCASO provides these adapters as a SOAP web service. This adapter resolves the interoperability according to the invoked context web service type (e.g., SOAP or REST).

PCASO context evaluation service
A context evaluation service receives a context value and compares it with predefined values. If they match, the value of one is returned, and otherwise, the value of zero is returned. Predefined values can be either a fixed value, a list of allowed values or a range of allowed values limited by a lower and an upper bound. A context evaluation service is used by three PCASO web services (i.e., the context listening service, the periodic pull service and the push notification service). For embedding context awareness into a standard composite service, PCASO introduces two mechanisms: a context trigger and context listening.

PCASO context trigger
When we activate a context trigger, the context value is monitored and evaluated. When a context value matches the predefined values, the trigger is activated and a predefined composite service is called and initiated. The context triggers can be activated by either of the two web services provided by PCASO, i.e., the periodic pull service or the push notification service.
Periodic pull service: A predefined service is executed periodically (e.g., every 5 seconds) and extracts the last value of a specific context from a particular context service. The extracted context value is evaluated, and if it matches the predefined values, the trigger is activated. If the extracted value does not satisfy the evaluation conditions, the periodic pull service snoozes for a pre-determined period (e.g., 30 seconds). After the snooze, the cycle of pulling and evaluating context values is repeated periodically.
Push notification service: The composite service is subscribed in advance for a specific context of a particular context service. Afterwards, the context service monitors the context values. As soon as it detects any change in the monitored context, its new context value is sent to the push notification service. This service evaluates the received context value. In the case of compliance, the trigger is activated. Note that the context service must support the push notification feature to support the PCASO push notification service fully. Fortunately, this feature is supported by the CaaSSET API.

PCASO listening service
PCASO uses the existing features of WS-BPEL to add the contextual pre-condition and contextual postcondition before or after each action, respectively. When a service composition is executed, PCASO initiates the listening service right after reaching any contextual pre/post-condition. By calling the PCASO listening service, the last context value is extracted from the associated context service. This context value is evaluated. When it matches with predefined values, the value of one is returned to the composite service. It means that the contextual pre/post-condition is satisfied. In the case of non-compliance, the listener snoozes for a predefined period (e.g., 30 seconds). Afterwards, the last context value is re-extracted and re-evaluated. This cycle is repeated until the contextual pre/post-condition is satisfied or the listening deadline is reached. As soon as the deadline condition is reached, the listening service is stopped and the negative value of one is returned to the composite service.
The PCASO listening service can be called both synchronously and asynchronously. In synchronous listening, the composite service suspends until it receives a response from the PCASO listening service or reaches the listening deadline. Asynchronous listening means that the composite service sends a listening request and continues the service composition. In this approach, the calling composite service is not suspended. Note that synchronous listening is suggested when the listening deadline is short-term (e.g., less than 30 seconds); otherwise, asynchronous listening is recommended .

Standard tools for developing and executing composite services
We use the standard Eclipse BPEL Designer 2 tool to develop composite service models and transform them into WS-BPEL code. The standard Eclipse BPEL Designer tool provides a standard graphical modelling environment, enabling developers to build a WS-BPEL-compliant composite service model and integrate it with its constituting web services. This development environment automatically generates the equivalent WS-BPEL code of the graphical service composition model. Our proposed solution also utilizes the WSO2 BPS (Business Process Server) tool 3 to deploy and execute composite services. This open-source tool facilitates the deployment and management of composite services. Note that WSO2 BPS uses the standard Apache ODE (Orchestration Director Engine) 4 to execute composite services.
To fully meet requirements R1 to R13, this study used the de-facto standard WS-BPEL language and its associated tools to implement and execute the composite services. However, the conceptual design of the proposed approach does not depend much on this standard. On the other hand, our main contributions (i.e., CA-BPEL, CaaSSET and PCASO) were designed according to the separation of concerns and reusability principles. Therefore, in future works, we can customize CA-BPEL for embedding context awareness into service choreography standards, the BPMN standard, or non-standard commercial service composition platforms, such as Amazon AWS Step Functions and Netflix Conductor. According to our preliminary investigations, such customizations can be made with minor modifications to the CaaSSET framework, which is the core of the CA-BPEL approach.

Demonstration (Tourism Context-aware Composite Service)
In our previous research (Moradi et al., 2020), we conducted a tourism demonstration and utilized the CaaSSET toolset to model, develop and deliver the TourismCS context service. In this section, we conduct a tourism demonstration to show the usefulness of CA-BPEL in the CASC domain. This demonstration can model a tourism composite service using standard service composition modelling tools. Afterwards, we use the PCASO adapter to facilitate the interoperability of OutdoorTourProcess and the TourismCS context service.
We also used the PCASO web services to embed the context awareness features into the tourism composite service. Finally, the CA-BPEL approach could generate a WS-BPEL-compliant context-aware composite service, which can be executed on the Apache ODE service composition engine.
We illustrated the conceptual model of OutdoorTourProcess in Figure 5. This figure shows that a standard composite service consists of two atomic web services (i.e., TourOrganizerWS and TouristNotifierWS) and one context service (i.e., TourismCS). The communication types of OutdoorTourProcess and the two atomic web services are one-way asynchronous and two-way synchronous, respectively.
In Figure 5, we followed the CA-BPEL approach and created a context-aware service composition by adding green elements to a standard composite service. The white colour was also used for the main elements of the standard composite service. Similarly, the atomic services, which are reused by the composite service, were marked grey.
To design and develop OutdoorTourProcess, we used the Eclipse BPEL Designer environment. In this IDE, a WS-BPEL-compliant service composition model was drawn graphically, and the communication with the atomic web services was configured. To turn this standard composite service into a context-aware composite service, we manually connected the tourism composite service and the intermediate web services provided by PCASO. We also configured the communication between the PCASO context service adapter and the TourismCS context web service. Eclipse BPEL Designer generated the WS-BPEL code of OutdoorTourProcess automatically. After designing and developing OutdoorTourProcess, we deployed its WS-BPEL code in the WSO2 BPS tool. Note that BPS executes the composite services using the standard Apache ODE engine .

Evaluation
Section 6.2 introduced a tourism demonstration to evaluate the usefulness of the CA-BPEL approach for CASC development and execution. In this section, the CA-BPEL approach itself is evaluated. In Section 7.1, we use the tourism demonstration results to investigate to what extent PCASO and standard WS-BPEL tools support R1 to R8. In Section 7.2, we discuss to what extent requirements R9 to R13 are supported by the CaaSSET toolset. Note that judgment on the convenience of CASC development and execution is entirely dependent on satisfying the ease of context service development and delivery (R13) by the CaaSSET toolset. Hence, in Section 7.3, we conduct a usability evaluation survey to measure the satisfaction of R13 by the CaaSSET toolset. To resolve threats to the survey validity, we also use a Pearson correlation analysis.
In the continuation of this section, we examine to what extent CA-BPEL supports requirement specifications R1 to R13.

Meeting requirements R1 to R8
In the CA-BPEL approach, we used the standard WS-BPEL tools to develop and execute composite services. Since these tools are more than a decade old and are reasonably mature, they are appropriate for service composition development and execution to the best of our knowledge. Therefore, our proposed solution fully supports both requirements R1 and R2. In the following, we used the tourism demonstration results to examine to what extent PCASO supports requirement specifications R3 to R8.
• The TourismCS context service sends the value of the OutdoorWeather context to the PCASO push notification service as soon as it changes. The push notification service evaluates the received context value , and in the case of compliance with the value true, the trigger is immediately activated and OutdoorTourProcess is initiated [Requirement R3]. • The PCASO periodic pull service runs periodically and extracts the value of the OutdoorWeather context from the TourismCS context service. The PCASO periodic pull service evaluates the OutdoorWeather context value. If the context value complies with the value true, the trigger is immediately activated and OutdoorTourProcess is initiated [Requirement R4]. • Figure 5 shows that two contextual pre-conditions are evaluated asynchronously by the asynchronous invocation of the PCASO listening service [Requirement R5]. • To support the interoperability between OutdoorTourProcess and TourismCS, both PeriodicPullWebService and ListeningWebService call the PCASO adapter, and this adapter calls the TourismCS service interface on behalf of PeriodicPullWebService and ListeningWebService. This design style allows developers to apply integration without worrying about the interoperability of a SOAP-compliant composite service (i.e., OutdoorTourProcess) and a RESTcompliant context service (i.e., TourismCS) [Requirement R6]. • As implied from the tourism demonstration, our approach treats the context model similar to a standard web service. We also have not applied any changes to the original meta-model of WS-BPEL. Besides, our proposed solution builds a context-aware composite service, which can be compatibly executed on the Apache ODE, which is a WS-BPEL-compliant service composition engine [Requirement R7]. • CA-BPEL facilitates CASC development, because, instead of providing a brand new tool for CASC development, we used the Eclipse standard IDE to ease the development of a WS-BPEL-compliant composite service. We also use the CaaSSET framework to facilitate context service development and delivery. Besides, PCASO web services, which are invoked similarly to standard web services, could facilitate turning a tourism composite service into a context-aware tourism composite service [Requirement R8].

Meeting requirements R9 to R13
As mentioned previously, requirements R9 to R13, which are related to context service development and delivery, should be supported by the CaaSSET framework. As implied from our previous work (Moradi et al., 2020), developers can use the CaaSSET toolset to graphically model a context service and transform it into an executable standalone context web service. The CaaSSET API is equipped with a context repository and allows context sharing and delivery as a web service. This web-based REST API supports run-time access to current and historical context values. Hence, CaaSSET fully supports R9 to R11.
Our previous investigations (Moradi et al., 2020) also showed that 34 out of 36 features of the context service modelling are fully supported by CaaSSET, one feature (sophisticated derivation expressions) is partially supported, and one feature (ontology model) is not supported. Note that the ontology model could be incompatible with the vital requirement R13, i.e., the ease of context service development and delivery. These investigations reveal the superiority and comprehensiveness of the CaaSSET meta-model for modelling complex context services compared to the related work. Therefore, we can argue that CaaSSET can fully support R12.
Note that our work aims to ease CASC development and execution. Achieving this goal is entirely dependent on satisfying the vital requirement specification R13 (i.e., ease of context service development and delivery). Hence, meeting R13 by the CaaSSET toolset would be of great value. In the next section, we measure the extent to which the CaaSSET toolset satisfies the critical requirement specification R13.

Measuring the satisfaction of requirement R13 by CaaSSET
Given that the CaaSSET toolset uses a graphical user interface, we used two usability questions to assess the extent to which the CaaSSET toolset supports R13.

1) First usability question (ease of learning and use):
Is it easy to learn and use the CaaSSET toolset? 2) Second usability question (audience satisfaction and usefulness): Is it useful and satisfactorily leveraging the CaaSSET toolset to ease context service development and delivery?

CaaSSET toolset usability questionnaire
To answer the usability questions mentioned above, we used the survey method and utilized the Lund questionnaire (Lund, 2001), known as USE. The USE questionnaire measures the usability of the software product interface using the four variables: ease of use, ease of learning, usefulness and audience satisfaction (Lund, 2001). The variables ease of use and ease of learning help find the answer to the first usability question, i.e., ease of learning and use. The variables usefulness and audience satisfaction help find the answer to the second usability question, i.e., audience satisfaction and usefulness. The questionnaire for evaluating the CaaSSET toolset usability, presented in Table 2, measures the four usability variables based on 11 evaluation factors and 21 questions.

Usability survey audience
The survey statistical population was developers in Isfahan and Birjand cities of Iran familiar with context service modelling, development and delivery; we call this domain knowledge. The statistical population size was about 53 people. According to the Morgan table method (Krejcie and Morgan, 1970), the sample size should be 32. We used the simple random sampling method without placement, and after communicating with different people in the statistical population, 20 people participated in our survey. Participants selfassessed three dimensions of their domain knowledge by answering six questions. Due to the specialized nature of the CaaSSET toolset, the evaluators' domain knowledge should not be too low. Therefore, to preserve the survey quality, we eliminated the participants whose domain knowledge was less than eight, meaning the lower quartile of domain knowledge. Finally, we collected the feedback of 12 developers, who were in the top three quartiles of domain knowledge. Among these 12 participants, two had a PhD in Software Engineering, two were third-year PhD students of Software Engineering, four had MSc in Software Engineering or Information Technology, and four were MSc students of Information Technology. We elaborated the results of this self-assessment step in Appendix A (Table A.1).
The evaluators' relevant experience was between two and eight years. Two evaluators had seven or eight years of academic experience, two had six years of relevant experience in both industry and academia, four of them had five years of industrial experience, and four had about two years of academic experience .
The evaluators' age was between 25 and 38 years. Two people were 37 to 38 years old, one person was 33 years old, five people were 28 to 29 years old, and the remaining four were 25 to 26 years old.
The evaluators' experience included a combination of knowledge of software design and modelling, model-driven development, UI/UX 5 design, web service development and context-aware application development . Due to the novelty and multidisciplinary subject of the evaluated toolset, the average score of evaluators' domain knowledge was 16.2 out of 30, indicating that the developers' average knowledge of the problem domain was mediocre. Besides, the average score of the evaluators' domain knowledge ranged from 8 to 25. In other words, a combination of less experienced and more experienced evaluators was used to assess the toolset.

Usability evaluation results
After preparing the usability assessment questionnaire, we provided a guideline to develop a context service and deliver it as a web service. We also had a 40-minute online meeting in which we trained 12 participants on how to work with the CaaSSET toolset. Afterwards, the participants modelled and generated a similar context web service. To observe and execute the generated context web service, they used a graphical user interface, which we provided for the CaaSSET API. Finally, we collected the participants' feedback. Participants were allowed to leave the answer blank or choose from five options: excellent, good, moderate, weak and very weak. We applied the descriptive statistics to calculate for each option the ratio to the total number of received responses. Table 2 shows the usability evaluation results.
To make the results more understandable, in the last left column of Table 2, we considered a column called satisfaction ratio, showing what percentage of participants had chosen the acceptable answer. The value of this column is derived by adding the values of the columns excellent and good. We calculated the minimum satisfaction ratio for each of the four usability variables by minimizing the values of the satisfaction ratio column.

Usability question Usability variable Minimum satisfaction ratio
Ease of learning and use Easy to use the CaaSSET toolset 75% Easy to learn the CaaSSET toolset 75% Audience satisfaction and usefulness The usefulness of the CaaSSET toolset (for facilitating context service development and delivery) 75% Audience satisfaction with the CaaSSET toolset 100% As illustrated in Table 3, the minimum satisfaction ratio for the three usability variables is 75%. Overall, more than 75% of the participants evaluated the CaaSSET toolset usability as satisfying (good or excellent) .
In the following, we analyse the descriptive statistics of the usability questionnaire.
• First evaluation question (easy to learn and use): More than two-thirds of survey participants rated their modelling knowledge as moderate, weak or very weak. However, 100% of the participants evaluated the ease of working with the CaaSSET toolset as satisfying. More than 75% of the survey participants evaluated five other factors related to ease of use (i.e., user-friendliness, flexibility, consistency and coordination, error-checking and fast recovery) as satisfying. In addition, 91.7% of the participants rated the ease of learning and use of modelling and code generation tools as satisfying, and 75% found it easy to learn how to work with the CaaSSET API. Besides, about 17% of the developers rated the user-friendliness of the CaaSSET modelling tool as moderate or weak. Hence, improving the visual aspects of the CaaSSET modelling tool can be the subject of our future developments .
• Second evaluation question (audience satisfaction and usefulness): 100% of the participants were satisfied with the CaaSSET toolset. Besides, all the participants evaluated the CaaSSET toolset applicability as satisfying. More than 75% of participants also considered the other three usefulness factors (including productivity, time saving, requirement coverage, productivity and effectiveness) satisfying .

Number of respondents:
We used a relatively small number of evaluators due to two limitations. The first limitation is the novelty and multidisciplinary subject of the evaluated toolset. The evaluators' experience should be a combination of their knowledge of software design and modelling, model-driven development, UI/UX design, web service development and context-aware application development. Unfortunately, developers with a combination of such expertise are rare, and identifying and communicating with them to participate in a non-profit study was a challenging task. The second limitation was the installation of the prerequisite software (such as Eclipse and its associated tools) before the beginning of the evaluation.
Due to these limitations, our assessment was conducted in two cities where we had previous knowledge of relevant experts, and we had, in the unusual circumstances of COVID-19, physical access to relevant experts for initial coordination, training, software installation and final evaluation. To efficiently increase the number of evaluators, in future research, we are going to work on creating a web-based version of the CaaSSET modelling tool so that more experts can evaluate it remotely without the installation of the Eclipse software and its associated tools.

Relation of evaluators' domain knowledge and ease of learning and use:
The other threat to our usability survey validity could be that if people with lower domain knowledge had performed the assessment, the toolset usability score would have been lower. In response to this threat, we should note that the participants' average domain knowledge is about 16.2 out of 30, indicating that the evaluators' average domain knowledge was moderate. The average score of the evaluators' domain knowledge also ranged from 8 to 25, indicating that we used a combination of less experienced and more experienced evaluators.
Nevertheless, to fully resolve this threat, we designed six hypotheses, similar to hypothesis H1.1; see Appendix A (Table A.2). These hypotheses examine whether there is a significant positive or negative correlation between the evaluators' domain knowledge and the CaaSSET toolset usability.
Hypothesis H1.1: There is a significant correlation between evaluators' domain knowledge and ease of learning and use of the CaaSSET toolset.
We used the Pearson correlation test with a confidence interval level of 95% and a margin error of 5% to prove or disprove the above six hypotheses. The results of analysing these six hypotheses are presented in Appendix A (Table A.2). This analysis showed a weak positive correlation between evaluators' domain knowledge and the CaaSSET toolset usability. The correlation is more prominent in the knowledge of service development and delivery; however, considering the rejection of the six designed hypotheses, the correlation is not statistically significant and cannot be generalized to the whole statistical population. Hence, according to the usability evaluation results (Table 3) and the correlation analysis (Table A.2), it is concluded that the CaaSSET toolset is usable for audiences above three quarters in the domain knowledge of context service modelling, development and delivery. Therefore, the CaaSSET toolset could fully support ease of context service development and delivery (R13).

Comparison of the proposed solution and related works
This section reviews the most important works related to CASC development and execution. The most important criterion for including a related work in our comparison table is to what extent it supports requirement specifications R1 to R13. We have chosen a combination of related works such that each requirement specification is covered by at least one related work. We can classify works related to the CASC development and execution into four general sections: service composition (SC), CASC, contextaware business processes (CABP) and context service development and delivery (CSD&D).
According to our previous investigations (Moradi et al., 2020), the studies related to CSD&D can be classified into four general categories: context-aware services, context-aware applications, CaaS delivery and CaaS development. In our previous work (Moradi et al., 2020), we compared 16 key approaches, classified in the four mentioned categories, based on 44 evaluation criteria, then elaborated 14 requirements related to CSD&D. In the present research, among the 16 key mentioned approaches, we have chosen five works that are more related to context-aware service composition and execution. Hence, five approaches including CaaSSET (Moradi et al., 2020), ContextUML (Sheng et al., 2010;Sheng and Benatallah, 2005), NGSI (Open Mobile Alliance, 2012), NGSI-LD (ETSI, 2019), and CSDL+CDQL (Hassani et al., 2019) have been included in our new comparison table. Table 4 compares CA-BPEL (including PCASO, CaaSSET and standard WS-BPEL tools) with 14 related works classified in four categories, based on the 13 requirement specifications R1 to R13. Note that in the CA-BPEL approach, we assumed that standard WS-BPEL-compliant tools support R1 to R2; the PCASO middleware meets R3 to R8, and the CaaSSET framework satisfies R9 to R13.
As shown in Table 4, none of the thirteen related works could fully support R1 to R13. Table 4 also shows that Hagin's approach provides more substantial support for 13 identified requirements and, as such, it has an advantage over most related work. Nevertheless, Hagin's approach and the other investigated related works are weak in supporting R3 to R5 and R12 to R13. In other words, existing approaches either partially support embedding context awareness into a standard composite service (R3 to R5), or have a weakness in considering a comprehensive context model (R12), or they have not provided an easy-to-use solution to facilitate CASC development (R13). Moreover, most existing approaches use a proprietary solution, inconsistent with industry-accepted standards, such as WS-BPEL (R2).
As implied from Table 4 and previously elaborated in our previous work (Moradi et al., 2020), the CaaSSET framework fully supports the development of a comprehensive context service model, whereas the related studies are weak at this (R12). Note that CaaSSET is equipped with an API and a context repository that allows the storage of context values and accessing the context values at run time (R11). Moreover, CaaSSET does not fully support the interoperability between composite services and context web services (R6). However, this weakness is resolved by applying the wrapping adapter of the PCASO middleware to the REST interface of the CaaSSET API. Although CaaSSET fully supports ease of context service development and delivery, it is not designed to facilitate CASC development (R8). Fortunately, this weakness has been resolved by using the standard WS-BPEL development tools. In general, it can be concluded that while related work partially supports requirement specifications R1 to R13, CA-BPEL supports the 13 identified requirement specifications fully.

Conclusions
The goal of this study was to facilitate the development and execution of context-aware service orchestrations. We achieved this goal by proposing the CA-BPEL approach, which is based on MDD and CaaS. Our main contributions are the CA-BPEL approach and the PCASO middleware, consisting of a reference model and five intermediate web services. PCASO web services include trigger services (a periodic pull service and a push notification service), a listening service, a context evaluation service and a context service adapter. The CA-BPEL approach assumes that instead of modifying the WS-BPEL language meta-model, context is delivered as a web service. Hence, standard composite services can work with a context service similar to other standard web services. The PCASO middleware allows the developer to turn a standard orchestrated service into a context-aware composite service. PCASO is also fully compliant with the WS-BPEL language, accepted by service composition development environments and service composition execution engines. PCASO also facilitates the interoperability of standard composite services and context services.
We showed the usefulness of CA-BPEL by developing and executing a tourism demonstration. We also compared the CA-BPEL with 14 baseline techniques in terms of 13 identified requirements. These evaluations showed that CA-BPEL (i.e., PCASO, CaaSSET and standard WS-BPEL-compliant tools) facilitates CASC development and execution and has advantages over related work. Our investigations also indicated that while CA-BPEL supports the 13 identified requirements, related studies either support limited dimensions of contextual concepts or have a weakness in the critical context awareness features or use a proprietary solution, inconsistent with industry-accepted standards.
The judgment on the convenience of CASC development and execution is entirely dependent on satisfying requirement R13, i.e., ease of context service development and delivery. As such, we conducted a usability survey to measure the satisfaction of R13 by the CaaSSET toolset. In the survey, we asked 12 developers to evaluate four usability variables: ease of use, ease of learning, usefulness and audience satisfaction. The survey results showed that 100% of the participants were satisfied with the CaaSSET toolset for facilitating context service development and delivery as a web service. All the participants evaluated the applicability and ease of working with the CaaSSET toolset as satisfying. Overall, more than 75% of the survey participants ranked the CaaSSET toolset usability as good or excellent. To resolve threats to the survey validity, we used a Pearson correlation analysis, showing that the CaaSSET toolset is usable for audiences above three-quarters in the knowledge of context service modelling, development and delivery. The significance of this study is in demonstrating that MDD, along with CaaS, has much potential to facilitate the development of context-aware service compositions.
This research can be extended in several ways. For instance, we can work on a web-based version of the CaaSSET toolset so that its audience would not need to install Eclipse IDE and its associated tools. We can also explore a brand new solution to facilitate context-aware service choreography development. CA-BPEL can also be customized for embedding context awareness into service choreography standards, the BPMN standard or non-standard commercial service composition platforms, such as Amazon AWS Step Functions and Netflix Conductor. According to our preliminary investigations, such customizations can be made with minor modifications to the CaaSSET framework, which is the core of the CA-BPEL approach.

Additional Information and Declarations
Conflict of Interests: The authors declare no conflict of interest.

Data Availability:
The data that support the findings of this study are available from the corresponding author upon reasonable request.