Context driven process selection and integration of mobile and pervasive systems

Pervasive and Mobile Computing 8 (2012) 467–482

Contents lists available at SciVerse ScienceDirect

Pervasive and Mobile Computing journal homepage: www.elsevier.com/locate/pmc

Context driven process selection and integration of mobile and pervasive systems✩ Matthias Füller a,1 , Willi Nüßer a,∗ , Thomas Rustemeyer b,2 a

FHDW, University of Applied Sciences, Computer Science, Fürstenallee 3-5, 33102 Paderborn, Germany

b

eck*cellent IT GmbH, Theodor-Heuss-Straße 2, 38122 Braunschweig, Germany

article

info

Article history: Received 4 June 2010 Received in revised form 4 March 2011 Accepted 5 March 2011 Available online 21 March 2011 Keywords: Mobile systems Context Business processes BPEL Rule based systems OSGi Ontology

abstract Current mobile or pervasive systems possess ever increasing computing powers. A tight integration of those systems into business processes is therefore desirable. However, this requires consideration of the changing context of those systems especially when determining adequate processes for a system. This paper introduces a novel context driven approach to select processes suitable for a system’s context and to integrate the system into the chosen processes. An infrastructure to implement the context driven approach is proposed and a prototype is given. A flexible implementation is accomplished using a hybrid context model, rule engines and OSGi. © 2011 Elsevier B.V. All rights reserved.

1. Introduction Mobile or pervasive systems, like mobile phones or embedded systems, are becoming more and more powerful. They are equipped with vast computing powers and high network bandwidths [1]. It is only natural that new requirements on the usage of such systems arise. First, mobile systems should be integrated much more closely into business activities in order to make efficient use of these resources for business cases and to provide users with smarter and value added services. This may address the integration into existing business processes or even lead to the creation of new processes and business models. Well-known examples are from Tourism [2], Maintenance [3,4], Health Care [5] or Agriculture [4]. Second, due to their deep integration in human life, one expects mobile and pervasive systems to adapt to an ever changing environment, to their context [6]. To meet these demands, one has to find ways to combine mobile systems, processes and contexts. Relevant details of these three concepts are given later in this article. When combining, some obvious consistency requirements between these concepts must be met. For example, it is natural to assume that the processes in which a mobile system participates should fit to its context.

✩ Financial support of the German Bundesministerium für Wirtschaft (BMWi) represented by the Arbeitsgemeinschaft industrieller Forschungseinrichtungen (AiF) is gratefully acknowledged. German patent granted. ∗ Corresponding author. Tel.: +49 5251 301135; fax: +49 5251 301188. E-mail addresses: [email protected] (M. Füller), [email protected] (W. Nüßer), [email protected] (T. Rustemeyer). 1 Tel.: +49 5251 301135; fax: +49 5251 301188.

2 Tel.: +49 (531) 70 22 20 00; fax: +49 (531) 70 22 22 99. 1574-1192/$ – see front matter © 2011 Elsevier B.V. All rights reserved. doi:10.1016/j.pmcj.2011.03.002

468

M. Füller et al. / Pervasive and Mobile Computing 8 (2012) 467–482

However, the approaches to actually combine these three concepts differ. There is a well-known approach which starts with a process model [7,8]. This model is expanded to deal with context and to handle context data within the model. This is considered as a special case of the general class of context aware applications [6,9,10]. The focus lies on the process model itself and efficient ways to deal with context from within the model. In pervasive and mobile scenarios, a different approach which starts with the system itself sometimes seems to be more natural. Here one starts with the mobile or pervasive system, determines its context, finds suitable processes for this context and integrates the system into these processes. The focus of this approach shifts from the process to the system. This procedure might be called context-driven since the systems context actively defines the process. While the context aware approach is studied intensively, there is much less systematic work on a context driven design. It offers some benefits, though. First, it takes the whole life cycle of business processes and systems into account. This significantly extends the usual approaches to integrate context and processes. It also provides a straightforward way to relate the life cycles of processes and systems. Consequently, this allows for a direct way to associate systems with actions and processes suitable for the systems context. Secondly, it can help to separate context handling from process modelling, thus reducing complexity, e.g. in process modelling. In a context driven design, even existing context-agnostic process models may be reused. The context itself chooses the suitable processes which in turn may take these context values for granted. This reduces the need during process modelling to take all possible context variations into account. Finally, a combination with existing approaches to combine context and processes [7,8] may easily be achieved. One can start with context-driven process selection and additionally request context data within the selected process if needed. This may lead to new application types and broaden the range of existing context aware applications. The purpose of this paper is therefore twofold: first, the concept and the benefits of a context driven approach are discussed in more detail. Secondly, a generic infrastructure to implement the context driven approach is presented. This architecture allows existing approaches to be implemented and enables advanced applications. This paper is structured as follows. Section 2 presents work related to different forms of context handling. Section 3 discusses two case studies which demonstrate the requirements and benefits of a context driven approach. Section 4 describes conceptual elements of the generic infrastructure. In Section 5, details of an implementation are given. Section 6 presents an evaluation of the infrastructure implemented. Here we first show the implementation of the case studies within the infrastructure and then give a quantitative evaluation of performance aspects of the infrastructure. Section 7 comprises some thoughts on future work and gives a summary and conclusion. 2. Context and processes Over the last 15 years, much research work has been done in the area of context understanding [11,6,10]. Various approaches to context models are available [12,13] as well as design guides for infrastructures which handle context information [14,15]. Special examples are Location Based Services (LBS) which — for example — allow for the creation of user information adapted to the current location [16]. Some approaches are of special importance to our work. First, hybrid context models which combine different modelling approaches are sometimes considered as promising candidates to handle the complexity and variability of context models [12,13]. The usage of semantic technologies, like ontologies, may possess especially great potential [17,13]. Second, complete context infrastructures have appeared over the last few years. For example the NEXUS infrastructure [18] provides an elaborate system of context servers which provide different clients with context information. Third, context information has been used in applications to adapt their behaviour according to context. For example, context information was requested and processed in order to either route packages [19] or messages [5]. Finally and most important, in the last few years much work has gone into the study of the use of context information in business processes or workflows. We look at these approaches in greater detail in the next sections. We start with a general discussion of the business process lifecycle and use this conceptual framework to describe the different, but related approaches. 2.1. Process lifecycle During their lifetime business processes and — say — mobile systems run through several different states. On the left, Fig. 1 shows states which relate to the process model itself and a simplified variant of the states of a running process instance [20, ch. 5.5]. On the right side, a very simple state diagram of a system is given. For the purpose of this paper we can assume that a system is in one of three states: shut down, running independently, e.g. used for phoning, or executing actions on behalf of a process. The arrow between the two regions indicates in a not UML-compliant way that transitions between the two regions are closely related. We will come back to this in later sections. In this section we focus on the process related states. For each of these states some questions are of special importance. In this section we will give some of these questions. In the next sections we use them to describe two approaches and outline their differences.

