Toward Context-Awareness: A Workflow Embedded Middleware

Toward Context-Awareness: A Workflow Embedded Middleware Shaxun Chen, Yingyi Bu, Jun Li, Xianping Tao, and Jian Lu National Laboratory for Novel Software Technology, Nanjing University Nanjing City, P.R. China, 210093 [email protected]

Abstract. Context-aware computing is widely researched in recent years, but we lack for a powerful context-aware middleware which supports a uniform programming model. So developing context-aware applications is still complex and time-consuming. We introduce a workflow embedded middleware called FollowMe. It supports pluggable context-aware applications. FollowMe includes a workflow engine and sustains applications described with pvPDL, which is a workflow definition language proposed specially for context-awareness. The employment of workflow makes the development of applications simplified and the maintenance much easier. We testify the improvement by realizing an example and the related evaluation.

1 Introduction The concept of pervasive computing was introduced by Mark Weiser in 1991. He described pervasive computing as the everywhere and anytime computing which is transparent to users [1]. Pervasive computing calls for a new human-computer interaction mode in order to decrease users’ attention to computing and make computing invisible to users. To achieve this, context-awareness is developed. Contexts refer to any information that portrays the situation of users and the environments the users in. Computational devices with the ability of context-awareness can follow the situation and provide the users with adequate services without users’ intended input. Although context-aware computing is progressing rapidly, developing context-aware applications is still a complex and time-consuming job. Application developers should learn the details about bottom layers such as the working state of sensors. When an application changes they should totally rewrite the program, and when the domain varies, little work can be reused. Furthermore, applications are self-governed. They do not have a uniform construction so that they cannot share an infrastructure and developers can not reuse the common parts of them. Besides, most context-aware projects pay their attention to providing a single service instead of a flow of services. In this paper, we establish a middleware called FollowMe, which shields bottom layers details, and provides a workflow based programming model for context-aware applications.

Funded by 973 of China (2002CB312002) and 863 Program of China (2005AA113160, 2005AA113030, 2005AA119010), NSFC (60233010, 60403014).

J. Ma et al. (Eds.): UIC 2006, LNCS 4159, pp. 766–775, 2006. c Springer-Verlag Berlin Heidelberg 2006

Toward Context-Awareness: A Workflow Embedded Middleware

767

Our system includes a workflow engine. It is event-declarative and RDQL [2] apprehensible. FollowMe supports pluggable applications described with pvPDL (Pervasive Process Definition Language), which is a workflow definition language designed for context-awareness. The development of context-aware applications become more efficient and workload of maintenance is highly reduced in virtue of workflow. Our programming model is constructed upon the OSGi [3] framework and ontology based context model. OSGi provides modularization and platform independency, and the services organized by OSGi are hot-pluggable. With the help of domain-independent context model, FollowMe can be customized to specific domains by deploying domain related ontology. The rest of paper is organized as follows. We list related work in section 2 and discuss why workflow is suitable for context-aware middleware in section 3. In section 4, we give an overview of FollowMe’s architecture. Then we describe the implementation of the workflow system and the characters of pvPDL in section 5, and show a scenario described with pvPDL as an example in section 6. At last, we evaluate our system and conclude respectively in section 7 and 8.

2 Related Work This paper is part of work of FollowMe Project. While [13] is an overview of FollowMe system, this paper focuses at the workflow based programming model which facilitates the pervasive application development and distinguishes our system from others. We notice that there are mainly two methods for context exploitation in existing projects. One is the event-trigger mechanism, such as Context-toolkit [4], Context Fabric [5], and Context Cube [6]. The common ground of them is treating a context as an event and providing services in the callback of the event. The other is the rule-based declarative programming method. There are some prototype systems employing this method to specify context-aware application behaviors, such as [7]. Jose J. Alferes, et al. proposed an more flexible approach using Logic Program Updates, in which the rules for context-awareness changed dynamically [8]. However, these studies focused on one single service rather than a serial of services. In pervasive computing environments, an application may be composed of a chain of services triggered by a sequence of contexts. If we use the simplex event-trigger mechanism to process these scenes, we have to register an event in the callback of the previous event, that is, recursive event registers. It leads to ugly and unreadable programs. Declarative programming is a good choice in some domains, but it is sometime inefficient. When there is a flow of contexts and some context is the precondition of another, rules become complicated and performance goes very low. So, we introduce a workflow model to exploit contexts and develop applications. Having a workflow system, we also need a workflow definition language to describe applications. Actually, there are quite a few such languages as XPDL [9], BPML [10]. But they have several problems when adapting to context-awareness. First, context information is a complex set of data. Traditional workflow definition languages can not express them felicitously. Second, services of a context-aware application can not simply use another service’s result, but instead context information obtained from users

