A Generative Programming Framework for Context-Aware ... - CiteSeerX

A Generative Programming Framework for Context-Aware CSCW Applications DEVDATTA KULKARNI, TANVIR AHMED and ANAND TRIPATHI University of Minnesota, Minneapolis

We present in this paper a programming framework based on the paradigm of generative application development for building context-aware collaborative applications. In this approach contextaware applications are implemented using a domain-specific design model, and their execution environment is generated and maintained by the middleware. The key features of this design model include support for context-based service discovery and binding, context-based access control, context-based multi-user coordination, and context-triggered automated task executions. The middleware uses the technique of policy-based specialization for generating application-specific middleware components from the generic middleware components. Through a case-study example, we demonstrate this approach and present the evaluations of the design model and the middleware. Categories and Subject Descriptors: D.2.11 [Software Architectures]: Domain-specific architectures; D.3.2 [Language Classifications]: Specialized application languages; D.2.6 [Software Engineering]: Programming Environments; D.4.6 [Security and Protection]: Access controls General Terms: Design, Experimentation, Languages, Measurement, Security Additional Key Words and Phrases: Context-Aware Computing, Pervasive Computing, Generative Middleware

1.

INTRODUCTION

In recent years, there has been a growing interest in designing and building contextaware applications [Weiser 1991; Schilit et al. 1994] that adapt their behavior based on the changing ambient conditions of the user’s physical environment. Context refers to a situation in the physical or the virtual world that may be utilized by an application for the purpose of dynamic adaptation, for example, to acquire ambient resources and services needed in a given location. Such applications may also involve multiple users interacting based on the CSCW (Computer-Supported Cooperative Work) models for workflow and “group-aware” collaborative activities. Emerging CSCW applications aim at utilizing context information for enhancing application functionalities. Examples of context-aware CSCW applications include assisted living [Consolvo et al. 2004], hospital information systems [Bardram et al. 2006], and tour guides [Davies et al. 2001]. This work was supported by National Science Foundation grants 0411961, 0708604, and 0834357. This paper is a revised and extended version of papers presented at ICDCS 2002, SACMAT 2008, and SEPCASE 2007. Permission to make digital/hard copy of all or part of this material without fee for personal or classroom use provided that the copies are not made or distributed for profit or commercial advantage, the ACM copyright/server notice, the title of the publication, and its date appear, and notice is given that copying is by permission of the ACM, Inc. To copy otherwise, to republish, to post on servers, or to redistribute to lists requires prior specific permission and/or a fee. c 20YY ACM 0000-0000/20YY/0000-0001 $5.00

ACM Transactions on Software Engineering and Methodology, Vol. V, No. N, Month 20YY, Pages 1–0??.

2

·

Devdatta Kulkarni et al.

Building context-aware CSCW applications is a challenging task because of several reasons. Such applications need context-based dynamic integration of application components, ambient resources, and infrastructure services. They need support for different kinds of user interaction models and access control policies, which can be context dependent. Some of the applications involve users who move across different physical spaces and administrative boundaries while engaged in application activities. Traditional design approaches for building context-aware CSCW applications has been to custom-build an application for some specific targeted domain, such as city tour guides [Davies et al. 2001], context-aware communication facilities [Henricksen and Indulska 2004], and interactive museums [Fleck et al. 2002]. Such approaches require custom design and implementation of complex protocols for dynamic resource discovery and access control. This results in high cost of programming and development efforts. Moreover, such approaches do not easily support design modifications needed due to changes in design requirements or technology evolution.

XML−based Activity−Template 1

Shared Application Resources, and Services

XML−based Activity−Template 2

Application Generation Framework (Application Compiler, Policy−driven Middleware)

Context−Aware Collaboration Environment (based on design 1)

Context−Aware Collaboration Environment (based on design 2)

Fig. 1. Regeneration of context-aware applications based on different specifications We present here a domain-specific programming framework that we have developed for building context-aware applications from their domain-specific high-level specifications. This framework embodies principles of the generative programming paradigm [Czarnecki and Eisenecker 2000]. In this framework, context-aware applications are designed using a domain-specific design model and realized through a policy-driven distributed middleware [Tripathi 2002; Tripathi et al. 2002]. The design model is expressed in XML. This design model and the middleware together provide a composition framework for integrating users, application-defined components, and infrastructure resources and services to build the execution environment of a context-aware CSCW application. The process of generating an application’s execution environment in this framework is shown in Figure 1. In this approach, a construct called activity template is used as the high-level abstraction for specifying the design of a context-aware application. The activity template is integrated with the shared application resources and ambient services to instantiate the execution environment of an application. Such an integration uses various kinds of policies which are derived from the activity template. These policies are related to dynamic resource discovery and binding, context-based multi-user coordination, and contextbased access control. Different activity templates can utilize the same resources and ACM Transactions on Software Engineering and Methodology, Vol. V, No. N, Month 20YY.

A Generative Programming Framework for Context-Aware CSCW Applications

·

3

services and instantiate different execution environments for a particular kind of a context-aware application. There are several advantages of using this generative approach in our programming framework. First, the domain-specific design model provides mechanisms for programming a context-aware CSCW application using a set of high-level abstractions, thus simplifying their designs. Second, the middleware provides generic components that encapsulate protocols for context-based service discovery and binding, user authentication, secure interactions among distributed components, contextbased access control, and inter-task coordination. This relieves the programmer from the task of custom development of such protocols. Third, we provide tool support to verify domain-specific security and coordination properties of the synthesized context-aware applications [Ahmed and Tripathi 2007]. Using this framework we have designed and implemented several context-aware CSCW applications in our testbed environment which include a context-aware patient information system, a collaborative whiteboard, a context-aware music player [Kulkarni and Tripathi 2008b], a context-aware distributed meeting [Tripathi et al. 2005], a student examination application [Ahmed and Tripathi 2007], and an emulation of a museum environment. Towards supporting the generative techniques for building the execution environments of context-aware applications from their high-level design specifications, this paper makes the following contributions. —Development of a domain-specific design model for programming context-aware collaborative applications. This model supports abstractions and mechanisms for context-based service discovery and binding, context-based access control, context-based multi-user coordination, and context-triggered automated task executions. —Development of a generative process for creating the execution environments of context-aware applications. We present the architecture of the middleware components, the runtime data structures and their use by the middleware components. —Development of techniques for the derivation and representation of applicationspecific policies, and their integration with the middleware components for building an application’s execution environment. This paper is organized as follows. In Section 2 we present the domain requirements for context-aware CSCW applications. In Section 3 we present the high-level declarative model that we have developed for designing context-aware applications. In Section 4 we present the generative middleware, concentrating on the following aspects: the process of creating the execution environment of a context-aware application, data structures for managing the execution environment of an activity, policy derivation procedures, and architecture of various middleware components. In Section 5 we evaluate this programming framework’s capabilities for generating the execution environments of context-aware applications, present our experiences and lessons learned from using this framework in developing several context-aware applications, and discuss the model’s extensibility. In Section 6 we compare our work with the related work. In Section 7 we discuss the future work, and conclude in Section 8. ACM Transactions on Software Engineering and Methodology, Vol. V, No. N, Month 20YY.

4

2.

·


DOMAIN REQUIREMENTS

Here we present the main requirements of context-aware applications that formed the basis for developing the domain-specific design model in our programming framework. These requirements are related to the following characteristics of contextaware applications: context-based dynamic discovery of and binding to resources, context-triggered automated task executions, dynamic access control, and contextbased multi-user coordination. The first two characteristics have been identified as key characteristics of such applications since the earliest days of context-aware computing [Schilit et al. 1994], whereas the latter two have become important in recent years as the realm of context-aware computing has extended to include domains such as health-care systems. The ambient computing environment in which context-aware applications are deployed is called an active space [Rom´ an et al. 2002]. Such a space may span multiple physical spaces. An active-space provides the infrastructure services that are required for deploying and running context-aware applications. Such services include context services, discovery services, naming services, and services for authorization and access control [Rom´ an et al. 2002; Garlan et al. 2002]. An application needs to interface with one or more context services for obtaining the required context information. For this purpose a context service may interface with various kinds of sensors. To represent the context information, a context service may utilize different kinds of context models [Henricksen and Indulska 2004]. Such models need to represent the dynamic context conditions required within various context-aware applications. Specifically, a context model needs to represent various entities in the active-space, their attributes, and the relationships between the various entities. Context conditions are characterized in terms of the entity attributes and their relationships. From an application’s perspective, context conditions can be categorized as external or internal. Examples of external context conditions include users’ physical and network locations, a person’s proximity to other people and physical objects, number and identities of people present at a particular location, users’ devices, device characteristics, or temporal conditions. An example of an internal context condition is the history of tasks performed by a person within an application. 2.1

Context-based Dynamic Service Discovery and Binding

Context-based service discovery and binding refer to the ability of a context-aware application to dynamically discover and integrate resources and services that are available in an active-space. For example, consider a context-aware patient information system deployed in a hospital. One requirement for this application can be that it dynamically binds a doctor’s handheld computing device to a patient’s records who is currently being visited by that doctor. This binding needs to change as the doctor goes from one patient’s room to another patient’s room. In the design model we need a mechanism for logical representation of the functional view of a service required by a context-aware application. We use the term object for such a logical representation. An object may be dynamically bound to different services under different context conditions. An object acts as a proxy of the service to which it is bound. Such a service can be an application-specific ACM Transactions on Software Engineering and Methodology, Vol. V, No. N, Month 20YY.


·

5

service or a context service. Dynamic binding of an object with a service may involve discovering the appropriate service in the active-space. For this purpose, an object needs to be associated with the description of the service’s functional interfaces and attributes. Context information may need to be used as part of the discovery process. For example, a user’s location may be used to bind an object to an active-space service based on the user’s current location. 2.2

Representation of Users and Tasks

Certain context-aware applications may need to support execution of different tasks by its users. For example, in a patient information system the tasks that may be performed by doctors and nurses include creating, updating, and accessing patient records, requesting laboratory tests, etc. Moreover, some ambient resources and services may need to be accessed by such tasks. In the design model we need to support representation of users and their tasks. We use the abstraction of role for this purpose. A role defines a set of privileges for executing tasks in a context-aware application. The tasks are represented through a set of operations defined for that role. Users admitted to a role can perform the specified tasks by executing the corresponding role operations [Ahmed and Tripathi 2007]. The notion of role has been traditionally used to represent a set of responsibilities and privileges associated with a particular position within an organization [Sandhu et al. 1996]. In CSCW and group-ware applications the notion of a role has been used to provide a natural abstraction for representing users without requiring prior knowledge of their individual identities [Li and Muntz 1998; Corts and Mishra 1996]. The concept of a role as an abstraction for representing an entity’s behavior has been developed by others [Cabri et al. 2004]. There, a role specifies the functional behavior of an agent. Our model utilizes the notion of roles for both access control and functional abstractions. 2.3

Context-based Access Control

Context-aware applications may need to restrict a user’s privileges to execute certain role operations based on context conditions. For example, in a context-aware patient information system there could be a requirement that a nurse is allowed to access a patient’s records only when located in the patient’s room. This is an example of location-based access control. An example of co-location based access control is the requirement where a nurse may be allowed to initiate workflow for accessing doctor reports about a patient only in the presence of a doctor. To handle such requirements the design model needs to support specification of context-based access control requirements over user tasks. In certain cases an active-space service may be managing a set of resources and we may need to restrict a user’s access to a subset of these resources based on the context conditions. For example, in the patient information system the database service may be managing and controlling access to information about patients in different hospital wards. There might be a requirement that a nurse is allowed to access records of only those patients who are admitted to the ward where the nurse is currently located. In the design model, we need a mechanism through which the ACM Transactions on Software Engineering and Methodology, Vol. V, No. N, Month 20YY.

6

·