M. Füller et al. / Pervasive and Mobile Computing 8 (2012) 467–482

469

Fig. 1. Simplified lifecycle of business processes and systems.

The first state is concerned with modelling the process itself. Here, typical questions include

• How complex is the modelling of the process? • Can we reuse existing process models? • Do we need extensions to existing process languages to incorporate context information? Additionally it should be noted that especially in dynamic environments, the process model resulting from this modelling phase is not fully specified: since the modeller does not know which systems actually will participate in the process instance, the business partner description must remain abstract. The BPEL partnerLinkType and its subsequent binding to specific endpoints exemplifies this. In the next state one or several process models from the pool of modelled processes are chosen and deployed in a runtime environment like a workflow engine. Here, the obvious questions are

• Who starts and performs the selection? • When will this selection procedure start? Of course, the same questions apply to the next phase where the start of a instance of the selected process model takes place. During the execution of the process instance, relevant questions include

• • • •

What is the runtime behaviour and the resource usage of the process instance? How is context information made available to the process? Can we guarantee that context information is still valid when corresponding process activities take place? Given the not fully specified nature of the process model, how do calls from the instance to process partners get routed to the correct partner? • How easily can the process execution be adapted to a changing environment? This may include the ability to suspend and resume process instances. Of course, there are more relevant aspects of process execution, like process and engine specific features, but for the purpose of this article we will concentrate on the list mentioned above. In the final stages the process instance will be stopped. Furthermore, the process model may be undeployed. Here, the same questions as in the deploy and start stages apply. These question give a sound basis for relating different approaches to incorporate context information into business processes. But it should be noted that all these questions start from the notion of a business process. However, in situations which are characterised by dynamic partners, this is not the only important perspective. In this type of environment business partners like mobile systems may change over time either because they move out of spatial range or because of other changes in their context. So these systems and their mutability play a crucial role in process execution. Consequently, a more systemcentric view should be able to complement the process-centric perspective and to provide additional information about process execution and process reconfiguration [21]. 2.2. Context aware processes The integration of context information into workflows and business processes was studied in several publications. For the purpose of this article we can group these existing approaches under the general term context aware (CA) process modelling. Their common anatomy can be characterised in a somewhat simplistic way by a specific emphasis on certain stages of the process lifecycle.

470

M. Füller et al. / Pervasive and Mobile Computing 8 (2012) 467–482

First, they focus on the creation of process models which explicitly incorporate context processing. This is often done through special process activities like the abstract activities in [7] or the context queries in [8,22]. Additionally, extensions to process execution languages like BPEL are created to give these activities a sound foundation [23,8]. However, these extensions tend to be domain specific [22,24]. Note that this procedure results in any case in quite complex process models and implies that already existing workflows or process models must be redesigned to work in a context aware environment. Although [25] mentions the task of selecting business process instances matching available context information the selection phase itself and a corresponding architecture for this selection is not studied in detail. Similarly, in [26] an interesting example is given in the field of tourism where context information determines the services available to a mobile user. In mobile maintenance [3] context information — esp. location information — is used to provide mobile workers with adequate documentation to complete their repair tasks. But again, the procedure to select processes and integrate systems into these processes was not studied in depth. [8,22] directly address the question of the start of the process instance. They use context events but do not elaborate on the origin of these events and the relation to mobile systems. During the execution phase of the process instance context information may flow either in a push or a pull communication between the instance and context providers. This context information can affect the control flow of the instance [8,22]. The runtime discovery of the actual business partners and the corresponding context based routing was only studied for very special situations [23]. The remaining questions concerning the runtime behaviour — adaptability, context scope and resource usage — were not studied systematically. The same statement holds for the final phase, the stopping and undeploying of the process. In the literature, there are several other approaches that address related problems like handling changing environments and integration of devices. For example, the iROS middleware [27] studies situations in which a changing set of available interacting devices must be managed and the dynamic coordination of applications using events must be enabled. Similarly, one.world [28] describes an architecture to facilitate the development of applications which adapt to a constantly changing environment. Explicit regard of context information, ad hoc composition of devices and applications and straightforward data sharing are central requirements addressed in this project. In both approaches however, context and its relationship to process selection or execution is not of central importance and thus — again — not studied systematically. 2.3. Context driven approach The approaches mentioned above which connect context with business processes have a central focus on process modelling and execution. This process-centric view undoubtedly has its merits, but it is not the only or even most natural view when studying the integration of — say — mobile systems into business processes. The inherent variability of these systems has great impact on design and execution of business processes [21]. A study starting from a systems point of view may therefore lead to a better understanding of the complex interaction between pervasive and mobile environments and business processes. It will help to address questions which are not fully answered in the approaches mentioned above. When starting up such a system — like a handheld or even a farming machine — the first information it usually gathers is information about its context. Consequently, its next and primary focus lies on selecting processes according to this context information. Thereby, it does not matter if the processes themselves are modelled in a context aware way or not. Next, the system should be integrated into the selected process to act on behalf of this process or workflow. The execution of this process should last until either the process finishes or a context change requires the selection and start of a process fitting to this new context. Of course, in this cycle context plays a crucial role for the process management. We therefore termed the approach to implement this cycle ‘‘context-driven’’ (CD). It seems reasonable to create an infrastructure which is external to processes as a basic building block for the implementation. This design decision is mainly motivated by two observations. First, one can not assume that fitting processes are modelled and available for all possible context values. For example, there may be many spatial areas where mobile systems do not act as partners in a business process. Consequently, it seems natural to shift the reaction to context events into a non-process component. Second, an external infrastructure can relieve processes from modelling and executing reactions to some of these context events thus simplifying process models and runtime. In this paper we outline a framework to implement the context-driven approach which combines a few technically simple concepts. In doing so, we additionally explain the CD approach itself in more detail. The results show that the approach and our associated implementation can be used in two different stages of expansion. First, a context-driven framework may simply complement context aware techniques by adding a single initial selection phase in which processes are chosen according to their contexts. However, this approach can be broadened in a second step into a complete context driven process management for context sensitive systems. Context changes can be transmitted — say pushed — to a management system. In a context aware framework, this change would be processed within the running process. In the context driven approach however, entire processes fitting to the new context may be determined by the infrastructure and switched to when necessary. In this way, the full cycle mentioned above can be supported. To better contrast the context aware and context driven approaches, we finally map the elements of the second one to the general process lifecycle given in 2.1. This will also outline its benefits.

M. Füller et al. / Pervasive and Mobile Computing 8 (2012) 467–482

471