768

S. Chen et al.

and environments. So we propose pvPDL to describe context-aware applications in our system. [14] also proposed a workflow language which combined with web services for ubiquitous computing. However, there were few clues indicating that the workflow language they used was optimized and suitable for pervasive applications. In contrary, we endow our workflow engine with event-declaration and RDQL comprehension abilities which strengthen the description competence of contexts and simplify the development of context-aware applications. These will be discussed in part 5.

3 Benefits of Workflow for Context-Awareness Workflow is the automation of a business process, that is, a serial of related activities [11]. The workflow technology has been successfully applied to the traditional business domain and distributed computing. We use workflow to perform services composition, flow management, task distribution and collaboration. In pervasive computing environments, people get right services at right time without users’ intervention. However, a user may request a flow of services and these services are highly related. What’s more, most context-aware applications of smart environments have inherent business flow logic and can be divided into several simple parts (services). In these cases, workflow is highly applicable for pervasive computing. When workflow meets context-awareness, it shows advantages as follows. Firstly, with the help of workflow, FollowMe can support pluggable context-aware applications and software structure is clearer. We define pluggable applications as those applications which can be deployed, removed and updated dynamically by only modifying configuration files without stopping the system. Workflow decouples business logic and the realization of concrete functions. In our system, a context-aware application appears as a workflow description file (a pvPDL file) and a number of encapsulated services. We can add or update an application by adding or modifying a corresponding pvPDL file at runtime (See section 5). In FollowMe, applications built in the workflow model are pluggable and structured. As a result, it contributes to the flexibility and modularization of FollowMe. Secondly, workflow simplifies the development of context-aware applications. These applications are usually driven by a chain of events (contexts or variation of contexts). In traditional hardcode mode, we have to register the next event in the codes processing the previous event. It will cause the confusion of software structure when the event chain is very long. This is only an aspect of the improvement on application development; we will discuss it in part 1 of section 7. Moreover, developing applications in workflow mode facilitates reuse. As mentioned above, an application is divided into several simple parts and some of them can be reused by other applications. For example, “personal identification” can be shared with quite a few context-aware applications. Workflow raises the level of reuse. The cost of maintenance is reduced in workflow systems as well. Formerly, when an application changes, even just two steps of application exchange, we have to rewrite large quantities of codes. Now, in the workflow model, When the flow changes, we just modify application description files (pvPDL files) and, if function changes, modify a


769

few codes. The pvPDL files are declarative specifications rather than explicit programming behaviors. So modification is much easier. In addition, workflow helps us distribute tasks to each user and facilitates the collaboration between them. Actually, most of practical context-aware applications have a flow of services and call for the cooperation between users. Traditional methods can not deal with the collaboration of services in a concise way, and this is the strongpoint of workflow. By the way of organizing services and distributing them to proper users, workflow actualizes cooperation in context-aware applications easily. Finally, in our system, applications are described with pvPDL which is declarative specifications. It is propitious to turn our system to be data-centric and platform independent. In FollowMe, context-aware applications can run on the any OSGi equipped computational device which has pvPDL files. Services needed can be downloaded from network at runtime.

4 Architecture View Overview of FollowMe’s architecture. As Fig.1 illustrates, our system has three layers: physical, platform and application layer. Physical layer gathers data from physical world via various sensors and formats them to be computer-readable. We use Crickets [12] to perceive users’ positions and Mica2 [12] for light, noise, temperature, etc. Platform layer is the core of FollowMe. It is built on OSGi framework and manages all services to facilitate the developing and deploying of context-aware applications. Platform layer shields details of the physical layer. It includes an ontology based context model and a workflow system, which will be discussed in the next section. Application layer uses services and libraries provided by the platform layer. It includes pvPDL files which describe business logic of applications, and a GUI called FollowMe Application Builder for developing context-aware applications graphically (See Fig. 3).