application can restrict, based on context conditions, a user’s access to a subset of resources that are being managed by a service. 2.4

Context-based Multi-User Coordination

Coordination consists of managing flow of data, sharing of resources, synchronization of resource usage, and other relations among workflow activities, such as decomposition of workflow activities into tasks/subtasks and planning how such tasks would be performed [Malone and Crowston 1994]. An example of coordination requirement in the patient information system is the following: a nurse can create test reports for a patient only after the appropriate tests have been performed and a doctor has given the nurse the permission to create such reports. The nature of coordination in the above example resembles loosely coupled asynchronous interactions, such as those commonly occurring in workflow environments. On the other hand, in real-time synchronous collaborations, users are connected to the system simultaneously and their interactions occur through interactive sharing and manipulation of graphical and multimedia objects. Generally, the interactions tend to be unstructured, often spontaneous, and the coordination management is concerned with concurrency control for access to shared resources. The coordination policies may widely vary from one organization to another, and they may also change with time. The design model needs to provide constructs for expressing both types of coordination requirements. 2.5

Context-triggered Automatic Task Executions

One of the primary motivations for context-aware computing is to enhance user experience by relieving the user from performing routine tasks which can be automatically executed based on the occurrence of certain context conditions. Examples of such tasks include dynamic discovery-based binding of the application to appropriate active-space services, dispatching alerts when some pre-defined context conditions occur, or notification of a message to a person based on the person’s current location. The design model needs to support mechanisms for automatically executing certain tasks when the specified context conditions occur. 3.

A PROGRAMMING MODEL FOR CONTEXT-AWARE APPLICATIONS

Based on the above requirements, we have designed a declarative programming model for context-aware applications. This model needs to support the following abstractions and mechanisms. An abstraction is required to represent the design of a context-aware application as a whole. Such an abstraction provides the logical scope for defining various resources required by the application and the tasks that may be performed within the application. We need an abstraction to represent the functional view of active-space resources and services required by the application. Such an abstraction may bind to different active-space services under different context conditions. An abstraction is needed to represent application users and their tasks. Execution of such tasks may need to be constrained subject to the application’s context-based access control and coordination policies. Lastly, we need a mechanism to represent the tasks that may be automatically executed by the application when certain context conditions become true. ACM Transactions on Software Engineering and Methodology, Vol. V, No. N, Month 20YY.


·

7

The high-level programming model that we have developed contains the following basic elements: activities, roles, objects, and reactions. These elements are discussed below. Activity: A context-aware application is represented and programmed using an abstraction called activity. An activity contains roles, and may contain objects and reactions. An activity provides a namespace for the roles, objects, and reactions. In Figure 2 we present a UML class diagram showing the relationships between the programming model elements. We have developed an XML schema corresponding to this programming model. A context-aware application is specified using an activity template, which is defined in this schema. An activity is instantiated from its template. Any number of activity instances can be created from an activity template.

Activity 0..*

1..*

Role member

1..*

Role

X Y X Composed of 1..*

Y

Event

X Composed of

0..1

Precondition

0..1

Uses

1 or more of Y Y

X Composed of

Generates

0 or 1 of Y X

Y X Generates Y

0..*

Notify Event

Y

X

Reaction

Generates

0 or more of Y

X

Uses Uses

1..* 0..*

Operation

0..*

0..1

0..*

Object

1..*

Legend:

X

0..*

1..*

Action

1..* Uses

0..*

0..*

Invoke Session

Invoke Method

X Uses Y

Access Constraint

Fig. 2.

Activity Class Diagram in UML

Roles: A role defines user privileges for performing application tasks, which are represented by operations defined in the role. An operation name is defined in the namespace of a role. A role operation can contain one or more actions. An action may involve invoking a method on an object, or generating an application-defined event. Associated with each role operation is an optional precondition. Actions are executed only if the operation’s precondition is true. Objects: An object provides a reference within an activity for accessing a service which can be an application-specific service or a context service. It acts like a proxy for the service to which it is currently bound. Such a binding may change with the context conditions. Objects may be defined within an activity, or they may be defined within a role. Objects that are defined within the activity-scope are accessible to all roles, i.e. the operations in any role can invoke methods on such ACM Transactions on Software Engineering and Methodology, Vol. V, No. N, Month 20YY.

8

·


objects. The latter kind of objects are private to a role, i.e. they can be accessed only through that role’s operations. Moreover, a separate instance of such an object is created for each member in that role. For object binding purpose, two mechanisms are defined in the programming model. One mechanism is to explicitly specify a service by providing its network address. The other mechanism is based on discovering the required service in the ambient computing environment, based on the current context conditions. The latter mechanism is useful when the service’s location is not known a priori and may need to be discovered. Object Invocation Models: There are two kinds of models supported for accessing an object. These are shown in Figure 3. (1) In the method invocation model, a user invokes a role operation, which results in the invocation of a method on the service that is bound to the object on which the operation invocation is specified. (2) In the session interaction model, invocation of a role operation by a user results in the initiation of an interactive session between the user and the service. Through such a session, the user may execute an arbitrary sequence of permitted methods on the service. The role operation completes when the session is terminated. Role Operation

User

Operation start

Operation Invocation

Action

Object

Service Service invocation

Method invocation 11 00 00 11 00 11 00 11

Operation finish

Method Invocation Model Operation start

Session Interaction

Action

Session start

00 11 11 00 00 11 00 11 00 11 00 11 00 11 00 11 00 11 00 11 00 11 00 11 00 11 00 11 00 11 00 11 00 11 00 11 00 11 00 11 00 11 00 11 Session finish 00 11 00 11

Session 00 11 11 00 00 11 00 11

00 11 11 00 00 11 00 11

Operation finish

Session Invocation Model Legend:

00 11 11 00 00User 11 00 11 00 11

session interaction

Action specifying single method invocation Action specifying session invocation

Operation 11 00 00 11 00 11 00 11

Fig. 3.

Method invocation on a service through Interface components

Interaction models

Reactions: A reaction is used to program event-triggered actions for supporting automated task executions. A reaction follows the Event-Condition-Action (ECA) [Ceri and Widom 1990] model of evaluation and is executed by the runtime system. A reaction is triggered by one or more context events. The actions specified ACM Transactions on Software Engineering and Methodology, Vol. V, No. N, Month 20YY.


·

9

in a reaction are executed only if the reaction’s precondition is true. In case the precondition is not true, the event is discarded. Reactions can be defined at the activity-level and also within an object. Activitylevel reactions are used for two purposes. One is to program activity-level tasks that need to be automatically executed when certain context conditions occur. The second purpose is to program activity-level configuration actions which may involve establishing communication relationships between two or more activity-level objects. Reactions defined within an object are used to specify its binding policies. The actions that such reactions can execute are restricted to object binding and event notifications. Nested Activities: Within a context-aware application, occasionally we may need to instantiate sub-activities. For example, in the patient information system a doctor may need to create a patient treatment activity for a patient. In the programming model we support nested activities for this purpose. An activity template may define nested templates, whose instantiation result in the creation of child activities. Each child activity defines its own namespace. The nesting of activities results in creation of a hierarchically structured namespace. In a nested activity, the visibility of objects, roles, and event names is restricted to the name-scope of that activity. A nested activity may need to have access to the objects in the scope of its parent activity. For this, objects in the parent activity’s namespace can be passed as reference parameters to a child activity. 3.1

Case Study Example

To illustrate this declarative programming model, we use a context-aware patient information application as an example. We have implemented a prototype of this application in our testbed environment. It supports a number of requirements as follows [Evered and B¨ ogeholz 2004]. P1. The application maintains various kinds of records and reports for the patients admitted to different wards in the hospital. The application permits doctors to create different kinds of reports about patients. P2. The hospital staff is able to access utility services, such as a printer service, based on their proximity to a particular service. P3. For a nurse, access to doctor reports is allowed only if some doctor is present in the ward where the nurse is located, and also if a doctor has given prior approval for such an access. P4. A nurse is allowed to access records of only those patients who are admitted to the ward where the nurse is currently present. We model the above requirements using the PatientInformation activity template, whose schematic is presented in Figure 4. The partial specification of this activity is presented in Figure 5. Corresponding to different departments in a hospital, separate PatientInformation activity instances can be created from this template. For presenting the activity template specification we use a pseudo notation. In this notation, the terms in boldface represent the XML tags in our schema. In the activity’s object-space we define two objects PatientDB and LocationService. The PatientDB object refers to the database service that holds the patient ACM Transactions on Software Engineering and Methodology, Vol. V, No. N, Month 20YY.

10

·

Devdatta Kulkarni et al. ActivityTemplate PatientInformation Role Doctor

ActivityTemplate PatientCare

CreatePatientReports

Role Nurse

CreatePatientCareActivity

AccessDoctorReports ApprovePatientDataAccess

AccessWardPatientInfo Print Current Ward

My Printer

Ward2 Info Service

Printer1 Service

Patient DB

Location Service

Database Service

Location Service

Active−space Ward1 Info Service

Legend:

Fig. 4.

Printer2 Service

Activity

Role

Service

Binding

Display Service

Object

Schematic of Patient Information Activity Template

ActivityTemplate PatientInformation { Object PatientDB { /* See Figure 8 */} Object LocationService { ... } Role Nurse { Object CurrentWard { /* See Figure 6 */ } Object MyPrinter { ... } Operation AccessDoctorReports { /* See Figure 9 */ } Operation AccessWardPatientInfo { /* See Figure 10 */ } Operation Print { Action MyPrinter InvokeSession print } } Role Doctor { Operation CreatePatientReports { Action PatientDB InvokeSession createReports } Operation CreatePatientCareActivity { Action PatientCare New Activity (PatientCare) } Operation ApprovePatientDataAccess { /* See Figure 9 */ } } ActivityTemplate PatientCare { ... } }

Fig. 5.

Patient Information Activity: Specification

records and doctor reports. The LocationService object refers to the service providing location information for nurses and doctors. ACM Transactions on Software Engineering and Methodology, Vol. V, No. N, Month 20YY.


·

11