The existence of an external infrastructure handling context information has direct consequences on the modelling phase. Since at least parts of the processing of context information can be moved out of the process the resulting process models can be smaller and less complex. Due to this separation of context processing and business logic, the modelling itself is facilitated. Consequently, an adaptation of the process to changing environments becomes easier for a domain expert modelling the process. Additionally, the reuse of already existing process models which were designed without context awareness is greatly simplified. The need for extensions to process modelling languages which are often domain specific is reduced, too [23,8,22,24]. The selection and deployment of a process is not considered explicitly in the more process-centric view of the context aware approach. However, when we first focus on the lifecycle of a system, the selection issue comes up naturally. Context information helps in determining a process model best fitting to the systems current state. In Fig. 1 the adding of context information is indicated by switching to a lighter grey of the process states. All in all, this procedure leads to a solution which permits the context-respecting integration of mobile systems into processes. This solution can easily be extended to provide a new, direct and general framework for integrating many different kinds of mobile and context-sensing systems into processes. The concept of a context event given in [22] already incorporates a context dependent way of starting a process. A context driven approach therefore only clarifies the start-time relationship between the selecting system and the selected process. During the runtime of the selected process instance, the executing process engine itself has to deal only with smaller models since part of the context processing is moved into the new accompanying external infrastructure. Context information can still be delivered to the process either in a push or pull based way. However, in a context driven approach, the validity of context information can usually be assumed more safely since a change in context information will trigger a new selection step. Finally, the infrastructure presented in detail below also generalises the Interaction Controller given in [23]. It implements a dynamic and context dependent routing to matching process partners. Looking at the final phase of a process lifecycle, the changed emphasis of the context driven approach becomes clear again. Here, process interruption or termination may not only triggered by the process itself but also by the system drifting to new context values. The system and its context are recognised as controlling elements. To summarise, the context driven approach tries to integrate the lifecycles of both systems and processes. A straightforward implementation of this approach is based on a process-external infrastructure comprising central functions of [22,8,23]. However, this infrastructure will provide for a more systematic and complete treatment of all stages of a process lifecycle and offers several benefits especially in the modelling and execution phases. 3. Case studies In this section, we discuss two case studies to demonstrate the key features and requirements of a context driven design. The first case study comes from the field of tourism where many different approaches are available [2]. It simply reformulates the COMPASS application [26] and serves as a consistency or regression requirement. Our design must at least be able to support already existing applications. This case study considers a tourist who is equipped with a modern mobile phone and is searching for interesting restaurants in her current neighbourhood. It would be very convenient for her when starting from her physical location, her personal preferences — like fondness for Italian cuisine — and the weather, only adequate restaurants located within about 5 km of her location were proposed. Additionally, her mobile phone should offer her a reservation form for the chosen restaurant as well as an evaluation form used for a local tourist guide. This simple scenario clearly illustrates a user or system-centric approach supported by a context driven design. Technically speaking, the scenario is characterised by only one interacting mobile system, only a few relevant context items, direct interaction with a human user and a very simple business process consisting of reservation and evaluation of the restaurant. The second case study is taken from the field of agriculture. Here, precision farming [29], modern technologies on farm machines [30] and last but not least, increasing legal guidelines [31] require massive optimisation and automation of processes in farms. The harvest process may serve as an example. Today, harvesters are complex machines usually owned not by the farmer himself, but by contractors doing custom harvesting. Consequently, the systems and the processes of an individual farm are not known to the harvester in advance. Nevertheless, it is essential that the harvester has optimal utilisation. This requires an optimal integration into the environment of the farm the harvester is currently working for. The integration has some aspects. One involves the determination of the ‘‘best’’ tractor pulling tumbrils for the crop when the cereal level in the tank of the harvester exceeds some threshold. Here, the location and the time of the rendezvous must be determined. Information about the conditions of the road etc. may be relevant. Another aspect addresses the interaction with the accounting systems of the farm. Neither the systems themselves nor the individual processes are known in advance. Depending on its context (farm etc.), the harvester must identify suitable processes and interaction partners. This fits well in a context driven procedure. This case study can simply be extended to incorporate maintenance processes. Machine data, location information, etc. may serve as selection criteria for machine maintenance and support. It may even require starting adequate supply activities for defective machine components. A short analysis of the case studies with regard to the context aware and context driven approach shows at first that in principle both approaches can be used to implement the case studies. But already in the second case study the process

472

M. Füller et al. / Pervasive and Mobile Computing 8 (2012) 467–482

Fig. 2. Structure of one context item.

needed in a context aware framework would be very complex: in practise it would be almost impossible to anticipate and model all existing combinations of accounting systems and policies. Moreover, the second case study illustrates that for a harvester it is of central importance to find a fitting process thus stressing the relevance of our context sensitive selection framework. On a more technical level, the case studies indicate again the well-known fact that a very general and flexible context model is needed [12,13]. Typical context items like location, temperature, condition of a road, etc. depend strongly on the current situation and the systems involved. Second, in many cases mobile systems are not able to determine the whole context by themselves. For example, the location of partners will be requested from an external source. Therefore the context must be enriched in an additional step. Using this, context suitable business processes can be selected and the mobile systems integrated into — usually — one of these processes. 4. Conceptual elements of the infrastructure In this section we describe basic conceptual elements of the infrastructure in a coarse level of detail sufficient for the purpose of this paper. An infrastructure integrating mobile systems into business process according to their current context must have a thorough understanding and efficient way of dealing with context and business processes. Additionally, communication situations with mobile systems pose special problems which must be addressed. 4.1. Context model In our approach, we resort to a hybrid context model combining ontologies and object oriented features. Using the ontology, we provide structural information about context data [12,32]. The ontology is coded using OWL-DL to allow for localised ranges [33]. Advanced context reasoning techniques [13] were deliberately left out in this version. The actual context data is given in a simple Java-based object oriented (OO) model. Only this model is used during runtime ensuring sufficient performance. A combination of these two approaches offers several benefits. The semantic part provides for a consistent vocabulary of context information across the infrastructure components. Additionally, this vocabulary can be easily adapted to new types of context information. This is in line with the recommendation for a data-centric model made in [28]. From the context model point of view, a new type of sensor delivering new context data, for example, requires only a change in the underlying ontology. The implementation of the OO model itself can remain unchanged. Finally, the vocabulary given in the ontology can be used to tag process models. Using this tagging, a mapping between context and processes is possible. The actual implementation is based on the notion of a context item. We assume that every single piece of context information can be expressed as a context item using the form given in Fig. 2. Every item has a type indicating the kind of context information, e.g. temperature, location, time, tank level etc. This type is defined in the OWL-DL ontology and coded as a URI. Complex context information is thus represented using complex ontologies. The corresponding values are implemented as an array of Java Objects. All elements of the OO runtime context are instances of a such a context item and are combined into a context envelope. It is important to note that information about selected processes can be considered as context data and is consequently provided as context items and part of the context envelope. This is demonstrated in Section 6.1. The reference fields shown in Fig. 2 serve two different purposes. First, the field called item references allows for the representation of item relationships [13]. The most important usage is the representation of the well-known distinction between direct — or physical — context information and higher-level or derived context [15,34]. Typical examples include physical information like GPS coordinates or tank level in percent which are the basis for the derived information like ‘‘near Louvre’’ or ‘‘tank rendezvous necessary’’. The field range reference associates a physical context item with a range. GPS coordinates may be linked to polygons containing the coordinates. Tank level information may be mapped to simple intervals. Only when the physical context item leaves its range, does a new derived context item need to be created and the infrastructure addressed. A typical example is our tourist walking some 100 m. Although the GPS coordinates change permanently, she is still near the Louvre. Consequently, relevant processes will presumably not change so context transmission from the mobile phone to the infrastructure may be saved. Obviously, introducing ranges helps eliminate a performance bottleneck and also gives a mean to distinguish between context aware and context driven scenarios. In a context driven scenario, the event that a range is transgressed should immediately lead to a new determination of suitable processes whereas in context aware applications this new information will become available only on active request.