Fig. 1. FollowMe middleware architecture

770

S. Chen et al.

OSGi platform. OSGi framework supports hot-pluggable modules called bundles, which can be downloaded and deployed at runtime. FollowMe is built on OSGi platform; the services, including workflow services and context services, are encapsulated in bundles (See Fig.1). Another advanced character of OSGi is platform independency. System built on OSGi can be easily ported to PDAs, smart phones, etc. Ontology based context model. FollowMe’s context model is based on ontology and described with OWL. This model is formalized and flexible. FollowMe can be customized to specific domains by deploying domain related ontology. In the scenario of section 6, we customize it to support the office automation domain. In Fig. 1, context providers bundle interacts with sensors and transforms sensor data to raw contexts; context services bundle generates high-level contexts from raw contexts and manages contexts’ life cycle and conflicts. Physical distribution. In our smart environment, sensors, context providers, and context consumers (applications) are physically distributed. The workflow engine and the context reasoner are on the central node. Computers connect through ethernet and wireless network.

5 Workflow System and Pervasive Process Definition Language The employment of workflow is a remarkable contribution of FollowMe. In this section we will discuss the workflow system in detail. 5.1 Running Mechanism of Workflow System The business logic of a context-aware application is described in a pvPDL file. This file is firstly parsed by the pvPDL syntax checker. If passed, it will be explained by the pvPDL analyser and the result is stored. The starting condition of the application is registered to the workflow manager. These are done only when the system starts or the application is deployed on FollowMe for the first time. When the condition is satisfied, the analysis result will be read and executed in a new thread by the workflow engine which is on the central node. The workflow engine calls various Process Units, which provide services to perform the functions of activities. Common Process Units can be reused among different applications while Private Process Units are specially for one application. Physically, they are both encapsulated in bundles and located in distributed nodes. The unit registry bundle discovers and registers new Process Units automatically. The modules mentioned above have been shown in the middle layer of Fig.1. We can see that if we want to add a new application to FollowMe, the only work is creating a pvPDL file and some Private Process Units. Process Units can be reused among applications and downloaded from other nodes at runtime. So only a few Process Units should be developed. Both the file and the units can be deployed to the middleware dynamically, having no influence on other running applications. When we want to change or remove an application, we can modify or deregister the pvPDL file and corresponding Process Units. The workflow system detects the alteration of applications automatically.


771

5.2 Workflow Engine The workflow engine is also a bundle on the OSGi platform. Our workflow engine has parallel processing ability, supporting multi-applications at the same time. Besides, the engine has two remarkable characters: event-declaration and RDQL apprehension. Event-declaration. This is not the simplex event-trigger mechanism. What we should do in FollowMe is just describing events in pvPDL files. All the rest of work such as registry and callback are done by the engine automatically. Moreover, if there are a sequence of events, we just list these events in the pvPDL file but needn’t call back recursively, which should be done in simplex event-trigger systems for contextawareness. On the other hand, traditional workflow systems can not do this either. They use a condition judgement for state-transition constraints. This is a query mechanism and has poor performance. In our system, both the application and the activities can be triggered by events. Meanwhile, state-transition constraints are reserved. Consequently, contexts can be pushed or pulled by the engine as needed, which simplifies application development. RDQL comprehension. RDQL is a query language which can select matched RDF triples from a triple set. RDQL can describe complex information flexibly by composing triples. And our context information, including value, data type, relations among data types, time stamp and TTL, is a complicated set of data. So we choose RDQL to specify contexts in our system. The workflow engine is RDQL-apprehensible. Developers can describe demanded contexts by giving an RDQL query sentence in pvPDL files. The events in applications are also represented by RDQL. The engine will parse them and get suitable contexts or register the events to the context service. Traditional workflow systems can not express contexts felicitously and, of course, can not deal with them. 5.3 Pervasive Process Definition Language The pvPDL is a workflow definition language. We propose it to describe context-aware applications. The pvPDL is represented in the XML format and we definite the syntax of pvPDL in pvPDL-Schema. We will not lay out the schema for it is too long. We give a syntax checker to testify the validity of pvPDL files. The pvPDL is context-describable and event-declarative. The top level element “Process” stands for a unique application. Within the element “DataFields”, constant and variable are defined, which can be shared with all steps in the application. “Activities” is the aggregation of the element “Activity” which points to a specialized step of the application. Subelements of “Activity” direct some Process Unit performing the task and declare the parameters passing to it, actual and formal both acceptable. The elements “Process” and “Activity” both have the attribute “event”, which gives the triggering event, represented in RDQL, of its parent element. As the subelement of “Transitions”, “Transition” describes the paths between activities, while its attribute “condition” indicates the context constraints of the path in query mode. Here we pass over many other details of pvPDL. If you feel writing a pvPDL file still tedious, you can use flow diagrams to describe your applications. What you should do is dragging and dropping the graphical elements

