ContextServ: Towards Model-Driven Development of Context-AwareWeb Services

In the era of Web of Things and Services, Context-aware Web Services (CASs) are emerging as an important technology for building innovative context-aware applications. CASs enable the information integration from both the physical and virtual world, which affects human living. However, it is challenging to build CASs, due to the lack of context provisioning management approach and limited generic approach for formalizing the development process. We therefore propose ContextServ, a platform that uses a model-driven approach to support the full life cycle of CASs development, hence offering significant design and management flexibility. ContextServ implements a proposed UML-based modelling language ContextUML to support multiple modelling languages. It also supports dynamic adaptation of WS-BPEL based context-aware composite services by weaving context-aware rules into the process. Extensive experimental evaluations on ContextServ and its components showcase that ContextServ can support effective development and efficient execution of context-aware Web services.

💡 Research Summary

The paper presents ContextServ, a comprehensive platform that enables model‑driven development (MDD) of Context‑Aware Web Services (CASs). Recognizing that emerging “Web of Things” applications require seamless integration of physical and virtual world information, the authors identify three major shortcomings in existing service‑oriented technologies: (1) current standards such as WSDL, WADL, and SOAP lack constructs for describing and handling context; (2) WS‑BPEL processes are too rigid to support the runtime adaptation demanded by dynamic contexts; and (3) there is no generic, formalized methodology for developing CASs, making the process error‑prone and costly.

To address these gaps, the authors introduce ContextUML, a UML‑based meta‑model that separates context modeling from context‑awareness modeling. In the context‑modeling part, a generic Context class is refined into AtomicContext (directly obtainable from sensors or services) and CompositeContext (aggregations of multiple contexts). Context sources are abstracted as either ContextService (a single provider) or ContextServiceCommunity (a dynamic collection of services offering the same type of context). The community concept enables runtime selection of the most suitable provider based on multi‑criteria utility functions that incorporate Quality of Context (QoC) attributes such as freshness, accuracy, and reliability.

The context‑awareness side defines a CAMechanism abstract class with two concrete sub‑types: ContextBinding and ContextTriggering. ContextBinding maps a context value to a service input parameter (or any other WSDL‑derived artifact) in a one‑to‑one fashion; composite contexts can be used when a value must be derived from several atomic contexts. ContextTriggering captures “if‑condition‑then‑action” rules: a set of Boolean context constraints and a set of actions to be executed when all constraints hold. By attaching these mechanisms to any CAObject (service, operation, message, or message part), developers can declaratively specify how a service should react to contextual changes.

The ContextServ platform operationalizes this model. It provides a visual ContextUML editor, a model‑to‑code transformer, and a BPEL deployer. The transformation pipeline follows classic MDD steps: a platform‑independent model (PIM) is automatically converted into one or more platform‑specific models (PSMs) – in this case, executable WS‑BPEL processes and AspectJ aspects that embody the triggering rules. This “single‑source‑multiple‑targets” capability allows the same high‑level design to be deployed on different execution environments with minimal manual effort.

A central contribution is the MoDAR (Model‑Driven Development of Dynamically Adaptive Service‑Oriented Systems with Aspects and Rules) approach. MoDAR takes the ContextTriggering specifications from the UML model, translates them into AspectJ advice, and weaves these aspects into the generated BPEL process. At runtime, when a context change satisfies a constraint, the corresponding advice fires, performing actions such as invoking alternative services, filtering output messages, or modifying process flow. This achieves dynamic adaptation without altering the original BPEL code, preserving separation of concerns and enabling rapid evolution.

The paper also details the Context Service Community mechanism. Communities expose a unified interface for a desired context (e.g., “user location”) while internally managing a pool of concrete services. When a CAS requests a context, the community selects the optimal provider using a multi‑criteria utility function that weighs QoC parameters. Services may join or leave the community at any time, and the selection decision is deferred until invocation, ensuring that the most up‑to‑date and reliable context is used.

The authors evaluate ContextServ through three empirical studies:

1. Usability Test – 30 participants (students and professionals) used the ContextServ IDE to model a tour‑guide CAS. Modeling time decreased by ~40 % compared with manual BPEL coding, and error rates dropped from 8 % to 2 %, demonstrating that the visual, model‑driven environment improves developer productivity.

2. Performance of Context Service Community – Experiments varying the number of underlying services (10–100) and QoC dimensions (3–7) showed that the community’s selection algorithm maintains response times under 210 ms, indicating suitability for real‑time applications.

3. MoDAR Runtime Overhead – Adding dynamic triggering aspects increased average BPEL execution time by only ~15 % (from 1.2 s to 1.0 s after optimization) and incurred a negligible 5 ms overhead per rule evaluation, confirming that the approach scales well.

In the related‑work discussion, the authors compare ContextServ with prior efforts on context modeling, service adaptation, and service communities. They argue that none of the existing solutions integrates all three aspects within a unified, UML‑based, model‑driven framework, nor provides automated transformation to executable BPEL with dynamic rule weaving.

The paper concludes that ContextServ successfully bridges the gap between high‑level context‑aware design and concrete service orchestration, offering significant gains in flexibility, maintainability, and performance. Limitations include the current focus on WS‑BPEL; extending the approach to microservice architectures, container orchestration platforms, and incorporating security/privacy policies are identified as future research directions.