M. Füller et al. / Pervasive and Mobile Computing 8 (2012) 467–482

473

Fig. 3. Overview of the architecture of a mobile system.

4.2. Process model As stated in the introduction, one of the main benefits of a context driven approach is the reuse of existing process models. The challenge of this approach therefore lies in the selection of suitable processes and not in the modelling of new processes. The models we use are quite simple and do not leverage the full potential of current process modelling environments. Consequently, the choice of a process description is of less importance for our paper. There are only some very general requirements on the process modelling. First, the model should be executable, and second the model should be associable with elements of the ontology, i.e. context item types. These conditions are met by different approaches including BPEL [20], JPDL [35] or even Java archives. For the purpose of our project, we choose BPEL, since BPEL constitutes a well-known standard and has a reasonably fast development cycle. More important, there are existing BPEL models which may be reused within our infrastructure thus easing a comparison with other approaches [4,36]. The task of assigning mobile systems to context-fitting processes may involve the identification of a process already running. This is, for example, the case when a tractor must be integrated in the rendezvous process started by a harvester. In BPEL, this assignment requires the identification of a specific process instance (business process instance, BPI). Consequently, the infrastructure has to provide a mechanism to identify a running BPEL instance. The BPEL standard provides in-process correlation sets or more implementation specific usages of header-based information, e.g. WS Addressing [20, ch. 9]. Correlation sets require a massive intrusion into the design of a business process. In accordance with the reuse goal, this is not acceptable. Consequently, the infrastructure utilises header information to identify existing BPIs. 4.3. Mobile systems Integrating mobile systems into business processes poses several challenges for the infrastructure. First, business processes cannot rely on the continuous availability of mobile systems. Depending on the type of mobile system, they may even disappear within a running process. A caching proxy can hide this at least partially from the process. It receives a request from the process and may forward the request asynchronously to the mobile system. In this way it can also handle fault situations where the mobile system is temporarily not available. Furthermore, the assignment of a mobile system to a business process requires current knowledge of existing processes. In general, this information is not available to a mobile system and must be held by an external component. Second, one cannot assume that mobile systems like mobile phones or farm machinery are equipped right from the beginning with the software modules necessary for working in a chosen business process. These software modules, business process modules, must be administered, requested and deployed on demand. A highly suitable environment for such requirements is provided by OSGi [37]. Given such infrastructure functions, the runtime environment on the mobile or pervasive systems themselves can be quite lean, cf. Fig. 3. First, mobile systems only need a context environment for obtaining sensor data, checking ranges and eventually transferring context data into the infrastructure for further processing. In this context environment, dynamic adaptation to new sensors and their software adaptors must be possible. Second, a dynamic runtime environment is necessary for executing software specific to the chosen processes. A framework like OSGi is well-suited for both purposes. 5. Architecture of the infrastructure The facts given above show that the infrastructure should consist of some independent components, e.g. BPEL engine, OSGi framework, mobile systems, etc. To permit a high level of flexibility and heterogeneity, the components should couple only loosely and follow the rules of service based computing [38]. 5.1. Overall architecture The overall architecture of our infrastructure is given in Fig. 4.

474

M. Füller et al. / Pervasive and Mobile Computing 8 (2012) 467–482

Fig. 4. Overall architecture of the infrastructure.

Here, we distinguish between central components on one hand which implement the context driven approach and are responsible for evaluating context information, assigning mobile systems to business processes and running these processes. The management of mobile systems, on the other hand, happens in management units (MU) which act as proxies for mobile systems. All components of the infrastructure are currently implemented in Java. For the provision of Web Services we use Apache CXF [39]. A more detailed description of the individual components follows. 5.2. Components of the infrastructure Starting on the left of Fig. 4, the mobile systems (MS) are OSGi enabled to load modules necessary for participation in the business process. The communication of the business process with the mobile systems can be mediated by the MU. Here, the mapping of BPEL related Web Service calls to message formats suitable for the particular mobile systems is done. Additionally, the MU holds information about available and assigned MS and their contexts, as well as other resources, e.g. process instances. It therefore acts in a similar way to the discovery service in [28] or the interaction controller in [23]. The MU internal mapping between context and mobile systems is governed by rules engines, like JBoss Drools [40]. The MU finally serves as the module repository for the required OSGi modules. The central entry point into the infrastructure is provided by the Central Context Server (CCS). All context related calls first reach the CCS which dispatches the calls to the appropriate background services. An important example is the initial call by a mobile system. Here, the context provided by the mobile system holds only basic information like the ID of the system or the user. The CCS therefore dispatches the request to the next component, the Context Enrichment Service (CES). This service uses further services (Context Enrichment Sources like GIS [41] or rule engines) to enhance the context information. In general the CES tries to derive higher-level information from the given context items. A typical example is the determination of the logical location from the physical location with the help of a GIS. All these inferred context items are added to the context. Using the context and perhaps additional external sources, the Process Retrieval Service (PRS) identifies business processes which are relevant for the given context, i.e. a mobile system. In the case of the initial request, usually only context items are inserted which need to be filled by the mobile system in order to identify relevant business processes. Business process designers model their processes, tag them with context information types from the fundamental context ontology, and store them in a Business Process Repository. The PRS therefore only creates a mapping from the incoming context to some of the business processes. In this sense, the process selection is context driven or triggered [9]: context acts as a process selector. Again, a rule engine is one suitable tool for providing this mapping. The actual decision as to which business process should be started is made by the mobile system or the user himself. The Central Process Engine (CPE) is responsible for the creation, execution and management of the chosen process. When using BPEL, a BPEL Engine, like ActiveBPEL [42], is the central sub-component of the CPE. The sub-component Engine Controller starts an instance of the chosen business process. This is the only, and a deliberate, deviation from usual BPEL practices which expect a client like a mobile system to start the process. The action of the Engine Controller is introduced to obtain

M. Füller et al. / Pervasive and Mobile Computing 8 (2012) 467–482

475

the ID of the process instance started. This ID in turn is necessary for the integration of mobile systems into process instances already running. Unfortunately, the current implementation is to some extent BPEL engine specific. For the ActiveBPEL engine, a typical process will start with the following code:

abx:getProcessId() ... Here, the instance ID is obtained from the engine via abx:getProcessId() and returned to the calling engine controller. The MU holds the mapping between MS and these process instances. It automatically adds the required header information when forwarding a call from the MS to the process and also extracts the process ID from the header to route incoming process calls to the correct MS. Please note that in Active BPEL the abp:engineManagedCorrelationPolicy must be enabled in the deployment descriptor to instruct the engine to use this ID for the assignment of messages to process instances. Last but not least, the ontology service provides all components with access to the fundamental ontology vocabulary. The CES, the PRS and the MU all need a thorough and consistent understanding of the possible context information. In our current implementation, the ontology service was implemented using OSGi and HPs Jena API [43]. A frequently accessed method is boolean isClassOf(String subclassuri, String superuri) which checks if a class identified by its URI is a subclass of a given super class. This service basically uses the method hasSubClass of the Jena class OntClass. 6. Evaluation The evaluation of our implementation of the infrastructure is carried out in two steps. First, we use the case studies from Section 3 to study the functional behaviour of the infrastructure. Implementation details are also considered. Then, we give some results of performance measurements to evaluate non-functional properties. This will address questions concerning resource usage which are left open in the approaches mentioned in Section 2.2. 6.1. Case studies in the infrastructure We start the walk-through with the tourism case study. In COMPASS [26] services are presented on a user’s mobile phone according to her location and profile. This enables integration of mobile systems into processes but this feature is not studied systematically in terms of a context driven design. The features of COMPASS are easily implemented in our infrastructure. The processing in the infrastructure starts with the initial transmission of current context data to the mobile phone provider triggered by the tourist. The structure of the initial context is given in Fig. 5 on the left and denoted as initial context. The initial context is received by the CCS of the provider and forwarded to the CES. Rule engines and GIS for evaluating spatial coordinates may be used to add new context items yielding the middle context, called enriched context, of Fig. 5. In the PRS, the context is further expanded with process descriptions suitable to the context information. This context driven selection of processes is done via rules which first determine the type of relevant processes. Time, weather and personal preference, for example, might indicate that the booking of restaurants may be appropriate. Suitable restaurants may be determined via a GIS. The insertion of process descriptions itself is then done using Drools rules like the following

rule "de.fhdw.tourism" when $list : ArrayList(size>0) from collect( ContextItem(eval(ontoserv.isClassOf(typeURI, "http://de.fhdw#Restaurant")))) then insert(new ProcessDescription("de.fhdw/BookRestaurant", $list)); end

476

M. Füller et al. / Pervasive and Mobile Computing 8 (2012) 467–482

Fig. 5. Evolution of context information in the tourism case study.

Here, the list of restaurants is retrieved using collect from all context items and process descriptions are introduced. The process descriptions are coded as context items containing the URI of the processes selected and current and target states of the processes. The states are given by a state model for processes which slightly extends the BPEL model [20, ch. 5.5]. Examples of states are Running, ToStart or Suspend. The final structure of the context is shown in Fig. 5 on the right. This context envelope is sent back to the tourist, presenting different restaurants for booking. Choosing one restaurant ends the context driven process selection and starts the corresponding process which might include booking a restaurant, updating tourist guides, etc. All in all, the features of COMPASS are reproduced in a context driven way — fulfilling a necessary condition of our infrastructure. In the second case study, in the process model context is not explicitly incorporated — the original context agnostic model is reused. Again, the context processing works basically as before. Of course, the context information a harvester gathers is certainly much more complex than the information a mobile phone manages. However, real world agriculture scenarios [44] suggest that our context model is able to capture this information as well: even complex context information can be broken down into simple type-value pairs. For the sake of this case study, only new sensor information about the tank level of the cereal tank of the harvester is introduced. This may be given in percent, e.g. level = ‘‘90%’’, and is enriched in the CES to ‘‘Critical: rendezvous necessary’’ via a rule like the following one:

rule "de.fhdw.harvest" when ContextItem(civ : contextItemValues) ContextItemValue($uri : typeURI) from civ eval(ontoserv.isClassOf($uri, "http://de.fhdw#PhysTankLevel")); ContextItemValue(value instanceof Integer && value>90) then insert(new LogicalContextItem( "http://de.fhdw#LogTankLevel", new ContextItemValue("http://de.fhdw#StringValue", "Critical"))); end The characteristic of the second case study is the process switch necessary between the harvesting process itself and the rendezvous process to reload the cereal from the harvester to a tumbril when the enriched tank level information changes to ‘‘Critical’’. The switch is initiated by the harvester when the physical tank level exceeds its range, e.g. ‘‘90%’’. Then the context is transmitted to the infrastructure. After context enrichment and process selection by the infrastructure using rules, two process descriptions exist in the context envelope: first, the harvesting process with current state Running and target state Suspend and second, the rendezvous process with current state New and target state Running. According to this information, the driver of the harvester can confirm the switch. The harvesting process is suspended in the BPEL engine and a new instance of the rendezvous process is started. In this context driven approach, the process modelling exhibits two special features. First, neither the harvesting process model — including the interaction with the farm systems for documentation and accounting — nor the rendezvous process model need to explicitly regard context information. Both processes can be modelled separately and basically context agnostically since they are only started when a certain context is on hand. This is in contrast to [4,22] where context information is needed at the process modelling level.

M. Füller et al. / Pervasive and Mobile Computing 8 (2012) 467–482

477

However, the infrastructure provides even more services to process designers. In the process, only the abstract interface of process partners is required. The infrastructure takes over the identification of the actual partners. Consider for example the simplified extract of the tank rendezvous process