772

S. Chen et al.

Fig. 2. Meaning of elements in flow diagrams

in FollowMe Application Builder. The diagrams you draw can be translated to pvPDL files automatically. Fig.2 shows the meaning of elements in flow diagrams, and we will give a scenario represented by the flow diagram in the next section.

6 Case Study Scenario. Imagining you are a member of a research group, and you will give a lecture in a seminar. You should copy the slides to your flash disk, carry it to the meeting room, copy the slides to the computer in the meeting room, and then open them. The work is tedious and much attention is wasted. In our ideal, the lecturer needn’t do anything but editing the lecture notes. The latest version of the slides should be uploaded to the server. And it will be downloaded to the computer in the meeting room and opened when the lecturer enters the room and comes near the lectern. The work above is done automatically following the schedule contexts and user’s position contexts. When a stranger comes into the meeting room, a warning will appear on the screen to prompt lecturer to take care of sensitive information. When the lecturer leaves, the slides close automatically. Implementation. We develop an application named Seminar Assistant which is divided into two parts. One is called User Assistant and runs on the computer of the user. The other called Meeting Assistant runs on the computer in the meeting room. User Assistant uploads the slides when they are modified, while Meeting Assistant is responsible for opening and closing the slides automatically and warning the lecturer when a stranger comes in. Here we explain Meeting Assistant in detail. Fig.3 shows the GUI of FollowMe Application Builder. The upper right quadrant of the window is the flow diagram of Meeting Assistant and the bottom of right is a segment of the corresponding pvPDL file translated automatically. As the figure shows, Meeting Assistant has four activities. The task of the first activity (marked with A1 in the figure) is opening the slides. It is activated by the speaker entering the meeting room and this time fitting with the calendar in the profile context. The third (A3) activity closes the slides and the fourth(A4) shows a warning. They are triggered by the leaving of lecturer and coming of a stranger respectively, depicted by the circle in the figure. The second activity(A2) is a virtual activity


773

Fig. 3. GUI of FollowMe Application Builder. The upper right quadrant is the flow diagram of Meeting Assistant and the bottom of right shows a segment of the corresponding pvPDL file.

Fig. 4. Effect of Meeting Assistant when a stranger comes in. The bottom of right shows the smart environment.

for the need of flow transition. We develop Process Units “Slides Manager” shared by the first and third activities, and “Message Box” for the fourth. They are parameterized and can be reused in other applications. Runtime effect. Fig.4 shows the effect of Meeting Assistant when a stranger comes into the meeting room during the seminar. Other applications. Seminar Assistant is somewhat simple in application logic, which is convenient for us to illustrate the working mechanism of our system. Besides, we have developed several other applications, including Active Map and Security Manager, which embody the advantages of workflow for their more complicated logic.

774

S. Chen et al.

7 Evaluations Application development efficiency. We develop the Seminar Assistant in the ad-hoc method and workflow model respectively. By ad-hoc method, we spend about 10 mandays. We interact with a number of sensors and specify the program behaviors by the physical data get from them. Development of the application is complicated and we spend a lot of time in debugging and testing. When using the latter method, two persons use just one day to complete it. Later, we develop Active Map and Security Manager in the same way, and they cost 4 man-days respectively. In this case, bottom layer details are shielded and we needn’t care about them. We only develop simple services and then draw a flow diagram to describe the business logic of applications. Data management, flow control, etc. are done by FollowMe automatically. So we can see the time cost is highly reduced. FollowMe’s performance. We test the time cost of Seminar Assistant to evaluate FollowMe’s performance. In Fig.5, the first two lines are the time cost of Seminar Assistant developed in the ad-hoc method, and another two lines show the performance with FollowMe middleware. For each method, we collect two sets of data when the file size of slides is 50KB and 500KB respectively. We do this in order to find the effect of network traffic on FollowMe’s performance. “Total time” stands for the latency between lecturer’s coming and the opening of slides. And we check system time in each part of the program to get detailed information. The data in the form is the average of measured values and the unit is millisecond. The hardware configuration of the central node is 2-XEON-2.8GHz and 4GB-RAM. We also do the test for other applications; the time cost rates of each part are similar.