Role Nurse { ..... Object CurrentWard RDD (//WardRDD.xml) { Reaction BindCurrentWard { When Event UserArrivalEvent Bind Discover (LOCATION= LocationService.getLocation(UserArrivalEvent.getUserName())) } } } Fig. 6.

Example of Discovery based binding primitive

In the activity we define two roles, Nurse and Doctor. In the Nurse role we define two private objects, CurrentWard and MyPrinter. A separate instance of these objects is created for each member of the nurse role. The CurrentWard object for a Nurse role member refers to the context service of the ward where that nurse is currently present, and the MyPrinter object refers to the printer in that ward. We define the following operations in the nurse role. The AccessDoctorReports operation allows a nurse to access doctors’ reports. The AccessWardPatientInfo operation allows a nurse to access the records of those patients who are admitted to the ward where the nurse is present. The Print operation enables printing to the printer in the ward where the nurse is present. In the Doctor role we define the following operations. The CreatePatientReports operation allows a doctor to create various reports about patients. Through the CreatePatientCareActivity operation a doctor can create the nested PatientCare activity for a specific patient. The ApprovePatientDataAccess operation allows a doctor to give approval for accessing doctor’s reports to a specific nurse. 3.2

Objects and Dynamic Binding

For supporting discovery-based dynamic binding to services by an application, the middleware system provides a resource discovery service for dynamic registration and discovery of available services in an active-space environment. Service discovery is performed by matching an object’s description with the descriptions of various services that are registered with the discovery service. For describing functions and attributes of objects and services, we have developed a schema called RDD (Resource Description Definition). An RDD is expressed in XML and contains specification of the service’s attributes, its interfaces, and events to be imported from the service. RDDs are used for two functions. One is to specify the description of a service for registration with the discovery service. The other function is for querying the discovery service to find a service that matches the given description in an RDD. For discovery, certain attributes in an object’s RDD may be specified at runtime based on the context information. The discovery procedure attempts to find a service whose description matches to the RDD given in the query. Below we present two examples from the PatientInformation activity that illustrate the various binding mechanisms. Example 1 (Discovery-based binding): The CurrentWard object defined in the Nurse role refers to the context service corresponding to the ward in which a nurse ACM Transactions on Software Engineering and Methodology, Vol. V, No. N, Month 20YY.

12

·


Fig. 7.

Example of parameterized RDD: Active-space service for a Ward

is present. We use discovery-based binding for this object, because it needs to refer to context services of different wards as a nurse moves from one ward to another ward. The binding specification for this object is shown in Figure 6. The binding is triggered by the UserArrivalEvent that is generated whenever a particular Nurse role member enters a ward. The WardRDD, shown in Figure 7, is used for the discovery purpose. This RDD defines the interfaces that need to be supported by the context service to which the CurrentWard object would be bound. It also specifies the context events (in this case RoomStatusChangeEvent) that would be imported by the activity from the service after binding the object to it. The LOCATION attribute in this RDD is a parameterized attribute. The value $PARAM of this attribute is specified at runtime using the location information of the Nurse role member corresponding to whom the UserArrivalEvent is generated. A similar binding directive is specified for binding the MyPrinter object, thus satisfying requirement P2 given in Section 3.1. Example 2 (Direct Binding): The PatientDB object is directly bound to the database service that provides access to patient records. The corresponding specification is shown in Figure 8. The URL of this service is explicitly specified here. The reaction is triggered by the ActivityCreationEvent, which is generated by the middleware when the activity is instantiated. The binding of the LocationService object is similar to that of the PatientDB object. After binding, the activity imports UserArrivalEvent from this service. Object PatientDB { Reaction { When Event ActivityCreationEvent Action Bind Direct (//PatientDBServiceURL) } } Fig. 8.

Example of Direct binding primitive

ACM Transactions on Software Engineering and Methodology, Vol. V, No. N, Month 20YY.


3.3

·

13

Constraint Specification for Access Control and Coordination

Context-based access control and coordination policies are specified using constraints. These constraints are specified through the precondition mechanism associated with a role operation. The precondition for an operation needs to hold before the operation’s actions can be executed. For our goal of supporting collaborative applications, we focus only on access control and coordination policies. There could be other kinds of policies also, for example, privacy policies and active-space administrative policies such as, whether an activity is allowed to use resources and services in an active-space. However, we do not support these in our programming model. A constraint is a boolean expression which may involve predicates based on event counts, role membership information, and context information. An event-based predicate is expressed using logical expressions involving event counts and event attributes. The programming model supports three kinds of events. The first kind of events are system-defined start and finish events which are related to operation executions. These events are implicitly generated by the runtime system. When an operation is invoked and if the operation’s precondition is satisfied, the operation’s start event is generated and the execution of the operation’s actions begins. An operation’s finish event is generated when the operation’s actions complete. The second kind of events are application-defined events. These are explicitly generated by an action in a role operation or reaction. The third kind of events are the context events, such as UserArrivalEvent, which are generated by context services. Multiple occurrences of an event type are viewed to form an event-list. The count operator # applied to an event identifier, e.g. #EventName, returns the number of occurrences of that event type. A subsequence of an event-list can be derived by filtering it based on some predicate on the event’s attributes. For operation start and finish events, there are two predefined attributes: invoker and time. The expression roleId.opId.start(invoker=thisUser) defines a filter based on the operation invoker’s identity. The variable thisUser in an expression represents the identity of the user for whom the constraint is being evaluated. Using the count operator, the expression #(roleId.opId.start(invoker=thisUser)) counts the number of times the user for whom the constraint is being evaluated has invoked the role operation opId. It is also possible to define and set custom attributes within an event. Role membership information can be used in constraint specification. The function member(thisUser, RoleName) checks at runtime if the invoking user is a member in the role RoleName. Other functions are provided for querying the list of current members of a role. Similarly, context information provided by ambient context services can also be used in constraint specification. For this purpose, such context services would typically provide some query functions. For example, a context service that monitors the status of a ward may support a method such as isPresent(userId) to detect if the specified user is present in that ward. Example 3: In Figure 9 we present how the requirement P3 given in Section 3.1 is programmed using this model. The AccessDoctorReports operation of the Nurse role allows a member of this role to access the doctor reports available through ACM Transactions on Software Engineering and Methodology, Vol. V, No. N, Month 20YY.

14

·


Role Nurse { .... Operation AccessDoctorReports { Precondition CurrentWard.isPresent(thisUser) ∧ CurrentWard.isPresent(members(Doctor)) ∧ #Doctor.AccessApprovalEvent(nurseID=thisUser) > 0 Action PatientDB InvokeMethod accessDoctorReport } } Role Doctor { .... Operation ApprovePatientDataAccess { Action NotifyEvent AccessApprovalEvent( Attribute nurseID Value (Action Nurse InvokeSession selectMember)) } } Fig. 9.

Example of context-based access control and coordination policy specification

the PatientDB object. Both context-based access control and coordination constraints are required to satisfy the requirement P3. We use operation precondition mechanism for this purpose. In the Doctor role we define the ApprovePatientDataAccess operation through which a doctor may give approval to a specific nurse for accessing patient records. An AccessApprovalEvent is generated when a doctor executes this operation. The attribute nurseID within this event can be set by selecting a specific member of the Nurse role. For this, the session invocation model, specified through the InvokeSession primitive, is used. The precondition for the AccessDoctorReports operation in the Nurse role checks the following: whether some member of the Doctor role is present in the ward where the nurse who is invoking this operation is present, and if the count of AccessApprovalEvent for this Nurse role member is greater than zero. The InvokeMethod primitive indicates that this operation follows the method invocation model, whereby the accessDoctorReport method is invoked on the PatientDB object and the results are returned to the nurse. 3.4

Resource Access Constraints in Service Invocations

When a role operation accesses an object that is bound to a service managing a collection of resources, in many applications a need arises to constrain the role operation’s access to only a subset of these resources, based on the current context conditions. For example, a user’s access to a database service needs to be restricted to only those records that satisfy certain context-based predicates. The programming model provides the resource access constraint mechanism for this purpose [Kulkarni and Tripathi 2008b]. One can associate such a constraint with the method invocation defined on an object in an action of a role operation. Such a constraint specifies a relation between resource attributes and certain context variables. Only those resources that satisfy this predicate are allowed to be accessed through the role operation. ACM Transactions on Software Engineering and Methodology, Vol. V, No. N, Month 20YY.


·

15

Example 4: Consider the AccessWardPatientInfo operation of the Nurse role which allows a nurse to access the records of only those patients who are admitted to the ward where that nurse is currently present. To program this requirement, we use the resource access constraint mechanism as shown in Figure 10. As part of the constraint specification, we require that access should be granted to the nurse for only those patient records for which the value of the WardID field in the patient’s record matches the nurse’s current ward location. In this way the requirement P4 given in Section 3.1 is satisfied. Operation AccessWardPatientInfo { Precondition TRUE Action PatientDB InvokeSession accessPatientInformation AccessConstraint (WardID = CurrentWard.getWardID()) } Fig. 10.

4.

Example of resource access constraint primitive

GENERATIVE MIDDLEWARE

We have taken a generative approach for creating the execution environments of context-aware applications from their high-level design specifications [Kulkarni and Tripathi 2007]. The central element of this approach is creation of applicationspecific components from the generic middleware components by specializing the middleware components with application specific policies. The generic components encapsulate protocols for context-based service discovery and binding, and enforcement of context-based access control and multi-user coordination constraints. The generic components provided in the middleware include the following managers. Activity Template Manager: This manager maintains the activity template and enforces the security policies, which identify the roles and their operations that are allowed to instantiate that template. Activity Manager: The primary function of an activity manager is to manage a specific instance of an activity template. An activity manager creates the activity’s namespace, the role managers corresponding to the roles defined in the activity, the object managers corresponding to the objects defined in the activity’s object-space, and the template managers for any nested sub-activities. Role Manager: A role manger provides functionalities and protocols for supporting the user interaction models for accessing various resources and services through role operations. The role manager performs the functions of constraining users’ admission to the role, evaluation of operation preconditions, and performing role membership authentication on operation invocations. Object Manager: An object manager supports the user-interaction models by performing the requested method invocations by role operations. It acts as a proxy for forwarding these invocations to the currently bound service. An object manager performs event-triggered dynamic binding actions and also enforces object-level access control policies. ACM Transactions on Software Engineering and Methodology, Vol. V, No. N, Month 20YY.

16

·


The following kinds of requirements were addressed in developing the architecture of this middleware. Generative Process Requirements: These requirements are related to the design of the managers, and generation of an application’s execution environment. —A system architecture needs to be developed that enables composing of various managers and their interaction protocols for creating and managing the execution environment of a context-aware application. —Appropriate architectures need to be designed for the various generic managers to enable their specialization based on an activity’s specification. —Mechanisms need to be developed for deriving application-specific policies from an application’s specification for creating its execution environment. Decentralized Management Requirements: These requirements are related to the management aspects of an activity. Specifically, the middleware needs to address the following: —Operation invocations by various users need to be authenticated. —The middleware needs to support distributed execution and management of policy enforcement functions. This is important because different people or organizations may be trusted to manage different roles and objects of an activity. —Because coordination and access control constraints are based on events, the system needs to ensure the authenticity of event sources, inferred from the design specification. 4.1

Approach Overview

The process of generating a context-aware application’s execution environment is partitioned into three phases as shown in Figure 11. The first phase is the design phase. The designer has to develop the activity specification corresponding to the application requirements. The designer has to also develop the required application components, active-space services, and if necessary, application-specific context models and context services utilizing the context services available in the active-space. Design Phase − Create Activity Specification − Design Context Models

Fig. 11.

Compilation Phase − Create Template DOM tree − Derive Policy Templates − Create Activity Template Manager

Instantiation Phase − Create Instance DOM tree − Derive Policy Instances − Create Instance Managers

Three phases in context-aware application generation

The second phase is the compilation phase, which is executed by the middleware for a given activity template. The primary function of the compilation phase is to create the data structures and the policy objects required for generating the execution environment for an activity instance from the template. This is done just once for an activity template, thus reducing the time required in its ACM Transactions on Software Engineering and Methodology, Vol. V, No. N, Month 20YY.


·

17

instantiation. The two basic entities created in this phase are the activity’s template manager, and the template policies. The activity template manager maintains a representation of the activity template in the form of its XML Document Object Model (DOM) tree. The template policy objects are maintained with the activity template manager. These template policy objects are parameterized. This means that the instance specific information such as the names of the various roles and objects are maintained as parameters within these template policy objects. The specific values for these parameters are specified only during the third phase, which is the instantiation phase. In the instantiation phase the following steps are executed. The activity template manager clones the template DOM tree to create the instance tree for that activity. It then creates an activity manager for managing the instance of the particular template that is being instantiated. The activity manager refines the template policies with the instance specific information, such as the names for the various entities defined in that activity instance. The activity manager then creates the role managers, the object managers, and starts the reaction threads for the activity-level reactions. The role managers create object managers corresponding to the objects that are defined in the role’s namespace. Lastly, the activity manager creates the activity template managers for any nested activity templates.

UCI

UCI

Application−specific Activity Manager

UCI

Application−specific Role Manager

Application−specific Object Manager

Trusted Server

Application Execution Environment

Discovery Service

Context Services

Infrastructure Services

Application Components

Active space Environment Legend:

Fig. 12.

User Interaction

Discovery

Binding

Architectural overview of a context-aware application

In Figure 12 we present an overview of the execution environment and components of a context-aware application. The application execution environment consists of managers specialized according to the activity’s specification. These managers are active objects that support remote interfaces through Java RMI and are run on the trusted servers. These servers provide a trusted environment for hosting and running the various managers that are instantiated as part of an application’s execution environment. For a single user application such servers may ACM Transactions on Software Engineering and Methodology, Vol. V, No. N, Month 20YY.

18

·


be run on the user’s device. For a multi-user application, such servers may be run in the active-space by the administrator. For user interactions, a GUI component called User Coordination Interface (UCI) is executed on each user’s device. Through this, a user can perform application tasks by executing role operations corresponding to roles in which he/she is admitted. 4.2

Data Structure for Runtime Management of Activities

At the heart of the runtime management of an activity lies the activity’s XML DOM tree representation. In Figure 13 we present how a template tree for an activity evolves when different instances of that activity are created. In this figure we only show nodes for activities, roles, and objects. Each of these nodes is a root of a subtree. For example, a role node is the root of the subtree containing one or more operations, an object node is the root of the subtree containing one or more binding reactions, etc. In case of an activity template node, all of its sub-nodes are template-based. A top-level System activity is defined for providing the namespace for all activity templates created in the system. A system-defined role, called Convener, is responsible for instantiating the activity templates corresponding to the toplevel activities. In part (a) of Figure 13 we show the template for the patient information activity. When an activity’s template is created, it is appended as a child of the System activity. The instance tree of an activity is appended as a child of that activity’s template root node. The instance tree represents the runtime data-structure that maintains the execution state of an activity. The instance tree corresponding to the activity instance named Opthalmology is shown in part (b) of Figure 13. This activity defines a new namespace containing nurse and doctor roles that are independent of other activity instances. The names of various nodes in the instance tree are part of the namespace of the activity template which is being instantiated. For example, when the activity instance Opthalmology is created, the name of this instance is System.PatientInformation.Opthalmology. Because the activity instance names are strongly tied with the scope of the activity template for which the current activity instance is created, the activity instance is appended as a child of the template node. A nested activity template PatientCare is specified for the PatientInformation activity. However, it is not instantiated yet. Therefore, it is attached as a template tree to the Opthalmology node. In part (c) we show two instances of the PatientCare activity one with name Patient1, and the other with name Patient2, instantiated based on the PatientCare activity template. 4.3

Distributed Management of Activities

The instantiated managers for activities, roles, and objects are given references to the nodes for the corresponding activity, role, and object in the instance DOM tree. This is done so that the managers can execute the entity-specific functions in the execution environment of an application. For the activity manager such functions include creating managers for roles and objects defined in that activity. For the role managers, the functions are enforcing context-based access control and coordination policies, and executing the role operations. In case of object managers, the functions performed are context-based service discovery and binding, and enforcing objectlevel access control policies. In Section 4.5 and 4.6 we present the architecture of ACM Transactions on Software Engineering and Methodology, Vol. V, No. N, Month 20YY.


19

·

System Convener

PatientCare

Legend:

PatientInformation

1111 0000 0000 1111 0000 1111

Activity Template

1111 0000 0000 1111 0000 1111

11111 00000 00000 11111

11111 00000 00000 11111

1111 0000 0000 1111 0000 Object Template 1111 Object Instance

Activity Instance

00000 00000 Patient Location 11111 Nurse Doctor 11111 DB Service

11111 00000 Role Template 00000 11111 00000 11111 Role Instance

Nested Template

(a) Creation of PatientInformation activity template System PatientInformation

Convener

PatientCare

1111 0000 0000 1111 0000 1111

PatientDB

1111 0000 0000 1111 0000 1111

11111 00000 00000 11111 00000 11111 00000 11111 00000 11111 00000 Doctor 11111 Nurse

Location Service

Opthalmology Owner=Convener

PatientCare

Laboratory Tests

1111 0000 0000 1111 0000 1111

Patient Location Doctor Nurse Service DB

11111 00000 00000 11111 11111 00000 00000 11111 11111 00000 00000 11111 00000 11111 00000 Specialist 00000 00000 11111 11111 Doctor Nurse 11111

(b) Creation of Opthalmology activity instance PatientCare

Laboratory Tests

1111 0000 0000 1111 0000 1111

00000 11111 00000 11111 11111 00000 11111 00000 11111 00000 00000 11111 00000 11111 00000 11111 00000 11111 00000 11111 Doctor Nurse Specialist

Laboratory Tests

Patient1 Owner=Doctor

Doctor

Nurse

Specialist

Patient2 Owner=Doctor

Laboratory Tests

Doctor

Nurse

Specialist

(c) Creation of instances for nested activity PatientCare Fig. 13. Runtime data structure representing execution state of an activity template and its nested activities

the role manager and the object manager respectively. The task of executing the managers for the various roles, objects, and nested activities could be entrusted to different organizations or individuals. The programming model supports the notion of an owner of an activity, who is responsible for managing that activity. As a default rule, the role that instantiates an activity is designated as its owner. Otherwise, it is possible to specify a different role as the owner of an activity. In Figure 13, the Convener role is the owner of the activity instance for the Opthalmology activity instance. In Figure 13(c), all PatientCare ACM Transactions on Software Engineering and Methodology, Vol. V, No. N, Month 20YY.

20


·

activity instances are under the ownership of the Doctor role in that department. To perform the runtime management functions of an activity, its owner has to run trusted servers on one or more hosts for executing the managers for roles, objects, and nested activity templates in that activity. The managers can be placed on different trusted servers belonging to the owners. Each manager object is given the appropriate subtree of the activity’s DOM tree representation. For example, the managers for the Nurse and the Doctor roles in Figure 14 can be placed and executed on different servers belonging to the Convener role, who is the owner of the Opthalmology activity. The corresponding DOM subtrees for these roles are placed at those servers. Similarly, the managers for the objects in an activity are created on the owner’s trusted servers. When a person in the Doctor role creates an instance of the PatientCare activity, its managers are created and executed on the trusted server under the control of the Doctor role. Activity Manager: Opthalmology Opthalmology

Opthalmology

1111 0000 0000 1111 0000 1111 0000 1111

Role Manager: Nurse Role

Role Manager: Doctor Role

11111 00000 00000 11111 00000 11111 00000 11111 00000 11111

Nurse

Notification Policies Notifier Doctor

Event Access Approval Event

Event Handler

Admission constraint

Operation: Access Doctor Reports

Precondition Action

^ #

11111 00000 00000 11111 00000 11111 00000 11111 00000 11111

Doctor

Operation: Approve Patient DataAccess

Subscription Policies Subscriber Nurse

Action

Event Handler

^ CurrentWard. isPresent(members(Doctor))

AccessApproval Event (nurseID=thisUser)

Fig. 14.

4.4

Event Access Approval Event

CurrentWard. isPresent(thisUser)

DOM Tree reference Event processing

Example of event subscription and notification policies

Policy Derivation for Runtime Management

The core of the compilation phase is the policy derivation procedure. The goal of this procedure is to derive the policies required for the runtime management of an activity. The following types of policies are used in our middleware: (a) role admission policies, (b) coordination and access control policies, (c) contextbased object binding policies, (d) object-level access control policies, (e) resource access constraints, and (f) event subscription and notification policies. The first two kinds of policies are maintained with role managers, the next three kinds of policies are maintained with object managers, and the event subscription and notification policies are maintained by both. Policies are represented in two basic forms: as Java objects, or as references to the nodes of the activity’s DOM tree. The policies that need to be derived by analyzing the entire activity specification are maintained as Java objects. The event ACM Transactions on Software Engineering and Methodology, Vol. V, No. N, Month 20YY.


·

21

subscription and notification policies, and the object-level access control policies for an object manager are maintained in this form. Policies that are specific to only a single entity are represented as pointers to the appropriate constraint specification nodes in the activity’s instance tree representation. The policies that are maintained in this form include role admission policies, access control policies that involve queries to context services, context-based object binding policies, and resource access constraints. Event subscription/notification policies: The purpose of these policies is to ensure secure event communication among various role managers, object managers, and the activity manager of an instantiated activity. The event subscription policies for a manager specify the other managers that are allowed to subscribe to a given type of event generated by this manager. The event notification policies for a manager specify the set of other mangers that are the valid sources for a given event type. Effectively, the notification policies are used to authenticate the generators of the events. Both these policies are determined by analyzing the activity specification during the compilation phase. The basic rule in policy derivation is to determine for each role, object, and activity the various kinds of events that are used in the constraint specification, and derive event subscription and notification policies for those events. The subscription and notification policies are derived in the template form from the activity template during the compilation phase. Then, as part of instantiating an activity instance from that template, these template policy objects are specialized with the names of the specific role managers and object managers corresponding to the activity instance that is being instantiated. This two-step process helps in avoiding the expensive computation step of analyzing the activity instance tree for deriving instance policies. Figure 14 shows the event subscription and notification policies for the Nurse and the Doctor roles in the Opthalmology activity. The subscription policy for the Doctor role indicates that the Nurse role manager is allowed to subscribe to the AccessApprovalEvent from the Doctor role manager. The notification policy for the Nurse role indicates that the Doctor role manager is a valid notifier of the AccessApprovalEvent. Whenever any Doctor role member invokes the ApprovePatientDataAccess operation, the AccessApprovalEvent is generated and notified to the Nurse role manager. The event handler in the Nurse role manager updates this event’s count in the precondition tree specified for the AccessDoctorReports role operation. Object-level access control policies: An object’s access control policies determine which roles and their operations are permitted to invoke a given method of the object. These policies are maintained in the form of an access control list (ACL) for the object. In our model, method invocations on an object may be specified at two places: as part of a role operation action, or as part of a role operation precondition. An ACL for an object contains for each method a list of pairs, indicating a role and its operation through which that method can be invoked. For the activity-scope objects, such an ACL may refer to any role defined in the activity. On the other hand, for a role’s private objects, such an ACL can refer to that role’s operations only. Similar to the subscription and notification policies, ACM Transactions on Software Engineering and Methodology, Vol. V, No. N, Month 20YY.

22

·


the ACLs for an object are derived and maintained in the template form during the compilation phase, and specialized with activity-specific information during the instantiation phase. In Figure 15 we present the ACL entries for the PatientDB object defined in the PatientInformation activity specification. The Doctor in the PatientInformation activity $X can invoke the createReports method on it, and the Nurse can invoke the accessDoctorReports method on it. OBJECT=System.PatientInformation.$X.PatientDB ENTRY{ SUBJECT=System.PatientInformation.$X.Doctor OPERATION=CreatePatientReports PERMISSION=createReports } ENTRY{ SUBJECT=System.PatientInformation.$X.Nurse OPERATION=AccessDoctorReports PERMISSION=accessDoctorReports }

Fig. 15.

Example of template Access Control List (ACL)

As an activity is instantiated, the above template becomes more specific by incorporating the information about the instantiated activity. For example, for the Opthalmology activity, the instantiated access control policy looks as shown in Figure 16. OBJECT=System.PatientInformation.Opthalmology.PatientDB ENTRY{ SUBJECT=System.PatientInformation.Opthalmology.Doctor OPERATION=CreatePatientReports PERMISSION=createReports } ENTRY{ SUBJECT=System.PatientInformation.Opthalmology.Nurse OPERATION=AccessDoctorReports PERMISSION=accessDoctorReports }

Fig. 16.

4.5

Example of instantiated Access Control List (ACL)

Role Manager Architecture

A role manager performs two functions within the constructed execution environment of a context-aware application. First, a role manager provides mechanisms that enable users to perform application-specific tasks. Second, a role manager provides trusted environment for enforcing task-specific context-based access control and coordination policies. In Figure 17 we present the components of a role manager and interactions among them. The shaded elements are constructed for each role manager based on the ACM Transactions on Software Engineering and Methodology, Vol. V, No. N, Month 20YY.

A Generative Programming Framework for Context-Aware CSCW Applications Events

Invocation Interface

Notifier Interface

Subscription Policies

Event Notification Policies

Operation start/finish

Event Handling Policies

events,

Authentication Protocols

2

23

Events

Subscriber Interface

1

·

Operation Dispatch Table (3)

Application−specific Precondition Notification events Node Update Precondition Action Nodes Check 111 000 000 111 000 111 000 111 000 111 000 111 000 111 000 111

(4)

5

To Object Manager Action Node Reference

Action Dispatch Table Role Membership Database

Admission Policies

Role Admission Functions

0000 1111 1111 0000 0000 1111 0000 1111 0000 1111

Role Member Private Object Space

Legend:

Control−flow 0000 1111 1111 0000 0000 1111 0000Policies 1111

Event−flow 0000 1111 1111 0000 0000 1111 0000 1111 0000 1111

Role Node Reference

Component reference

DOM Tree node reference

Non−shaded elements: Generic Role Manager

Fig. 17.

Architecture of a Role Manager

activity specification, whereas the non-shaded elements are available as part of the generic role manager architecture. The role manager contains an Operation Dispatch Table, which maintains references to the operation nodes in the activity’s instance DOM tree. The role manager also maintains a list of the users who are currently admitted to that role. For every such user, an object manager is created corresponding to each object that is defined in the role’s private object space. The role manager implements three interfaces: an invocation interface, a subscriber interface, and a notifier interface. The invocation interface supports operation invocations by the role members through their UCIs. The subscriber interface is used by the other managers to subscribe to the events that are generated by this role manager. The notifier interface is used for notifying remote events to this manager. Invocation of a role operation involving object method execution leads to accessing of the service to which that object is currently bound. The steps taken by the role manager to achieve this are marked as steps 1 to 5 in Figure 17. The role manager first authenticates the role member who is requesting method invocation (step 1). Authorization tickets are used to ensure that role operation invocations are being performed by valid role members. Such a ticket contains an operation’s name, and its parameters. The role manager verifies the ticket, extracts the operation’s name from it, and then dispatches the operation execution by consulting the operation dispatch table (steps 2 and 3). The role manager evaluates the precondition associated with the invoked operation using the operation’s DOM tree representation (step 4). If the precondition is true, the role manager passes the method name and the method parameters to the object manager that is specified as ACM Transactions on Software Engineering and Methodology, Vol. V, No. N, Month 20YY.

24

·

Devdatta Kulkarni et al. Binding/Rebinding Events

Invocation Interface

Context Events

Subscriber Interface

Notifier Interface

1

Binding Policies

Event Handler Method List

3 : : : : Object−level Access control policies

Legend:

Operation Dispatch

4

:

Reaction Node Reference

Binding Reaction Table 0000 1111

Resource access constraint filter 11111111 00000000 00000000 11111111 00000000 11111111 00000000 11111111 00000000 11111111 00000000 11111111

Control−flow Event−flow Non−shaded elements: Generic Object Manager

Fig. 18.

Reaction Node

:

2 Operation Name

Event Name

Subscription Policies

Authentication Protocols

5

1111 0000 0000 1111 0000 1111 0000 1111 0000 1111 0000 1111 0000 1111 Service

Reference

6

To Service (Using Reflection) Object Node Reference

Component reference

Architecture of an Object Manager

part of the operation’s action (step 5). For this, the role manager uses a standard interface implemented by the object manager. The object manager in turn invokes the method on the currently bound service using reflection. A role operation may contain more than one action with object method execution specified as part of it. In such a case, the role manager repeats step 5 for each such action. 4.6

Object Manager Architecture

An object manager performs two functions within an activity. First, it performs context-based binding actions, thereby maintaining a reference to the appropriate service of a given type under the current context conditions. Second, it enforces method-level access control policies. This involves authenticating the role manager whose member requested the method invocation, verifying that the invoked method is permitted by the object ACL, and enforcing the resource access constraints. In Figure 18 we present the architecture of an object manager derived from the corresponding generic manager. The shaded elements are constructed for each object manager based on the activity specification, whereas the non-shaded elements are available in the generic object manager architecture. An object manager implements an invocation interface, a subscriber interface, and a notifier interface. The invocation interface is used by role managers and UCI to request method invocations. The subscriber interface is used by other managers to subscribe to the events that are generated by the object manager. Each object manager generates object binding and rebinding events whenever the object’s binding changes [Kulkarni and Tripathi 2008a]. The notifier interface is used for receiving such events from other object managers and context events from context services. A request for method invocation may arrive from a role manager or a UCI. The object manager handles such requests as follows (steps 1 to 6). The object manager first authenticates the role manager or the UCI that is requesting method invocation (step 1). It then checks whether the method being invoked satisfies the object’s ACLs (step 2). The object manager then constructs the method parameters by applying the specified resource access constraint filter on these parameters (steps 3 and 4). We describe resource access constraints in Section 4.6.2. Finally, using ACM Transactions on Software Engineering and Methodology, Vol. V, No. N, Month 20YY.


·

25

Java’s reflection API the object manager invokes the specified method on the currently bound service (steps 5 and 6). If the method invocation is specified using the session invocation primitive (InvokeSession), the object manager creates a session with the service. Corresponding to such a session the object manager maintains information such as the identity of the role member initiating the session, and session-level authentication tickets. It also creates any session-specific user interface components, if such components are provided for that session. The object manager terminates the session when the user who initiated the session explicitly terminates it. An object manager maintains two kinds of policies, the binding policies, and resource access constraints. 4.6.1 Object Binding Policies. These policies specify the following: when to perform the binding actions, how to identify the service to which the object should be bound, and what context information, if any, should be used in the discovery process. These policies are derived from the activity specification and maintained in the binding reaction table in the following form: . Each object manager subscribes to all the context events that are required as part of its binding reactions. These reactions get triggered when a context event is delivered to the object manager. 4.6.2 Resource Access Constraints. A resource access constraint is a mechanism that is used by the object manager to enforce context-based access control on resources that are managed by a service. There are two approaches for enforcing such constraints. In one approach, the object manager constructs a filter based on the specified resource access constraints and passes this filter to the service as part of the method invocation. The service applies this filter and grants access to only those resources that satisfy the filter condition. The services need to be designed to support appropriate interfaces that can accept the access constraint filter as a parameter. In case a service does not provide such an interface, the filtering can be done by the object manager itself. This corresponds to the second approach. In this approach, the object manager is able to access all the resources managed by the service. To the role member, however, it grants access to only those resources which satisfy the access constraint. In Figure 19 we present the runtime evaluation of the access constraint example which was earlier presented in Section 3.4. The PatientDB object manager grants access to only those database records for which the WardID field in the patient records has the value equal to the location of the Nurse role member who is invoking the operation. 4.7

Tool Support

Designing a context-aware application using our framework involves a number of steps. One has to design the required active-space services, the context services, and develop the activity specification. The active-space services and the context services can be designed using standard programming languages and design methodologies. The cost of developing the context services can be amortized across various applications. For instance, several of our applications used the location service, which was developed once. We used an agent-based event aggregation system [Tripathi ACM Transactions on Software Engineering and Methodology, Vol. V, No. N, Month 20YY.

26

·

Devdatta Kulkarni et al. Components of Application Runtime Environment AccessWard PatientInfo

AccessWard PatientInfo

Event Handler

Precondition

Service Reference

Action

GUI

response

response

User Cooridnation Interface (UCI)

method

PatientDB Object Manager

Nurse Role Manager

Service

Role: Nurse

Operation: AccessWardPatientInfo Action Precondition AccessConstraint InvokeSession

=

CurrentWard. getWardID()

WardID

Fig. 19.

Resource access constraint example: PatientDB object manager

et al. 2007] for collecting context data. These agents utilized sensors for Bluetooth, RFID, and GPS for collecting different kinds of context information, such as user locations, number and identities of people present in a room, proximity of a user to a physical entity, and so on. For assisting the designer in creating activity specifications, we provide a syntax-driven Activity Template Editor for creating the XML specifications. 5.

EVALUATION

In this section we present the evaluation of the programming model and the generative middleware. The programming model is evaluated for its support of designing different kinds of context-aware applications. In Section 5.1 we briefly discuss some of the context-aware applications that we developed using this framework. In Section 5.2 we discuss the lessons that we learned through this development effort. We comment on the extensibility of the design model in Section 5.3. The generative middleware is evaluated in Section 5.4 for its support towards automating the task of generating the execution environment of a context-aware application. In Section 5.5 we consider the time taken to realize an application’s execution environment. In evaluating our framework we have purposely avoided its comparison with other programming frameworks for context-aware applications. This is because there is no single standard programming model or framework for context-aware applications against which our model and approach can be directly compared. In our discussion of the related work (Section 6) we provide a detailed comparative analysis of our framework with other frameworks and systems for context-aware application development. ACM Transactions on Software Engineering and Methodology, Vol. V, No. N, Month 20YY.


5.1

·

27

Testbed Applications

We developed several context-aware applications in our testbed environment using the programming framework presented here. Some of the significant ones, apart from the patient information system application (PI), were music-player, distributed meeting, and a whiteboard application. The details about the first two applications and the patient information system can be found in [Kulkarni 2009], whereas the details of the latter can be found in [Ahmed 2004]. These applications served as a basis for evaluating the programming model and the generative middleware. MusicPlayer (MP): This application primarily exercised context-based service discovery and binding mechanisms in the design model. This application runs on the user’s mobile device, and depending on the context conditions it streams music either to the user’s headphones or to the audio player in the room where the user is currently present. This application implements the following requirements. (1) When the user enters a room, this application automatically starts streaming music to the room’s audio player, only if no other person is present in the room. (2) When the user leaves the room or when some other person enters the room, the application reverts streaming music to the device’s audio player. Components developed for this application included, an audio streaming component, and an audio player service, which played the audio streams received from the sender. Both these components were developed using Java Media Framework (JMF). The audio player services were run in different rooms and also on the user’s device. The services in various rooms were registered with the discovery service. The context information required for this application included the user’s location, the user’s arrival in and departure from various rooms, the arrivals and departures of other people in the room where the user was present, and the number of people present in the room where the user was present. For obtaining this context information we reused the context agents that we had developed for the patient information system. Whiteboard (WB): This is a collaborative application which serves as a shared discussion facility amongst a group of users. This application involves two roles: moderator, and participant. A single user is admitted to the moderator role, whereas multiple users may be present in the participant role. We generated three different implementations of this application for the following three policies. (1) The moderator grants access to participants in first come first serve (FCFS) manner. (2) The moderator grants access to any requesting participant. (3) Participants vote to select the next person who can use the board. With this application, we tested event-based coordination mechanisms in the design model. Application-defined events were used for representing participant requests and the subsequent grants given by the moderator. The application components developed for whiteboard included a drawing component. The primary context information was the application’s internal coordination state corresponding to the requests made by different participants and access granted by the moderator. Distributed Meeting (DM): This is a distributed meeting application spanning multiple rooms. The meeting involves a chairperson, a secretary, and number of ACM Transactions on Software Engineering and Methodology, Vol. V, No. N, Month 20YY.

28

·


participants who may be present in different rooms. This application implements the following requirements. (1) A participant is allowed to perform a classified presentation as long as he or she is co-located with the chairperson in the same room. (2) The presentation of the classified information by the participant is displayed only on the projector in the room where the participant is present together with the chairperson. (3) The presentations made by the chairperson are displayed in all the rooms. (4) The presentation in a room is terminated if no participant remains in the room. For satisfying the first requirement, we used role operation precondition mechanism. The second requirement was satisfied by defining a private object in the participant role. The third requirement could not be satisfied directly in the design model. To satisfy this requirement it was necessary to treat multiple active-space services (in this case projector services) as a single group. We had to extend the design model for this purpose. This is explained in Section 5.2. The last requirement was satisfied using an activity-level reaction. The application component developed for the distributed meeting included a display service. An instance of this service was run in different rooms in which the meeting was conducted. All these services were registered with the discovery service provided in the active-space. The context information required for this application included locations of various users and the number of people present in different meeting rooms. Similar to the music-player application we reused the context agents developed for the patient information system in this application. 5.2

Lessons from Testbed Application Development

Development of these applications brought forth the following drawbacks of the programming model and the middleware. Subsequently, we addressed them in the design revision. 5.2.1 Binding order. We realized that when multiple objects’ binding actions are triggered by a specific context event, the order in which objects are bound can be crucial for correct application behavior. Specifically, it is important to bind the objects that refer to context-services before binding other objects. We encountered the problem due to incorrect binding order in the music player application, which occasionally behaved incorrectly. The problem was that one of the object’s binding reactions depended on the context information which had to be queried from an object referring to a context service (context object). For this, it was important to bind the latter object (the context object) first. Doing otherwise led to cases where stale context information was used in executing binding actions, causing the application to misbehave. To address such situations, we added a construct in the design model through which binding order for a set of objects could be specified. 5.2.2 Concurrent event handling. In some cases, we realized that concurrent processing of context events by different binding reactions may lead to incorrect application behavior. We encountered problems due to this in the music player application. Specifically, an object’s binding was getting over-written causing the application to behave incorrectly. To avoid such situations it was important for the middleware to ensure atomicity in handling context events. In the revised design, we ensure this by requiring that the object managers handle the context events ACM Transactions on Software Engineering and Methodology, Vol. V, No. N, Month 20YY.


·

29

sequentially. We refer the reader to [Kulkarni and Tripathi 2008a] for the details of the problems that we encountered due to not following an appropriate binding order and due to concurrent handling of context events. 5.2.3 Service Collections. As noted earlier, the distributed meeting application needed to manage a set of active-space services as a group. We defined the Collection abstraction in the model for this purpose. Multiple services can be bound to a collection. Methods invoked on a collection are executed on all the services that are currently bound to it. 5.2.4 Revocation of access privileges. We realized that the operation precondition mechanism was not sufficient for enforcing access control policies that required a task to be executed only while some specified ambient context condition continued to hold. We encountered this situation in the distributed meeting application. Specifically, the participant was able to continue the presentation of classified material even after the chairperson had left the room. We wanted the participant’s privilege for performing classified presentation to be revoked when the chairperson was no longer in the room. The precondition mechanism enabled checking of context conditions only once, before the corresponding operation’s actions were executed. It did not support checking of context conditions after the operation session had begun. For revoking a user’s access privileges, it is crucial to monitor if the context condition associated with an operation gets invalidated while an operation’s session is active. We added ContextGuard mechanism [Kulkarni and Tripathi 2008b] in the programming model for this purpose. Such a guard can be associated with a role operation. Context conditions that need to hold while an operation’s session is active can be specified using this mechanism. Such conditions can be different from those specified in an operation’s precondition. The middleware terminates the operation session if the context condition specified in the guard fails to hold while the session is active. 5.2.5 Handling failures. The dynamic nature of active-spaces raises several failure issues related to an object’s binding with an active-space service. The discovery protocols may result in a failure because the required service may not be available in the active-space, or a service may reject an application’s binding request because of its own policies. Our experience in developing the testbed applications confirmed this observation. Consequently, we added support for programmed error recovery in the programming model [Kulkarni and Tripathi 2008a]. In Section 5.3, we briefly discuss the error recovery mechanisms provided in our model. 5.2.6 Limitation. The generative approach does not permit modification and extensions to an application’s execution environment that has been already created. The modification is not possible because the policies are derived and integrated with the middleware components as part of the application generation process. A completely new execution environment needs to be generated when any changes are required in any of the policies related to an already instantiated application. We believe that this limitation can be overcome for those context-based requirements for which it is sufficient to evolve an activity by adding new roles, objects, or reactions that are independent from the previously defined entities in that activity. ACM Transactions on Software Engineering and Methodology, Vol. V, No. N, Month 20YY.

30

·


The middleware can generate the new managers corresponding to the newly defined entities. This approach needs further research. 5.3

Extensibility

The design of the programming model for context-aware applications presented here was conceived as an extension to an earlier programming model which we had designed for building CSCW applications [Ahmed 2004]. That programming model supported the concepts of activities, roles, and objects. It also supported mechanisms for specifying and enforcing coordination constraints. However, that model did not contain mechanisms for context-aware computing. Specifically, there were no mechanisms for context-based service discovery and binding, context-based access control, and context-triggered task executions. In order to support these context-based functionalities, following extensions were needed. The object manager had to be extended with mechanisms for context-based service discovery and binding. A new manager for handling activity-level reactions had to be introduced. The policy derivation routines had to be modified to take into consideration contextbased preconditions and context-based resource access constraints. Furthermore, as identified in Section 5.2, we also extended the design model and the middleware based on our experiences in designing the testbed applications. Specifically, in the design model we added a construct for specifying object binding order and the ContextGuard construct for specifying context conditions that need to hold while an operation’s session is active. In the middleware we made the following modifications. We extended the role manager to monitor the context conditions specified in a context guard associated with a role operation, and to terminate the operation’s session when the guard condition fails to hold. To address the issues due to concurrent handling of context events we modified the object manager to support atomic handling of such events. A substantial extension to the programming model was in the form of mechanisms for programmed error recovery using exception handling for context-aware applications [Kulkarni and Tripathi 2008a; 2010]. 5.4

Middleware Support for Application Environment Generation

Our goal in this evaluation was to quantify the support provided by the middleware towards generating an application’s execution environment. For this we measured the components that are automatically created by the middleware for the application. In Table I we present the number of various components that are automatically generated by the middleware for each application. For traditional application development, such components would need to be designed and programmed by the application designer. The dynamically created components for a context-aware application include the managers for the activities, roles, and objects, the subscription and notification policies, object-binding policies, and the access control lists (ACLs) for various object managers. The number of activity and role managers is exactly equal to the number of activities and roles defined in the activity specification. One object manager is created for every activity-scope object. For objects that are private to a role, one object manager is created for every object corresponding to every user admitted to the role. The total number of subscription and notification policies involving role operation ACM Transactions on Software Engineering and Methodology, Vol. V, No. N, Month 20YY.


App.

MP WB PI DM

Table I. Activity characteristics: Various Applications Roles Objects Num of Num of Num of Subscription Notification Object Policies Policies ACLs 1 2 2 2

4 2 5 7

3 18 2 4

0 18 1 1

45 10 13 21

·

31

Num of Binding Policies 8 2 4 7

events depends on the number of event count-based precondition predicates defined in the activity’s specification. Specifically, for a single precondition node involving a single operation event count based predicate, one instance of a subscription policy and one instance of a notification policy is derived. The total number of subscription and notification policies is therefore equal to twice the number of precondition nodes containing operation event nodes. Additionally, as part of the subscription policies, we also consider all the context events that are subscribed by an activity. The total number of object-binding policies for an object is equal to the number of binding actions defined for it. 5.5

Performance of Activity Instantiation Procedures

The goal of this evaluation is to measure how long it takes for the generative middleware to construct an application’s execution environment. All the experiments were done on an Intel Pentium 4 CPU 2.6GHz machine with 1GB of RAM.

App.

MP WB PI DM

Table II. Activity Instantiation Times: Various Applications Num of XML Policy Manager Activity DOM Instance Tree Derivation Instantiation Instantiation tree Creation nodes (seconds) (seconds) (seconds) (seconds) 170 6.71 0.05 68.18 77.33 105 3.63 0.90 81.37 86.15 85 2.9 0.17 74.10 78.94 163 6.15 0.20 100.75 110.05

In Table II we present average values (over three experiments) for the three steps involved in activity instantiation. These steps are: (1) creation of XML DOM tree for the activity instance, (2) policy derivation, and (3) creation of various managers. The activity instantiation time includes the time taken by all the three steps. The time for XML instance tree creation step is directly proportional to the number of nodes present in the XML DOM tree. The time for policy derivation step is directly proportional to the number of subscription and notification policies derived for the activity (fourth and fifth columns of Table I). The time for the manager instantiation step is directly proportional to the number of roles and objects defined in the activity (columns two and three of Table I) and the number of subscription policies derived for an activity (column four of Table I). ACM Transactions on Software Engineering and Methodology, Vol. V, No. N, Month 20YY.

32

·


We see that the activity instantiation times for these applications are under two minutes. This indicates that it is possible to realize different application designs fairly quickly, once application-specific resources and services are designed and implemented. 6.

RELATED WORK

The approaches investigated in the literature towards context-aware application development can be broadly categorized as, those based on using domain-specific languages (DSLs), those that provide toolkits/libraries for context-aware application development, and those that provide an adaptive middleware for introducing context-awareness within applications. DSL-based approach: Such an approach consists of using a high-level domainspecific language for programming a context-aware application. The language provides abstractions towards this purpose. Our high-level specification language is such a DSL. Similar to our work, the DiaSpec [Cassou et al. 2009] system also uses a DSL-based approach. DiaSpec is a DSL for describing and creating active-space services. That framework supports gluing together such services using distributed middleware technologies. However, the framework does not support coordination between users and access control over services. In contrast, our DSL is targeted toward pervasive activities and specialized towards coordination and access control of users and active-space services. We assume the active-space services, similar to those constructed by DiaSpec, are already developed and deployed in the environment. Hence our work is complementary to DiaSpec. A DSL for context-aware applications can be considered as an architecture description language (ADL) for specifying architectures of such applications. The notion of an activity in our model provides logical scope for an application. This is similar to scoping provided by an architecture description in general purpose ADLs such as Darwin [Magee et al. 1995], or Rapide [Luckham et al. 1995]. We also support nested activities which allow dynamically creating sub-scopes consisting of users and tasks for specific functions. The notion of dynamic object binding in our model is conceptually similar to the notion of dynamic modification of application configurations in such ADLs. Rather than a general purpose architecture description language, we provide a domain-specific design model for context-aware applications. It is specifically developed for user-centric distributed applications with the role-based model as a central element of context-based access control and coordination. It provides abstractions representing users through roles and services through objects. External components and services are integrated with an application through the binding rules. Toolkits/library based approach: In this approach a toolkit or a library in a general purpose programming language is provided for application development. Applications are developed by extending and reusing the library/toolkit classes. The systems belonging to this category include Gaia [Ranganathan et al. 2005], RCSM [Yau et al. 2002], and One.World [Grimm et al. 2004]. In Gaia, the Olympus toolkit is provided to program active-spaces. Olympus programs are written in C++. The coordination between different Olympus tasks is achieved by writing Lua scripts. A distinguishing aspect of our model as compared ACM Transactions on Software Engineering and Methodology, Vol. V, No. N, Month 20YY.


·

33

to Olympus is handling of object bindings. In our model it is possible to specify multiple context-based rules for binding an object to different active-space services under different context conditions. In Gaia, a virtual entity (which is similar to our object abstraction) can be bound only once, when the Olympus program is instantiated in a specific active-space. The Gaia middleware binds such an entity to the best available resource in that space. In comparison to our discovery model which only considers current context, Gaia’s discovery process takes into consideration resource state, such as the current load, in addition to context information. A common aspect of our system and Gaia is the use of roles in context-based access control. Gaia defines roles that are specific to different physical spaces in an active-space [Sampemane et al. 2002]. Such roles are managed by the security service running in that active-space. In Gaia, the use of context information in defining roles is thus restricted to the granularity of a physical area. In contrast our system differs from Gaia in the following ways. First, in our system roles are supported within the programming model itself. This is not the case in Olympus. Second, the mechanisms of role operation precondition and resource access constraint in our model provide fine-grain integration of context information in access control policies. Other researchers have also developed RBAC models specifically for contextaware pervasive computing applications, e.g., the GRBAC model [Covington et al. 2001]. In that model context-based access control is performed by defining different environmental roles pertaining to different context conditions. Such a definition leads to large number of roles in an access control system, as there might be potentially many environmental states that are relevant for an application. Through the resource access constraint mechanism we enforce access control requirements that depend on the relationship of a resource’s attributes with the context information, such as the identity and the location of the role member who is accessing the resource. Similar requirements have been discussed and addressed previously in [Giuri and Iglio 1997; Ge and Osborn 2004]. The mechanisms of parameterized privileges [Giuri and Iglio 1997] and parameterized roles [Ge and Osborn 2004] essentially perform access control based on an object’s contents. Content-based access control ideas can be traced back to the work on access control based on data types in programming languages [Jones and Liskov 1978]. In RCSM [Yau et al. 2002] containers are used to introduce context-awareness in application components. A container encapsulates an application component and interfaces with context services. The containers are programmed using the contextaware interface definition language provided in the RCSM system. Containers react to changes in context conditions and invoke application component’s methods when the specified context conditions are detected. Such a container-based approach is mostly useful for programming event-condition-action (ECA) based contexttriggered task executions. One.World system [Grimm et al. 2004] defines an eventbased programming model for programming pervasive computing applications. Applications are programmed in Java. An application consists of a collection of event-handlers reacting to contextual events. In contrast to both RCSM and One.World, we support both, asynchronous event handling (through reactions), and synchronous user interactions (through role operations). The synchronous ACM Transactions on Software Engineering and Methodology, Vol. V, No. N, Month 20YY.

34

·


interaction model naturally supports programming of context-based access control and coordination policies in our model, which is not the case for RCSM and One.World. There are several toolkits developed for integrating context data as part of context-aware applications [Dey et al. 2001; Judd and Steenkiste 2003; Julien and Roman 2006; Henricksen and Indulska 2004]. The Context Toolkit [Dey et al. 2001] provides an abstraction of a context widget, similar to GUI widgets, to collect context data from distributed sensors. A virtual database abstraction for collecting context information, along with a SQL-like language for querying context-based information is defined in [Judd and Steenkiste 2003]. The EgoSpaces system [Julien and Roman 2006] provides a middleware to support a declarative model for context specification and detection. The framework presented in [Henricksen and Indulska 2004] uses a graphical approach for context modeling. The design model for context-aware applications presented here is orthogonal to such context detection systems and infrastructures. In our testbed environment we have designed an agent based context detection infrastructure [Tripathi et al. 2007]. One can replace this with any other system for context detection. The main requirements for such a context detection system are the following. First, it should provide query and notification interfaces through which an application may obtain the required context information. Second, it should provide integrity and authenticity of the sensor data, as applications may use the context information in enforcing access control requirements. In our system, this is achieved using an authentication protocol developed earlier by us for mobile agents [Karnik and Tripathi 2001]. Middleware-based approach: The main element of this approach is the use of an adaptive middleware for introducing context-awareness in an application. The systems that belong to this category include Aura [Poladian et al. 2006; Garlan et al. 2004], Chisel [Keeney and Cahill 2003], CARISMA [Capra et al. 2003], PROSE [Popovici et al. 2003] and Rainbow [Garlan et al. 2004]. The main distinction between our model and the Aura system is the use of roles in our model for representing users. This enables us to program context-based access control and coordination requirements of an application. Aura does not support such requirements. In Chisel, CARISMA, and PROSE, adaptations are triggered by policies that are separate from an application’s design. In contrast to the above systems, in our model the context-based adaptations are specified in an application’s design itself. An advantage of this approach is that one can analyze an application’s design specification to verify its security and coordination properties [Ahmed and Tripathi 2007]. A disadvantage is that the policies cannot be changed, once an application’s execution environment has been created. Chisel treats the context-based adaptations of an application as its non-functional behaviors, or aspects, which are separate from the application. For certain applications, it may not be possible to satisfy the adaptation requirements by performing such a functional/non-functional separation. For example, in the patient information system, the context-triggered binding of the objects is the application’s primary requirement and cannot be separated out as an aspect. The philosophy expounded by systems such as Chisel and CARISMA is to cusACM Transactions on Software Engineering and Methodology, Vol. V, No. N, Month 20YY.


·

35

tomize the middleware based on application requirements. A similar approach towards toolkits for programming CSCW and workflow applications has been propounded in the past [Dourish 1998; Nutt 1996]. For instance, the framework presented in [Dourish 1998] uses reflection to specialize a generic toolkit for CSCW applications for the needs of the particular collaborative application that is being developed. The work presented in this paper is also related to two well-known programming methodologies, generative programming, and component integration models. Generative programming: The generative programming framework presented here has similarities with other generative programming approaches [Zhand and Jarzabek 2003; Smaragdakis et al. 2004; Batory et al. 2003]. This is seen in the separation between an activity’s template and its instances, and use of specialization for creating application-specific components from their generic counterparts. There are two aspects in which our generative middleware differs from the above mentioned systems. First, unlike the program generator system of [Smaragdakis et al. 2004], our middleware is an application generator. The output of the instantiation phase is a running application in which the components may bind to different underlying services under different context conditions. Second, we use policies for the purpose of specialization of generic components. One advantage of this policybased approach is that policies precisely characterize the variation points in the generic components. Component integration models: Our approach for construction of context-based collaboration systems can be compared to component integration models such as Java Beans [Banavar et al. 1998], and service integration models such as BPEL [Chakraborty and Lei 2004]. Though component integration models, as in [Banavar et al. 1998], support auto generation of applications, due to the lack of a higherlevel specification model, without custom coding, they cannot support different coordination policies for participants and access control policies on resources and context services. In [Chakraborty and Lei 2004], separation of specification from its realization of context-based business processes are achieved through an extension of BPEL. However these are limited to business transactions. 7.

FUTURE WORK

There are several aspects of this work where further investigation can help in making this framework more practical. One direction is generation of tests for an application from its activity specification. In the literature two broad approaches have been investigated towards testing of context-aware applications. These are, control-flow testing [Wang et al. 2007] and data-flow testing [Lu et al. 2006]. Both these approaches are based on identifying specific points in a context-aware application’s code that are affected by context information, and generating tests that exercise all possible control and data flows involving these special points. A high-level specification model such as ours can be helpful in identifying these special program points and generating the corresponding tests. For instance, consider the CurrentWard object (Figure 6). A control-flow test for the BindCurrentWard reaction consists of testing that when the UserArrivalEvent is generated the discoverybased binding action is executed. A data-flow test consists of testing that the ACM Transactions on Software Engineering and Methodology, Vol. V, No. N, Month 20YY.

36

·


UserArrivalEvent being utilized in the reaction’s discovery-based binding action is same as the one that triggered the reaction. We envision that an activity’s specification can be used to generate such tests. Another direction in which our work can be extended is verification of contextbased properties of context-aware applications using model checking techniques. Verification can help in designing correct specifications for context-aware applications. In our previous work [Ahmed and Tripathi 2007] we have used model checking for verifying the security, coordination, and information-flow properties of CSCW applications. Those techniques can be extended to verify contextual properties such as dynamic discovery binding and context-based access control. Moreover, model checking can also help in detecting ordering and concurrency related issues (lessons 5.2.1 and 5.2.2) in such applications. Yet another interesting future direction would be to investigate how high-level programming approaches such as ours can be made usable for persons who are not traditional programmers. This is important as the application domains encompassed by context-aware pervasive computing tend to involve a variety of users some of whom may not have software engineering background. For such users, it should be possible to design and build active-space applications for their specific needs. The domain-specific high-level programming framework presented here, howsoever helpful, could still be a barrier to such users as it requires a designer to understand concepts such as roles, events, binding, and access-control, necessarily the purview of only those with a traditional software engineering background. Thus, there certainly exists a need to build systems that can further lower the barrier of developing active-space applications. This problem falls under the broader scope of making programming tasks approachable to non-programmers. In this regard certain user groups such as teens and artists have received attention by researchers. Systems such as Scratch [Resnick et al. 2009] and OpenFrameworks [OpenFrameworks ] have been created for these communities. It remains to be seen if such approaches can be developed for designing active-space applications. 8.

CONCLUSIONS

In this paper we have presented the architecture of a programming framework for building context-aware CSCW applications using generative programming techniques. The execution environment of a context-aware application is generated from its domain-specific design model. This design model provides mechanisms for context-based dynamic binding of application objects to ambient services, and integrates context-based access control and coordination mechanisms in a role-based model. A policy-driven middleware is used for generating the distributed execution environment of an application. For this purpose a set of generic components are specialized using policy modules that are derived from an application’s design specification. These policy modules are related to dynamic binding of objects, role-based access control, and event communication. In this paper a case-study application is used to demonstrate this design model and the architecture of the generative middleware. We have implemented a number of context-aware applications in our testbed environment to evaluate and demonstrate the capabilities of this system. The results of our evaluations demonstrate the benefits of using ACM Transactions on Software Engineering and Methodology, Vol. V, No. N, Month 20YY.


·

37

generative programming techniques in building context-aware CSCW applications. REFERENCES Ahmed, T. 2004. Policy Based Design of Secure Distributed Collaboration Systems. Ph.D. thesis, University of Minnesota, Minneapolis. Ahmed, T. and Tripathi, A. R. 2007. Specification and Verification of Security Requirements in a Programming Model for Decentralized CSCW Systems. ACM Transactions on Information and System Security (TISSEC) 10, 2, 7. Banavar, G., Doddapaneni, S., Miller, K., and Mukherjee, B. 1998. Rapidly Building Synchronous Collaborative Applications By Direct Manipulation. In Proceedings of CSCW’98. 139–148. Bardram, J. E., Hansen, T. R., Mogensen, M., and Søgaard, M. 2006. Experiences from RealWorld Deployment of Context-Aware Technologies in a Hospital Environment. In Ubicomp. 369–386. Batory, D., Sarvela, J. N., and Rauschmayer, A. 2003. Scaling Step-wise Refinement. In ICSE ’03: Proceedings of the 25th International Conference on Software Engineering. IEEE Computer Society, Washington, DC, USA, 187–197. Cabri, G., Ferrari, L., and Leonardi, L. 2004. Agent Role-based Collaboration and Coordination: A Survey About Existing Approaches. Systems, Man and Cybernetics, 2004 IEEE International Conference on 6, 5473–5478. Capra, L., Emmerich, W., and Mascolo, C. 2003. CARISMA: Context-Aware Reflective Middleware System for Mobile Applications. IEEE Transactions on Software Engineering 29, 929–945. Cassou, D., Bertran, B., Loriant, N., and Consel, C. 2009. A Generative Programming Approach to Developing Pervasive Computing Systems. Proceedings of the Eigth International Conference on Generative Programming and Component Engineering, (GPCE’09), 137–146. Ceri, S. and Widom, J. 1990. Deriving Production Rules for Constraint Maintenance. In Proceedings of the Sixteenth International Conference on Very Large Databases. 566–577. Chakraborty, D. and Lei, H. 2004. Pervasive Enablement of Business Processes. In Second IEEE International Conference on Pervasive Computing and Communications, PERCOM’04. Consolvo, S., Roessler, P., Shelton, B. E., LaMarca, A., Schilit, B., and Bly, S. 2004. Technology for Care Networks of Elders. IEEE Pervasive Computing 3, 2, 22–29. Corts, M. and Mishra, P. 1996. DCWPL: A Programming Language for Describing Collaborative Work. In Proceedings of CSCW’96. 21 – 29. Covington, M. J., Long, W., Srinivasan, S., Dey, A. K., Ahamad, M., and Abowd, G. D. 2001. Securing Context-Aware Applications Using Environment Roles. In SACMAT ’01: Proceedings of the Sixth ACM Symposium on Access control Models and Technologies. 10–20. Czarnecki, K. and Eisenecker, U. W. 2000. Generative Programming Methods, Tools, and Applications. Addison-Wesley. Davies, N., Cheverst, K., Mitchell, K., and Efrat, A. 2001. Using and Determining Location in a Context-sensitive Tour Guide. IEEE Computer 34, 8 (August), 35–41. Dey, A. K., Abowd, G. D., and Salber, D. 2001. A Conceptual Framework and a Toolkit for Supporting the Rapid Prototyping of Context-Aware Applications. Hum.-Comput. Interact. 16, 2, 97–166. Dourish, P. 1998. Using Metalevel Techniques in a Flexible Toolkit for CSCW Applications. ACM Trans. Comput.-Hum. Interact. 5, 2, 109–155. ¨ geholz, S. 2004. A Case Study in Access Control Requirements for a Evered, M. and Bo Health Information System. In ACSW Frontiers ’04: Proceedings of the Second Workshop on Australasian Information Security, Data Mining and Web Intelligence, and Software Internationalisation. 53–61. Fleck, M., Frid, M., Kindberg, T., O’Brien-Strain, E., Rajani, R., and Spasojevic, M. 2002. From Informing to Remembering: Ubiquitous Systems in Interactive Museums. IEEE Pervasive Computing 1, 2, 13–21. ACM Transactions on Software Engineering and Methodology, Vol. V, No. N, Month 20YY.

38

·


Garlan, D., Cheng, S.-W., Huang, A.-C., Schmerl, B., and Steenkiste, P. 2004. Rainbow: Architecture-based Self-adaptation with Reusable Infrastructure. Computer 37, 10 (Oct.), 46– 54. Garlan, D., Siewiorek, D., Smailagic, A., and Steenkiste, P. 2002. Project Aura: Toward Distraction-Free Pervasive Computing. IEEE Pervasive computing 1, 2 (April-June), 22–31. Ge, M. and Osborn, S. L. 2004. A Design for Parameterized Roles. In DBSec. 251–264. Giuri, L. and Iglio, P. 1997. Role Templates for Content-based Access Control. In RBAC ’97: Proceedings of the Second ACM Workshop on Role Based Access Control. 153–159. Grimm, R., Davis, J., Lemar, E., Macbeth, A., Swanson, S., Anderson, T., Bershad, B., Borriello, G., Gribble, S., and Wetherall, D. 2004. System Support for Pervasive Applications. ACM Trans. Comput. Syst. 22, 4, 421–486. Henricksen, K. and Indulska, J. 2004. A Software Engineering Framework for Context-Aware Pervasive Computing. In Second IEEE International Conference on Pervasive Computing and Communications, PERCOM’04. 77–86. Jones, A. K. and Liskov, B. H. 1978. A Language Extension for Expressing Constraints on Data Access. Commun. ACM 21, 5, 358–367. Judd, G. and Steenkiste, P. 2003. Providing Contextual Information to Pervasive Computing Applications. In Proceedings of the First IEEE International Conference on Pervasive Computing and Communications, PERCOM’03. 133–142. Julien, C. and Roman, G.-C. 2006. EgoSpaces: Facilitating Rapid Development of ContextAware Mobile Applications. IEEE Trans. Softw. Eng. 32, 5, 281–298. Karnik, N. and Tripathi, A. 2001. Security in the Ajanta Mobile Agent Programming System. Software Practice and Experience, 301–329. Keeney, J. and Cahill, V. 2003. Chisel: A Policy-Driven, Context-Aware, Dynamic Adaptation Framework. In POLICY ’03: Proceedings of the 4th IEEE International Workshop on Policies for Distributed Systems and Networks. IEEE Computer Society, Washington, DC, USA, 3–14. Kulkarni, D. 2009. Mechanisms for Access Control and Application-level Recovery in ContextAware Applications. Ph.D. thesis, University of Minnesota, Minneapolis. Kulkarni, D. and Tripathi, A. 2007. Generative Programming Approach for Building Pervasive Computing Applications. In SEPCASE ’07: Proceedings of the 1st International Workshop on Software Engineering for Pervasive Computing Applications, Systems, and Environments. IEEE Computer Society, Washington, DC, USA, 3. Kulkarni, D. and Tripathi, A. 2008a. Application-level Recovery Mechanisms for ContextAware Pervasive Computing. In Proceedings of the 27th IEEE Symposium on Reliable Distributed Systems (SRDS’2008), 13–22. Kulkarni, D. and Tripathi, A. 2008b. Context-Aware Role-based Access Control in Pervasive Computing Systems. In Proceedings of the 13th ACM Symposium on Access control Models and Technologies (SACMAT’08), 113–122. Kulkarni, D. and Tripathi, A. 2010. A Framework for Programming Robust Context-Aware Applications. Software Engineering, IEEE Transactions on 36, 2 (March), 184 –197. Li, D. and Muntz, R. 1998. COCA: Collaborative Objects Coordination Architecture. In Proceedings of CSCW’98. 179–188. Lu, H., Chan, W. K., and Tse, T. H. 2006. Testing Context-Aware Middleware-centric Programs: A Data Flow approach and an RFID-based Experimentation. In SIGSOFT ’06/FSE-14: Proceedings of the 14th ACM SIGSOFT International Symposium on Foundations of Software Engineering. ACM, New York, NY, USA, 242–252. Luckham, D. C., Kenney, J. J., Augustin, L. M., Vera, J., Bryan, D., and Mann, W. 1995. Specification and Analysis of System Architecture Using Rapide. IEEE Trans. Softw. Eng. 21, 4, 336–355. Magee, J., Dulay, N., Eisenbach, S., and Kramer, J. 1995. Specifying Distributed Software Architectures. In Proceedings of the 5th European Software Engineering Conference. SpringerVerlag, London, UK, 137–153. Malone, T. W. and Crowston, K. 1994. The Interdisciplinary Study of Coordination. ACM Computing Surveys (CSUR) 26, 1 (March), 87 – 119. ACM Transactions on Software Engineering and Methodology, Vol. V, No. N, Month 20YY.


·

39

Nutt, G. J. 1996. The Evolution towards Flexible Workflow Systems. Distributed Systems Engineering 3, 276–294. OpenFrameworks. http://www.openframeworks.cc/. Available at URL http://www.openframeworks.cc/. Poladian, V., Pedro, S. J., Garlan, D., Schmerl, B., and Shaw, M. 2006. Task-Based Adaptation for Ubiquitous Computing. IEEE Transactions on Systems, Man, and Cybernetics, Part C: Applications and Reviews, Special Issue on Engineering Autonomic Systems 36, 3 (May). Popovici, A., Frei, A., and Alonso, G. 2003. A Proactive Middleware Platform for Mobile Computing. In M. Endler and D. Schmidt (Eds.): Middleware 2003, LNCS 2672. Springer Berlin / Heidelberg, 455–473. Ranganathan, A., Chetan, S., Al-Muhtadi, J., Campbell, R. H., and Mickunas, M. D. 2005. Olympus: A High-Level Programming Model for Pervasive Computing Environments. In Proceedings of the Third IEEE International Conference on Pervasive Computing and Communications, PERCOM ’05. 7–16. ´ndez, A., Rusk, N., Eastmond, E., Brennan, K., Resnick, M., Maloney, J., Monroy-Herna Millner, A., Rosenbaum, E., Silver, J., Silverman, B., and Kafai, Y. 2009. Scratch: Programming for All. Commun. ACM 52, 11, 60–67. ´n, M., Hess, C. K., Cerqueira, R., Ranganathan, A., Campbell, R. H., and Nahrstedt, Roma K. 2002. Gaia: A Middleware Platform for Active Spaces. Mobile Computing and Communications Review 6, 4, 65–67. Sampemane, G., Naldurg, P., and Campbell, R. H. 2002. Access control for Active Spaces. In Annual Computer Security Applications Conference (ACSAC2002). Sandhu, R., Coyne, E., Feinstein, H., and Youman, C. 1996. Role-Based Access Control Models. IEEE Computer 29, 2 (February), 38–47. Schilit, B., Adams, N., and Want, R. 1994. Context-Aware Computing Applications. In IEEE Workshop on Mobile Computing Systems and Applications. Santa Cruz, CA, US, 85–90. Smaragdakis, Y., Huang, S. S., and Zook, D. 2004. Program Generators and the Tools to make them. In PEPM ’04: Proceedings of the 2004 ACM SIGPLAN Symposium on Partial Evaluation and Semantics-based Program Manipulation. ACM, New York, NY, USA, 92–100. Tripathi, A. 2002. Adaptive Middleware: Challenges Designing Next-Generation Middleware Systems. CACM 45, 6 (June), 39–42. Tripathi, A., Ahmed, T., Kumar, R., and Jaman, S. 2002. Design of a Policy-Driven Middleware for Secure Distributed Collaboration. In Proceedings of International Conference on Distributed Computing Systems 2002. 393 – 400. Tripathi, A., Kulkarni, D., and Ahmed, T. 2005. A Specification Model for Context-Based Collaborative Applications. Elsevier Journal on Pervasive and Mobile Computing 1, 1 (MayJune), 21 – 42. Tripathi, A. R., Kulkarni, D., Talkad, H., Koka, M., Karanth, S., Ahmed, T., and Osipkov, I. 2007. Autonomic Configuration and Recovery in a Mobile Agent-based Distributed Event Monitoring System. Software - Practice & Experience 37, 5, 493–522. Wang, Z., Elbaum, S., and Rosenblum, D. S. 2007. Automated Generation of Context-Aware Tests. In ICSE ’07: Proceedings of the 29th International Conference on Software Engineering. IEEE Computer Society, Washington, DC, USA, 406–415. Weiser, M. 1991. The Computer for the 21st Century. Scientific American. Yau, S. S., Karim, F., Wang, Y., Wang, B., and Gupta, S. K. S. 2002. Reconfigurable ContextSensitive Middleware for Pervasive Computing. IEEE Pervasive Computing 1, 3, 33–40. Zhand, H. and Jarzabek, S. 2003. An XVCL-based Approach to Software Product Line Development. In International Conference on Software Engineering and Knowledge Engineering, SEKE’03.

ACM Transactions on Software Engineering and Methodology, Vol. V, No. N, Month 20YY.

A Generative Programming Framework for Context-Aware ... - CiteSeerX

A Generative Programming Framework for Context-Aware ... - CiteSeerX

Suggest Documents

Generative Programming for C#

Conceptual framework for generative design - Generative Art ...

A Retargetable Parallel-Programming Framework for ... - CiteSeerX

TRANSACT: A Transactional Framework for Programming ... - CiteSeerX

A Generative/Adaptive Programming Paradigm for Game ... - CiteSeerX

A Generative Programming Approach for Game Development

A Generative Programming Approach for Game

a generative framework for participatory designing of

Generative Programming for Automatic Differentiation

A Nonparametric Framework for Quantifying Generative ... - arXiv

A FRAMEWORK FOR ECOSYSTEM-BASED GENERATIVE MUSIC

Generative Programming from a DSL Viewpoint

Generative Programming Techniques for Java ... - Semantic Scholar

A Generative Programming Approach to Developing Pervasive ...

A Generative Approach to Building a Framework for Hard ... - INFRES

A Generative-Discriminative Framework using Ensemble ... - Microsoft

A Generative-Discriminative Framework using Ensemble ... - Microsoft

A GENERATIVE-DISCRIMINATIVE FRAMEWORK ... - Google Sites

A GENERATIVE-DISCRIMINATIVE FRAMEWORK USING ... - Microsoft

Church: a language for generative models - CiteSeerX

A Framework for Parallel Programming in Java - CiteSeerX

TermWare: A Rule-Based Framework for Programming ... - CiteSeerX

A Framework for Parallel Programming in Java - CiteSeerX

A Framework for Developing Agent Programming Systems - CiteSeerX