... ... in which the rendezvous of the tractor — partnerLink=‘‘Process-To-Tank’’ — is started. This call arrives at the MU. The MU identifies tractors which fit the context of the initiating harvester, e.g. belong to the same farm, are located near the field, etc. One of these tractors is informed and starts the assignment to the running process instance. Here, the ID of the process instance is needed to create response messages which can be routed to the instance. The tractor then performs the tasks indicated in the invoke. This will include the drive to the rendezvous point. After the loading of the tumbril, the process instance schedules update messages to stationary systems for accounting and documentation processes. 6.2. Performance tests The second case study especially demonstrates some of the extensions and simplifications which are possible when adopting the context driven approach. The actual potential of the proposed infrastructure, however, still remains to be tested in more detail. For this purpose, we created a test environment and performed tests on workstations and laptops including single core systems and dual core machines. To compare the retrieved results, we calibrated the values using one system as reference. Of course, absolute numerical values depend on the actual computing resources provided, like CPU and physical memory. They range from several milliseconds to a few seconds. The tests run for several weeks to obtain sufficient data. In these tests we used the farming scenario as the functional test case and the following set of independent parameters: the size of the context sent into the infrastructure, the size of the ontology used for defining the types of context items, the size of the rule base, and finally the number of available processes measured by a hit ratio. Additionally, the number of parallel requests submitted to the infrastructure can be varied. Together this gives a huge range of possible parameter combinations. In the context of this paper, we cannot present a thorough analysis of the performance data but only give some important results and demonstrate them using representative diagrams and examples. The number of context items, ontology entries and the size of the rule base were estimated using evaluations made in real world agriculture scenarios [44]. For example, manufacturers of farming machines expect at most a few hundred items to describe the machine context. So, our measurements should reflect real world situations reasonably well. 6.2.1. Runtime behaviour of the infrastructure In the first series of tests, we record the round trip time (RTT) of the infrastructure for different configuration settings. The RTT indicates the performance of context processing and process selection. Only one round trip is necessary to select a process. The infrastructure has accomplished its tasks as soon as the process starts. Therefore, we do not study the performance of the process itself since this depends entirely on the process. First, we look at the influence of growing context sizes. Clearly, the serialisation of the context envelope will create some overhead. However, some of this overhead may be due to the Web Service specific XML serialisation and deserialisation step. To determine the influence of this step, we compare different implementations of the infrastructure: first an entirely Web Services based implementation and secondly a pure OSGi based form. In the second implementation, all communication is done by simply passing object references eliminating the XML processing almost completely. Typical results are given in Fig. 6. It first shows that there is an almost linear increase in RTT with increasing context size. A significant part of this increase comes from the XML processing. To reduce the influence of this artifact, in the following paragraphs we only present values from the OSGi version. Fig. 6 also shows representative results for the influence of the ontology size on RTT. In either case, Web Services or OSGi, the size of the ontology has no significant effect on the RTT. This is due to the simple structure of our ontology requests: predominantly the method isClassOf is called which only traverses the ontology graph. This result suggests, on one hand, that even extensive ontologies are suitable for certain forms of performance sensitive processing. On the other hand, it points to questions of estimating and reducing the necessary context size. One can assume that realistic context sizes range from around 40 items for the tourist scenario (mainly location information and personal preferences) to several hundred items to describe the context of a farm machine. In realistic scenarios many systems will pose queries to the infrastructure at the same time. To measure the scalability of our infrastructure, we recorded the dependency of the RTT on the number of parallel requests. We simultaneously submitted

478

M. Füller et al. / Pervasive and Mobile Computing 8 (2012) 467–482

Fig. 6. RTT vs. Context size. parameter: (Rules = 50, Threads = 16, HitRatio = 0.5).

Fig. 7. RTT vs. Number of parallel requests. Parameter: (ContextItems = 50, OntologyItems = 100, Rules = 150, HitRatio = 0.5).

a varying number of requests to the infrastructure using multiple threads. We then recorded the RTT for each request and the total time starting from the transmission of all requests until the reception of the last request. The results are given in Fig. 7. Again, a monotonic, O (n) increase is evident. The scalability issue demonstrated by both test series can be resolved when redesigning the infrastructure to reduce serial behaviour. For example, a replication of CES and PRS can be done. Additionally, the frequency of requests can also be reduced using the range concept described above. To illustrate this approach, first consider the case of a tourist walking on foot. Usually she will move at a velocity of about 4 km/h. Assuming typical precision of location systems like GPS of about 20 m, we can assume that new position information becomes available every 20 s. The range of interest for tourist purposes, however, usually extends to the range of vision, say 200 m. Defining a similar range will decrease the frequency of requests sent into the infrastructure by a factor of 9–10. Following a similar reasoning for a farm machine gives an even greater performance gain. A typical farm machine may move at a velocity of about 10 km/h. Using differential GPS precision of about 8 m, this will generate new requests every 3 s. Defining a range for a field to equal 200 m leads to request only every 70 s. Thirdly, we present the influence of the size of the rule base on the RTT. Here, we additionally model the number of processes selectable using a probability measure, i.e. a hit ratio. Fig. 8 shows a monotonic, almost linear increase of RTT with a growing number of rules given a constant hit ratio. This is a representative result in two respects. First, it demonstrates the expected result that the rule base should be kept as small as possible. Second, it shows that the design of the rule base should be aligned with the process models available. A well chosen set of process models will lead to a high hit ratio which in turn may partly compensate the increase with a growing number of rules. Since the connection between the rule base and

M. Füller et al. / Pervasive and Mobile Computing 8 (2012) 467–482

479

Fig. 8. RTT vs. Number of Rules. Parameter: (ContextItems= 20, OntologyItems= 100, Threads= 16).

Fig. 9. Heap space consumption vs. number of rules. parameter: (ContextItems= 50, OntologyItems= 100, Threads= 4, HitRatio= 0.5).

the process models is governed by business logic, in real world scenarios a well-balanced design of both parts will usually be feasible. However, we believe that more systematic work will be necessary in order to simplify the implementation process. 6.2.2. Memory consumption of the infrastructure In the second test series we record the memory consumption of the central components to study the data pressure our application creates. Here, we focus on the effect of growing context, ontology and rule base. In doing so, special care was taken to prevent JVM internal restrictions like maximum heap size from influencing the results. First, the measurements show that the heap space consumption increases almost linearly with the growing number of context items. On the other hand, due to the encapsulation of ontology information in the ontology service an increase in ontology size has no impact on the memory consumption of the other central components (CCS, CES, PRS, CPE). Of course, the memory consumption of the ontology service itself strongly depends on the size of the ontology. For ontologies, which we expect to find in real world scenarios [44], sizes up to a few thousand items are reasonable. In this range, our measurements show a linear increase of memory consumption with growing size of ontology. This fits well to results from [45] although precise numbers largely depend on the implementation of the OWL engine. Fig. 9 gives typical results for the influence of the number of rules on the memory consumption. The increase in heap space usage is clearly sub-linear. A rule engine therefore seems to be a promising way to implement the context to process mapping.

480

M. Füller et al. / Pervasive and Mobile Computing 8 (2012) 467–482

6.2.3. Runtime behaviour on a mobile system In the final test series we look at the runtime behaviour of mobile systems to obtain an evaluation of the complete system consisting of infrastructure and mobile systems. Although these tests are made with the context driven approach in mind, it should be kept in mind that context creation on mobile systems is necessary in both the CD and the CA approach. Of course, the absolute performance numbers given below strongly depend on the type of the mobile system. In our tests we focus on current medium sized hardware. We use commodity smartphones with Android 2.2 and 1 GHz CPU and 576 MB main memory. Typical farm machines often are equipped with more memory. In the tests we concentrate on the behaviour of the context environment, cf. Fig. 3. The demands on the process environment are the same in CA and CD and can be evaluated only in a process specific way. Therefore, they are out of the scope of this article. For current smartphones context sizes of about 10–50 context items seem reasonable since even today the number of embedded sensors (GPS, gyro sensor, proximity sensor, ambient light sensor etc.) is still small. To be on the safe side, in our tests we repeatedly record the time for creating and serializing contexts consisting of 10–1000 items. The overall performance decrease is — again — almost linear. To give some numbers: the creation of 25 context items takes around 73 ms whereas 50 context items require 124 ms. A huge context of 1000 items is created and serialised for network transmission in 2500 ms. These results basically imply that several context transmissions per second are possible. However, the range concept detailed in Section 6.2.1 will further reduce this transmission frequency to about one transmission every 5 or 10 s. This seems entirely feasible even with current medium sized hardware. Our analysis further suggests that main memory is the major restricting factor. So, for future mobile systems context creation and transmission will not pose a particular challenge. 6.3. Evaluation In Section 2.3 basically six distinguishing features of the CD approach are mentioned:

• • • • • •

easy reuse of existing process models systematic treatment of the initial selection of processes context based process management of mobile and pervasive systems dynamic and context dependent routing to fitting process partners optimised runtime behaviour of process execution due to simpler process instances higher validity of context data.

The first three features are demonstrated in Section 6.1 and the basis for the tests in Section 6.2. The results shown above indicate that our implementation actually fulfills these functions. Additionally, the routing feature already works in simple scenarios. To evaluate this feature and the runtime and context validity benefits more systematically further tests in complex situations are necessary. For these features, some evaluation work still needs to be done. Concerning the performance figures some interesting implementation details should also be mentioned. First, the data show that the size of the ontology has no significant impact on the runtime and memory consumption. Categorising and labelling data in the context model OWL works sufficiently well. The size of the rule base on the other hand is relevant to the runtime but not to the amount of memory used. However, since the rule engine resides on central backend systems, this effect can be overcome by scaling the backend vertically. Obviously, the most important influence on both runtime and memory consumption comes from the size of the context. With increasing numbers of context items, not only the RTT and the memory consumption rise linearly. At least during the initial process selection phase the context must be transmitted over a network from the mobile system to the central components of the infrastructure. Latency and, most notably, network bandwidth may limit this communication. Especially on slow networks like GPRS and even UMTS this will introduce an additional performance bottleneck. All in all, context size seems to be the most important delimiting factor. Although there is only a linear increase detectable, a careful design of relevant context information is still necessary. This statement certainly holds for the context aware and the context driven approach. However, in a context driven approach, the processing of context information can be allocated to several components and split up in time. This may somewhat lessen the performance burden context processing always introduces. 7. Conclusion The tight integration of mobile or pervasive systems into business processes offers many benefits for their users: first, users are presented with smarter, value added services better suiting their situation. Second, a greater degree of automation can be achieved which is necessary in many modern business areas, e.g. in modern agriculture industries. On the other hand, manufacturers of mobile systems will also benefit from a closer integration of their products into processes. Value added products may create higher customer loyalty and help fight the widespread problem of plagiarism. Last but not least, entirely new business processes may be possible where mobile systems constitute dynamic but otherwise fully-fledged participants in business processes.

M. Füller et al. / Pervasive and Mobile Computing 8 (2012) 467–482

481

The integration of mobile and pervasive systems into processes inevitably faces the challenge of the strong context dependence of those systems. There are two approaches to handle this challenge. First, the context aware approach focuses on the provision of context within an existing process model. In the second approach — termed context driven — which is studied in this paper, the focus extends to the systems. It conceptually merges the lifecycles of processes and systems into a single coherent view. Although it makes use of only a few simple technical concepts, this starting point offers some advantages. First, it supplements the context aware approach by adding an initialisation phase in which the process relevant to existing context information is selected. In a mobile or pervasive scenario, this often seems to be a very natural point of view. Further execution of this process may then follow the context aware paradigm or — alternatively — make further use of the process management features inherent in the context driven approach. Second, in a context driven framework, process models may get by with fewer context queries at runtime — and perhaps with no queries at all. The handling of context information when modelling processes is greatly simplified. This in turn permits the reuse of existing process models. Third, during runtime processes with a less complex context, processing will only require less work in the process execution environment. Additionally, the number of context transmissions may be reduced. All in all, this may in general lead to faster and more efficient process execution. This reduction in model size might even partly address the demands stated in [21]. Long running process instances require sophisticated methods for dynamic reconfiguration and flexible composition. The dynamic nature of a context driven process selection may render some of these provisions unnecessary. Finally, the explicit inclusion of mobile and context-sensing devices provides hints on how to design such systems to simplify the automatic integration into business processes. The second contribution of this paper is the proposal of a universal infrastructure to implement context driven approaches. This infrastructure successfully deploys a hybrid context model using semantic technologies to bridge the gap to process models. Our implementation uses standard rule engines. Its functional features already comprise context dependent process selection and management and even implement basic features of a dynamic, context dependent identification of and routing to partner systems. Due to the generic nature of our infrastructure, an adaptation to new scenarios requires only the following enhancements in the central components: 1. defining or reusing process models — in general without explicit consideration of context data 2. providing these processes for the infrastructure and creating and deploying adapted rules in CES, PRS and MU. Here, special care should be taken to create a well-balanced combination of rule bases and process models 3. and – only if necessary – customising the ontology. The current performance properties of the infrastructure provide a good basis for future work: for realistic context sizes, the performance of context processing and process selection are promising. Our use of ontologies scales well. The range concept reduces the communication requirements significantly. However, there is obviously much room for optimisation. In more complex scenarios we study the runtime features of process execution. Additionally, we are currently working on a more decentralised version of the infrastructure, elaborate the process management features and the context dependent partner identification. But all in all, we believe that a context driven approach is a workable and valuable contribution to the trend towards ever tighter integration of mobile and pervasive systems into business operations. References [1] P. Zheng, L. Ni, Smart Phone and Next Generation Mobile Computing, Morgan Kaufmann, 2005. [2] W. Schwinger, C. Grün, B. Prll, W. Retschitzegger, Context-awareness in mobile tourist guides, in: Handbook of Research on Mobile Multimedia, 2009. [3] H.-J. Eickerling, M. Benesch, F. Berger, S. Bublitz, Context-aware integration of collaboration services for the support of mobile field operations, in: Challenges in Collaborative Engineering, CCE’07, 2007. [4] Chr. Loeser, R. Trunko, Th. Steckel, K. Podratz, E. Georgiew, F. Swoboda, IT-supported integration of semi-autonomous mobile machines and processes into business and service models, in: iiWAS’08: Proceedings of the 10th International Conference on Information Integration and Web-based Applications & Services, 2008. [5] M.A. Mu noz, M. Rodríguez, J. Favela, A.I. Martinez-Garcia, V.M. González, Context-aware mobile communication in hospitals, IEEE Computer 36 (9) (2003) 38–46. [6] A.K. Dey, G.D. Abowd, Towards a better understanding of context and context awareness, GVU Technical Report, College of Computing, Georgia Institute of Technology, 1999. [7] L. Ardissono, R. Furnari, A. Goy, G. Petrone, M. Sagnan, Context-aware workflow management, in: L. Baresi, P. Fraternali, G. Houben (Eds.), Proceedings of the Seventh International Conference on Web Engineering, ICWE 2007, in: Lecture Notes in Computer Science, vol. 4607, Springer, Berlin, 2007, pp. 47–52. [8] M. Wieland, O. Kopp, D. Nicklas, F. Leymann, Towards context-aware workflows, in: CAiSE07 Proceedings of the Workshops and Doctoral Consortium 2, Trondheim, 2007. [9] B. Schilit, N. Adams, R. Want, Context-aware computing applications, in: IEEE Workshop on Mobile Computing Systems and Applications, 1994. [10] M. Baldauf, S. Dustdar, F. Rosenberg, A survey on context aware systems, International Journal of Ad Hoc and Ubiquitous Computing 2 (2007) 263–277. [11] B. Schilit, M. Theimer, Disseminating active map information to mobile hosts, IEEE Network 8 (1994) 22–32. [12] T. Strang, C. Linnhoff-Popien, A context modeling survey, in: 1st International Workshop on Advanced Context Modeling, Reasoning and Management, UbiComp, Nottingham, 2004, pp. 33–40. [13] C. Bettini, O. Brdiczka, K. Hendricksen, J. Indulska, D. Nicklas, A. Ranganathan, D. Riboni, A survey of context modelling and reasoning techniques, Pervasive and Mobile Computing 6 (2009) 161–180. [14] T. Gu, H.K. Pung, D.G. Zhang, Toward an OSGi-based infrastructure for context-aware applications, IEEE Pervasive Computing 3 (2004) 66–74.