Fig. 5. Performance evaluation of FollowMe and the workflow system

From the data we can see the application running on FollowMe is slower than the ad-hoc method. However, FollowMe brings about great advantages for context-aware computing and a latency of one second is acceptable to users. And we can see the main cost of FollowMe is context processing. FollowMe provides contexts for a number of applications simultaneously so that the context library is larger. This context library can support Active Map and Security Manager as well, while ad-hoc method can not. A little more time contributes to more abilities. We also test the response time of our system when three applications mentioned above run simultaneously on FollowMe. The latency of a certain application rises linearly by the increase of the number of applications deployed on the framework. This result manifests that efficiency of this middleware is fine.


775

Workflow system performance. In Fig.5, the last column shows the time cost including the workflow system and network transport. It only takes a small part of the total time. This result attests that the workflow system does not depress FollowMe’s performance obviously. Compared with its advantages, it’s completely worthwhile introducing workflow to context-awareness. And we will develop a distributed context processing mechanism and distributed workflow engines in the next stage of our work. It can be expected that the performance will be even better and time delay will be no trouble for users.

8 Conclusion and Future Work FollowMe is a service-oriented, pluggable and programmable context-aware middleware. It supports workflow based applications and we propose a new workflow definition language pvPDL for context-awareness. The case study and evaluations show that workflow simplified context-aware application development and has good performance. In the near future we will standardize the service called by workflow engine and work towards a distributed context processing mechanism to improve efficiency and robustness.

References 1. Weiser M.: The Computer for the 21st Century. In: Scientific American, September 1991. (1991)94-100 2. RDF Data Query Language. http://www.w3.org. 3. Open Service Gateway initiative. http://www.osgi.org. 4. A. K. Dey, et al.: A Conceptual Framework and a Toolkit for Supporting the Rapid Prototyping of Context-Aware Applications. Anchor article of a special issue on Context-Aware Computing. In: Human-Computer Interaction (HCI) Journal, 16(2-4). (2001)97-166 5. J. Hong and J. Landay.: An infrastructure approach to context-aware computing. In: HumanComputer Interaction (HCI) Journal, 16(2-4). (2001)287-303 6. Lonnie Harvel, Ling Liu, Gregory D. Abowd, et al.: Context Cube: Flexible and Effective Manipulation of Sensed Context Data. In Proceedings of the Second International Conference on Pervasive Computing, April 2004, Linz/Vienna, Austria. Springer-Verlag, (2004) 51-68 7. Wolfgang Beer, et al.: Modeling Context-Aware Behavior by Interpreted ECA Rules. In Proceedings of Parallel Processing, 9th International Euro-Par Conference, August 2003. Springer, Klagenfurt, Austria (2003)1064-1073 8. Jose J. Alferes, et al.: Computing Environment-Aware Agent Behaviours with Logic Program Updates. In Proceedings of Logic Based Program Synthesis and Transformation, 11th International Workshop, November 2001. Springer, Paphos, Cyprus (2001)216-232 9. XML Process Definition Language. http://www.wfmc.org. 10. Business Process Modeling Language. http://www.bpmi.org. 11. The Workflow Reference Model (WFMC-TC00-1003 Issue 1.1). WfMC (1995) 12. Sensors produced by Crossbow. http://www.xbow.com. 13. Jun Li, YingYi Bu, Shaxun Chen, Xianping Tao, Jian Lu.: FollowMe: A Pluggable Infrastructure for Context-Awareness. In Ubicomp2005, Tokyo, Japan (2005) 14. Joohyun Han, et al.: Context-aware Workflow Language based on Web Services for Ubiquitous Computing. In LNCS3481 - ICCSA2005. Springer (2005)1008-1017