482

M. Füller et al. / Pervasive and Mobile Computing 8 (2012) 467–482

[15] T. Gu, H.K. Pung, D.Q. Zhang, A service-oriented middleware for building context-aware services, Journal of Network and Computer Applications 28 (2005) 1–18. [16] B. Rao, L. Minakakis, Evolution of mobile location based services, Communications of the ACM 46 (2003) 61–65. [17] C. Becker, D. Nicklas, Where do spatial context models end and where do ontologies start? A proposal of a combined approach, in: Ubicomp 2004 Workshop on Advanced Context Modeling, Reasoning and Management, 2004. [18] O. Lehmann, M. Bauer, C. Becker, D. Nicklas, From Home to World Supporting Context-aware Applications through World Models, in: Proceedings of the Second International Conference on Pervasive Computing and Communications, PerCom, 2004, pp. 297–306. [19] M. Samulowitz, F. Michahelles, C. Linnhoff-Popien, CAPEUS: an architecture for context-aware selection and execution of services, in: Proceedings of the Third IFIP WG 6.1 International Conference on Distributed Applications and Interoperable Systems, Springer, Berlin, 2001, pp. 23–39. [20] OASIS, WSBPEL V. 2.0, 2007. http://docs.oasis-open.org/wsbpel/2.0/wsbpel-v2.0.pdf. [21] S.K. Shrivastava, S.M. Wheater, Architectural support for dynamic reconfiguration of distributed workflow applications, in: IEE Proceedings — Software, 2002. [22] M. Wieland, P. Kaczmarczyk, D. Nicklas, Context integration for smart workflows, in: Proceedings of the 6th Annual IEEE International Conference on Pervasive Computing and Communications, 2008, pp. 239–242. [23] D. Chakraborty, H. Lei, Pervasive enablement of business processes, in: Proceedings of the Second IEEE Annual Conference on Pervasive Computing and Communications, 2004, pp. 87–97. [24] St. Urbanski, E. Huber, M. Wieland, F. Leymann, D. Nicklas, PerFlows for the computers of the 21st century, in: IEEE International Conference on Pervasive Computing and Communications, PerCom, 2009, pp. 1–6. [25] O. Saidani, S. Nurcan, Towards context aware business process modelling, in: Proceedings of the 8th Workshop on Business Process Modelling, Development, and Support (BPMDS) at the 19th International Conference on Advanced Information Systems Engineering, CAiSE07, Springer, Berlin, 2007. [26] M.v. Setten, S. Pokraev, J. Koolwaaij, Context-aware recommendations in the mobile tourist application COMPASS, in: W. Nejdl, P. De Bra (Eds.), Proceedings of the International Conference on Adaptive Hypermedia and Adaptive Web-Based Systems, AH04, in: Lecture Notes in Computer Science, vol. 3137, Springer, Berlin, 2004, pp. 235–244. [27] B. Johanson, A. Fox, T. Winograd, The interactive workspace project: experiences with ubiquitous computing rooms, IEEE Pervasive Computing (April–June) (2002) 71–78. [28] R. Grimm, et al., One.world: experiences with a pervasive computing architecture, IEEE Pervasive Computing 3 (2004) 22–30. [29] A. Srinivasan, Handbook of Precision Farming, Haworth Press, 2006. [30] N. Wang, N. Zhang, M. Wang, Wireless sensors in agriculture and food industry — recent development and future perspective, Computers and Electronics in Agriculture 50 (2006) 1–14. [31] European Parliament, Regulation No. 178/2002 of the European Parliament and of the Council of 28 January 2002 laying down the general principles and requirements of food law, establishing the European Food Safety Authority and laying down procedures in matters of food safety, Official Journal L 031, 01/02/2002 P. 0001–0024. [32] X.H. Wang, D.Q. Zhang, T. Gu, H.K. Pung, Ontology based context modeling and reasoning using OWL, in: Proceedings of the Secondn IEEE Annual Conference on Pervasive Computing and Communications Workshops, IEEE, Orlando, 2004, pp. 18–22. [33] W3C, OWL Web Ontology Language Guide, 2004. http://www.w3.org/TR/owl-guide/. [34] T. Hofer, W. Schwinger, M. Pichler, G. Leonhartsberger, J. Altmann, Context-awareness on mobile devices — the hydrogen approach, in: IEEE Proceedings of the 36th Annual Hawaii International Conference on System Sciences, IEEE, 2003, pp. 10–19. [35] JBoss.org, jBPM Process Definition Language (JPDL), 2009. http://www.jboss.com/products/jbpm/docs/jpdl/. [36] Gregory Hackmann, Christopher Gill, Gruia-Catalin Roman, Extending BPEL for interoperable pervasive computing, in: IEEE International Conference on Pervasive Services, IEEE, 2007, pp. 204–213. [37] OSGi Alliance, OSGi R4, 2005. http://www.osgi.org/Release4/HomePage. [38] Th. Erl, Service-Oriented Architecture — Concepts, Technology, and Design, Prentice-Hall, 2005. [39] Apache Foundation, Apache CXF, http://cxf.apache.org/. [40] JBoss.org, JBoss Drools, 2008. http://www.jboss.org/drools/. [41] P. Longley, M.F. Goodchild, D.J. Maguire, D.W. Rhind, Geographic Information Systems and Science, Wiley, 2005. [42] Active Endpoints, ActiveBPEL, http://www.activevos.com/community-open-source.php. [43] HP Labs, Jena — A Semantic Web Framework for Java, 2009. http://jena.sourceforge.net/. [44] r2b — Robot To Business, Project of the SimoBit program of the German Bundesministerium für Wirtschaft und Technologie (BMWi), 2009. http://www.r2b-online.de. [45] Y. Guo, Z. Pan, J. Heflin, LUBM: a benchmark for OWL knowledge base systems, Web Semantics: Science, Services and Agents on the World Wide Web 3 (2005) 158–182.