A Generative Programming Framework for Context-Aware CSCW Applications

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 applica-

tion development for building context-aware collaborative applications. In this approach context-aware applications are implemented using a domain-specific design model, and their executionenvironment is generated and maintained by the middleware. The key features of this design modelinclude support for context-based service discovery and binding, context-based access control,

context-based multi-user coordination, and context-triggered automated task executions. Themiddleware uses the technique of policy-based specialization for generating application-specificmiddleware components from the generic middleware components. Through a case-study ex-

ample, we demonstrate this approach and present the evaluations of the design model and themiddleware.

Categories and Subject Descriptors: D.2.11 [Software Architectures]: Domain-specific archi-tectures; 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, Genera-

tive Middleware

1. INTRODUCTION

In recent years, there has been a growing interest in designing and building context-aware applications [Weiser 1991; Schilit et al. 1994] that adapt their behavior basedon the changing ambient conditions of the user’s physical environment. Contextrefers to a situation in the physical or the virtual world that may be utilized byan application for the purpose of dynamic adaptation, for example, to acquireambient resources and services needed in a given location. Such applications mayalso involve multiple users interacting based on the CSCW (Computer-SupportedCooperative Work) models for workflow and “group-aware” collaborative activities.Emerging CSCW applications aim at utilizing context information for enhancingapplication functionalities. Examples of context-aware CSCW applications includeassisted 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 personalor 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, andnotice 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 sev-eral reasons. Such applications need context-based dynamic integration of applica-tion components, ambient resources, and infrastructure services. They need supportfor different kinds of user interaction models and access control policies, which canbe context dependent. Some of the applications involve users who move acrossdifferent physical spaces and administrative boundaries while engaged in applica-tion activities. Traditional design approaches for building context-aware CSCWapplications has been to custom-build an application for some specific targeteddomain, such as city tour guides [Davies et al. 2001], context-aware communicationfacilities [Henricksen and Indulska 2004], and interactive museums [Fleck et al.2002]. Such approaches require custom design and implementation of complexprotocols for dynamic resource discovery and access control. This results in highcost of programming and development efforts. Moreover, such approaches do noteasily support design modifications needed due to changes in design requirementsor technology evolution.

Context−AwareCollaboration Environment

Context−Aware

Collaboration Environment

Shared Application Resources, and

Services

XML−basedActivity−Template 2

XML−based

Activity−Template 1

(based on design 1)

(based on design 2)

(Application Compiler,

Policy−driven Middleware)

FrameworkGenerationApplication

Fig. 1. Regeneration of context-aware applications based on different specifications

We present here a domain-specific programming framework that we have devel-oped for building context-aware applications from their domain-specific high-levelspecifications. This framework embodies principles of the generative programmingparadigm [Czarnecki and Eisenecker 2000]. In this framework, context-aware ap-plications are designed using a domain-specific design model and realized througha policy-driven distributed middleware [Tripathi 2002; Tripathi et al. 2002]. Thedesign model is expressed in XML. This design model and the middleware togetherprovide a composition framework for integrating users, application-defined compo-nents, and infrastructure resources and services to build the execution environmentof a context-aware CSCW application. The process of generating an application’sexecution environment in this framework is shown in Figure 1. In this approach, aconstruct called activity template is used as the high-level abstraction for specifyingthe design of a context-aware application. The activity template is integrated withthe shared application resources and ambient services to instantiate the executionenvironment of an application. Such an integration uses various kinds of policieswhich are derived from the activity template. These policies are related to dynamicresource discovery and binding, context-based multi-user coordination, and context-based 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 acontext-aware application.

There are several advantages of using this generative approach in our program-ming framework. First, the domain-specific design model provides mechanisms forprogramming a context-aware CSCW application using a set of high-level abstrac-tions, thus simplifying their designs. Second, the middleware provides generic com-ponents that encapsulate protocols for context-based service discovery and binding,user authentication, secure interactions among distributed components, context-based access control, and inter-task coordination. This relieves the programmerfrom the task of custom development of such protocols. Third, we provide toolsupport to verify domain-specific security and coordination properties of the synthe-sized context-aware applications [Ahmed and Tripathi 2007]. Using this frameworkwe have designed and implemented several context-aware CSCW applications inour testbed environment which include a context-aware patient information system,a collaborative whiteboard, a context-aware music player [Kulkarni and Tripathi2008b], a context-aware distributed meeting [Tripathi et al. 2005], a student ex-amination application [Ahmed and Tripathi 2007], and an emulation of a museumenvironment.

Towards supporting the generative techniques for building the execution envi-ronments 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-awarecollaborative applications. This model supports abstractions and mechanismsfor context-based service discovery and binding, context-based access control,context-based multi-user coordination, and context-triggered automated taskexecutions.

—Development of a generative process for creating the execution environmentsof context-aware applications. We present the architecture of the middlewarecomponents, the runtime data structures and their use by the middleware com-ponents.

—Development of techniques for the derivation and representation of application-specific policies, and their integration with the middleware components for build-ing an application’s execution environment.

This paper is organized as follows. In Section 2 we present the domain require-ments for context-aware CSCW applications. In Section 3 we present the high-leveldeclarative model that we have developed for designing context-aware applications.In Section 4 we present the generative middleware, concentrating on the followingaspects: the process of creating the execution environment of a context-awareapplication, 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 generatingthe execution environments of context-aware applications, present our experiencesand lessons learned from using this framework in developing several context-awareapplications, and discuss the model’s extensibility. In Section 6 we compare ourwork with the related work. In Section 7 we discuss the future work, and concludein Section 8.



2. DOMAIN REQUIREMENTS

Here we present the main requirements of context-aware applications that formedthe basis for developing the domain-specific design model in our programmingframework. These requirements are related to the following characteristics of context-aware applications: context-based dynamic discovery of and binding to resources,context-triggered automated task executions, dynamic access control, and context-based multi-user coordination. The first two characteristics have been identifiedas key characteristics of such applications since the earliest days of context-awarecomputing [Schilit et al. 1994], whereas the latter two have become importantin recent years as the realm of context-aware computing has extended to includedomains such as health-care systems.

The ambient computing environment in which context-aware applications aredeployed is called an active space [Roman et al. 2002]. Such a space may spanmultiple physical spaces. An active-space provides the infrastructure services thatare required for deploying and running context-aware applications. Such servicesinclude context services, discovery services, naming services, and services for au-thorization and access control [Roman et al. 2002; Garlan et al. 2002].

An application needs to interface with one or more context services for obtainingthe required context information. For this purpose a context service may interfacewith various kinds of sensors. To represent the context information, a contextservice may utilize different kinds of context models [Henricksen and Indulska 2004].Such models need to represent the dynamic context conditions required withinvarious context-aware applications. Specifically, a context model needs to representvarious entities in the active-space, their attributes, and the relationships betweenthe various entities. Context conditions are characterized in terms of the entityattributes and their relationships. From an application’s perspective, context con-ditions can be categorized as external or internal. Examples of external contextconditions include users’ physical and network locations, a person’s proximity toother people and physical objects, number and identities of people present at aparticular location, users’ devices, device characteristics, or temporal conditions.An example of an internal context condition is the history of tasks performed by aperson 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-awareapplication to dynamically discover and integrate resources and services that areavailable in an active-space. For example, consider a context-aware patient infor-mation system deployed in a hospital. One requirement for this application canbe that it dynamically binds a doctor’s handheld computing device to a patient’srecords who is currently being visited by that doctor. This binding needs to changeas 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 thefunctional view of a service required by a context-aware application. We use theterm object for such a logical representation. An object may be dynamically boundto different services under different context conditions. An object acts as a proxyof the service to which it is bound. Such a service can be an application-specific



service or a context service.Dynamic binding of an object with a service may involve discovering the appro-

priate service in the active-space. For this purpose, an object needs to be associatedwith the description of the service’s functional interfaces and attributes. Contextinformation may need to be used as part of the discovery process. For example, auser’s location may be used to bind an object to an active-space service based onthe user’s current location.

2.2 Representation of Users and Tasks

Certain context-aware applications may need to support execution of different tasksby its users. For example, in a patient information system the tasks that may beperformed by doctors and nurses include creating, updating, and accessing patientrecords, requesting laboratory tests, etc. Moreover, some ambient resources andservices 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 forexecuting tasks in a context-aware application. The tasks are represented througha set of operations defined for that role. Users admitted to a role can perform thespecified tasks by executing the corresponding role operations [Ahmed and Tripathi2007].

The notion of role has been traditionally used to represent a set of responsibilitiesand privileges associated with a particular position within an organization [Sandhuet al. 1996]. In CSCW and group-ware applications the notion of a role has beenused to provide a natural abstraction for representing users without requiring priorknowledge 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 hasbeen developed by others [Cabri et al. 2004]. There, a role specifies the functionalbehavior of an agent. Our model utilizes the notion of roles for both access controland functional abstractions.

2.3 Context-based Access Control

Context-aware applications may need to restrict a user’s privileges to executecertain role operations based on context conditions. For example, in a context-awarepatient information system there could be a requirement that a nurse is allowedto access a patient’s records only when located in the patient’s room. This is anexample of location-based access control. An example of co-location based accesscontrol is the requirement where a nurse may be allowed to initiate workflow foraccessing doctor reports about a patient only in the presence of a doctor. To handlesuch requirements the design model needs to support specification of context-basedaccess control requirements over user tasks.

In certain cases an active-space service may be managing a set of resources andwe may need to restrict a user’s access to a subset of these resources based on thecontext conditions. For example, in the patient information system the databaseservice may be managing and controlling access to information about patients indifferent hospital wards. There might be a requirement that a nurse is allowed toaccess records of only those patients who are admitted to the ward where the nurseis currently located. In the design model, we need a mechanism through which the



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

2.4 Context-based Multi-User Coordination

Coordination consists of managing flow of data, sharing of resources, synchro-nization of resource usage, and other relations among workflow activities, suchas decomposition of workflow activities into tasks/subtasks and planning how suchtasks would be performed [Malone and Crowston 1994]. An example of coordinationrequirement in the patient information system is the following: a nurse can createtest reports for a patient only after the appropriate tests have been performed anda doctor has given the nurse the permission to create such reports.

The nature of coordination in the above example resembles loosely coupled asyn-chronous interactions, such as those commonly occurring in workflow environments.On the other hand, in real-time synchronous collaborations, users are connected tothe system simultaneously and their interactions occur through interactive sharingand manipulation of graphical and multimedia objects. Generally, the interactionstend to be unstructured, often spontaneous, and the coordination management isconcerned with concurrency control for access to shared resources. The coordinationpolicies may widely vary from one organization to another, and they may alsochange with time. The design model needs to provide constructs for expressingboth types of coordination requirements.

2.5 Context-triggered Automatic Task Executions

One of the primary motivations for context-aware computing is to enhance userexperience by relieving the user from performing routine tasks which can be auto-matically executed based on the occurrence of certain context conditions. Examplesof such tasks include dynamic discovery-based binding of the application to ap-propriate active-space services, dispatching alerts when some pre-defined contextconditions occur, or notification of a message to a person based on the person’scurrent location. The design model needs to support mechanisms for automaticallyexecuting 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 programmingmodel for context-aware applications. This model needs to support the followingabstractions and mechanisms. An abstraction is required to represent the designof a context-aware application as a whole. Such an abstraction provides the logicalscope for defining various resources required by the application and the tasks thatmay be performed within the application. We need an abstraction to represent thefunctional view of active-space resources and services required by the application.Such an abstraction may bind to different active-space services under differentcontext conditions. An abstraction is needed to represent application users andtheir tasks. Execution of such tasks may need to be constrained subject to theapplication’s context-based access control and coordination policies. Lastly, weneed a mechanism to represent the tasks that may be automatically executed bythe application when certain context conditions become true.



The high-level programming model that we have developed contains the followingbasic elements: activities, roles, objects, and reactions. These elements are discussedbelow.

Activity: A context-aware application is represented and programmed using anabstraction called activity. An activity contains roles, and may contain objects andreactions. An activity provides a namespace for the roles, objects, and reactions.

In Figure 2 we present a UML class diagram showing the relationships betweenthe programming model elements. We have developed an XML schema correspond-ing to this programming model. A context-aware application is specified using anactivity template, which is defined in this schema. An activity is instantiated fromits template. Any number of activity instances can be created from an activitytemplate.

Event

NotifyEvent

0..*

0..1 0..1

Generates

Generates

Uses

Uses

Uses

Uses

1..*

0..*

0..* 0..* 0..*

0..*

X

1..*

Operation

Action

Activity

1..*

1..*

0..*

1..*

1..*

Y

0 or 1 of Y

1..*

Legend:

X

Y

X Composed ofY

0 or more of Y

0..*

AccessConstraint

SessionInvoke Invoke

Method

Y

YX Uses

X

X Y

Composed ofX

1 or more of YComposed ofX

0..1

GeneratesX Y

X

Role Object

Precondition

Reaction

memberRole

Fig. 2. Activity Class Diagram in UML

Roles: A role defines user privileges for performing application tasks, which arerepresented by operations defined in the role. An operation name is defined in thenamespace of a role. A role operation can contain one or more actions. An actionmay involve invoking a method on an object, or generating an application-definedevent. Associated with each role operation is an optional precondition. Actions areexecuted only if the operation’s precondition is true.

Objects: An object provides a reference within an activity for accessing a servicewhich can be an application-specific service or a context service. It acts like aproxy for the service to which it is currently bound. Such a binding may changewith the context conditions. Objects may be defined within an activity, or theymay be defined within a role. Objects that are defined within the activity-scope areaccessible to all roles, i.e. the operations in any role can invoke methods on such



objects. The latter kind of objects are private to a role, i.e. they can be accessedonly through that role’s operations. Moreover, a separate instance of such an objectis created for each member in that role.

For object binding purpose, two mechanisms are defined in the programmingmodel. One mechanism is to explicitly specify a service by providing its networkaddress. The other mechanism is based on discovering the required service in theambient computing environment, based on the current context conditions. Thelatter mechanism is useful when the service’s location is not known a priori andmay need to be discovered.

Object Invocation Models: There are two kinds of models supported for accessingan object. These are shown in Figure 3.

(1) In the method invocation model, a user invokes a role operation, which resultsin the invocation of a method on the service that is bound to the object onwhich the operation invocation is specified.

(2) In the session interaction model, invocation of a role operation by a userresults in the initiation of an interactive session between the user and theservice. Through such a session, the user may execute an arbitrary sequenceof permitted methods on the service. The role operation completes when thesession is terminated.

Methodinvocation

Serviceinvocation

Operation finish

Action

ObjectRole Operation

Operation start

ServiceUser

Operation start Action

OperationInvocation

through Interface componentsMethod invocation on a service

Action specifying session invocationOperation

Action specifying single method invocationLegend: User session interaction

Method Invocation Model

Session Invocation Model

InteractionSession

SessionSession start

finishSession

Operation finish

��

��

��

��

��

��

��

��

��

��

��

��

Fig. 3. Interaction models

Reactions: A reaction is used to program event-triggered actions for support-ing automated task executions. A reaction follows the Event-Condition-Action(ECA) [Ceri and Widom 1990] model of evaluation and is executed by the runtimesystem. A reaction is triggered by one or more context events. The actions specified



in a reaction are executed only if the reaction’s precondition is true. In case theprecondition is not true, the event is discarded.

Reactions can be defined at the activity-level and also within an object. Activity-level reactions are used for two purposes. One is to program activity-level tasksthat need to be automatically executed when certain context conditions occur.The second purpose is to program activity-level configuration actions which mayinvolve establishing communication relationships between two or more activity-levelobjects. Reactions defined within an object are used to specify its binding policies.The actions that such reactions can execute are restricted to object binding andevent notifications.

Nested Activities: Within a context-aware application, occasionally we may needto instantiate sub-activities. For example, in the patient information system adoctor may need to create a patient treatment activity for a patient. In theprogramming model we support nested activities for this purpose.

An activity template may define nested templates, whose instantiation result inthe creation of child activities. Each child activity defines its own namespace. Thenesting of activities results in creation of a hierarchically structured namespace. Ina nested activity, the visibility of objects, roles, and event names is restricted tothe name-scope of that activity. A nested activity may need to have access to theobjects in the scope of its parent activity. For this, objects in the parent activity’snamespace 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 patientinformation application as an example. We have implemented a prototype of thisapplication in our testbed environment. It supports a number of requirements asfollows [Evered and Bogeholz 2004].

P1. The application maintains various kinds of records and reports for the pa-tients admitted to different wards in the hospital. The application permits doctorsto 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 presentin the ward where the nurse is located, and also if a doctor has given prior approvalfor such an access.

P4. A nurse is allowed to access records of only those patients who are admittedto the ward where the nurse is currently present.

We model the above requirements using the PatientInformation activity tem-plate, whose schematic is presented in Figure 4. The partial specification of thisactivity is presented in Figure 5. Corresponding to different departments in ahospital, separate PatientInformation activity instances can be created from thistemplate. For presenting the activity template specification we use a pseudo nota-tion. 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 LocationSer-vice. The PatientDB object refers to the database service that holds the patient



Active−space

ActivityTemplate

ActivityTemplate

PatientInformation

PatientCare

Printer

Nurse

CurrentWard

Ward1Info

Service

My

Object

ServiceDatabaseService

LocationService

DisplayService

Service

Ward2 Printer1 Printer2Info

PatientDB Service

Service

Legend: Activity

Location

Service

Binding

Role

DoctorRole

CreatePatientReports

CreatePatientCareActivity

ApprovePatientDataAccess

Role

AccessDoctorReports

AccessWardPatientInfo

Print

Fig. 4. 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 pro-viding location information for nurses and doctors.



Role Nurse {

.....Object CurrentWard RDD (//WardRDD.xml) {

Reaction BindCurrentWard {

When Event UserArrivalEventBind 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 definetwo private objects, CurrentWard and MyPrinter. A separate instance of theseobjects is created for each member of the nurse role. The CurrentWard object fora Nurse role member refers to the context service of the ward where that nurseis currently present, and the MyPrinter object refers to the printer in that ward.We define the following operations in the nurse role. The AccessDoctorReportsoperation allows a nurse to access doctors’ reports. The AccessWardPatientInfooperation allows a nurse to access the records of those patients who are admittedto the ward where the nurse is present. The Print operation enables printing to theprinter in the ward where the nurse is present.

In the Doctor role we define the following operations. The CreatePatientReportsoperation allows a doctor to create various reports about patients. Through theCreatePatientCareActivity operation a doctor can create the nested PatientCareactivity for a specific patient. The ApprovePatientDataAccess operation allows adoctor 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, themiddleware system provides a resource discovery service for dynamic registrationand discovery of available services in an active-space environment. Service discoveryis performed by matching an object’s description with the descriptions of variousservices that are registered with the discovery service. For describing functionsand attributes of objects and services, we have developed a schema called RDD(Resource Description Definition). An RDD is expressed in XML and containsspecification of the service’s attributes, its interfaces, and events to be importedfrom the service. RDDs are used for two functions. One is to specify the descriptionof a service for registration with the discovery service. The other function is forquerying the discovery service to find a service that matches the given descriptionin an RDD. For discovery, certain attributes in an object’s RDD may be specifiedat runtime based on the context information. The discovery procedure attemptsto find a service whose description matches to the RDD given in the query. Belowwe present two examples from the PatientInformation activity that illustrate thevarious binding mechanisms.

Example 1 (Discovery-based binding): The CurrentWard object defined in theNurse role refers to the context service corresponding to the ward in which a nurse



<RDD CATEGORY=CURRENTWARD>

<INTERFACE>

<METHOD NAME=presentUserCount><OUTPUTPARAM TYPE=int/>

</METHOD>

<METHOD NAME=isPresent><OUTPUTPARAM TYPE=boolean/>

</METHOD>

</INTERFACE>

<IMPORTEVENT>

<EVENT NAME=RoomStatusChangeEvent/>

</IMPORTEVENT>

<ATTRIBUTELIST>

<ATTRIBUTE NAME=LOCATION VALUE=$PARAM/>

</ATTRIBUTELIST>

</RDD>

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 referto context services of different wards as a nurse moves from one ward to anotherward. The binding specification for this object is shown in Figure 6. The bindingis triggered by the UserArrivalEvent that is generated whenever a particular Nurserole member enters a ward.

The WardRDD, shown in Figure 7, is used for the discovery purpose. This RDDdefines the interfaces that need to be supported by the context service to whichthe CurrentWard object would be bound. It also specifies the context events (inthis case RoomStatusChangeEvent) that would be imported by the activity fromthe service after binding the object to it. The LOCATION attribute in this RDDis a parameterized attribute. The value $PARAM of this attribute is specified atruntime using the location information of the Nurse role member corresponding towhom the UserArrivalEvent is generated. A similar binding directive is specified forbinding the MyPrinter object, thus satisfying requirement P2 given in Section 3.1.

Example 2 (Direct Binding): The PatientDB object is directly bound to thedatabase service that provides access to patient records. The corresponding spec-ification 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 themiddleware when the activity is instantiated. The binding of the LocationServiceobject is similar to that of the PatientDB object. After binding, the activity importsUserArrivalEvent from this service.

Object PatientDB {Reaction {

When Event ActivityCreationEventAction Bind Direct (//PatientDBServiceURL)

}

}

Fig. 8. Example of Direct binding primitive



3.3 Constraint Specification for Access Control and Coordination

Context-based access control and coordination policies are specified using con-straints. These constraints are specified through the precondition mechanism asso-ciated with a role operation. The precondition for an operation needs to hold beforethe operation’s actions can be executed. For our goal of supporting collaborativeapplications, we focus only on access control and coordination policies. Therecould be other kinds of policies also, for example, privacy policies and active-spaceadministrative policies such as, whether an activity is allowed to use resources andservices in an active-space. However, we do not support these in our programmingmodel.

A constraint is a boolean expression which may involve predicates based on eventcounts, role membership information, and context information. An event-basedpredicate is expressed using logical expressions involving event counts and eventattributes. The programming model supports three kinds of events. The first kindof events are system-defined start and finish events which are related to operationexecutions. These events are implicitly generated by the runtime system. When anoperation is invoked and if the operation’s precondition is satisfied, the operation’sstart event is generated and the execution of the operation’s actions begins. Anoperation’s finish event is generated when the operation’s actions complete. Thesecond kind of events are application-defined events. These are explicitly generatedby an action in a role operation or reaction. The third kind of events are the contextevents, such as UserArrivalEvent, which are generated by context services.

Multiple occurrences of an event type are viewed to form an event-list. Thecount operator # applied to an event identifier, e.g. #EventName, returns thenumber of occurrences of that event type. A subsequence of an event-list canbe derived by filtering it based on some predicate on the event’s attributes. Foroperation start and finish events, there are two predefined attributes: invoker andtime. The expression roleId.opId.start(invoker=thisUser) defines a filter based onthe operation invoker’s identity. The variable thisUser in an expression representsthe identity of the user for whom the constraint is being evaluated. Using thecount operator, the expression #(roleId.opId.start(invoker=thisUser)) counts thenumber of times the user for whom the constraint is being evaluated has invoked therole operation opId. It is also possible to define and set custom attributes withinan event.

Role membership information can be used in constraint specification. The func-tion member(thisUser, RoleName) checks at runtime if the invoking user is a mem-ber in the role RoleName. Other functions are provided for querying the list ofcurrent members of a role.

Similarly, context information provided by ambient context services can also beused in constraint specification. For this purpose, such context services would typ-ically provide some query functions. For example, a context service that monitorsthe status of a ward may support a method such as isPresent(userId) to detect ifthe specified user is present in that ward.

Example 3: In Figure 9 we present how the requirement P3 given in Section 3.1is programmed using this model. The AccessDoctorReports operation of the Nurserole allows a member of this role to access the doctor reports available through



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 con-straints are required to satisfy the requirement P3. We use operation preconditionmechanism for this purpose.

In the Doctor role we define the ApprovePatientDataAccess operation throughwhich a doctor may give approval to a specific nurse for accessing patient records.An AccessApprovalEvent is generated when a doctor executes this operation. Theattribute nurseID within this event can be set by selecting a specific memberof the Nurse role. For this, the session invocation model, specified through theInvokeSession primitive, is used.

The precondition for the AccessDoctorReports operation in the Nurse role checksthe following: whether some member of the Doctor role is present in the ward wherethe nurse who is invoking this operation is present, and if the count of AccessAp-provalEvent for this Nurse role member is greater than zero. The InvokeMethodprimitive indicates that this operation follows the method invocation model, wherebythe accessDoctorReport method is invoked on the PatientDB object and the resultsare 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 acollection of resources, in many applications a need arises to constrain the roleoperation’s access to only a subset of these resources, based on the current con-text conditions. For example, a user’s access to a database service needs to berestricted to only those records that satisfy certain context-based predicates. Theprogramming model provides the resource access constraint mechanism for thispurpose [Kulkarni and Tripathi 2008b]. One can associate such a constraint withthe method invocation defined on an object in an action of a role operation. Sucha constraint specifies a relation between resource attributes and certain contextvariables. Only those resources that satisfy this predicate are allowed to be accessedthrough the role operation.



Example 4: Consider the AccessWardPatientInfo operation of the Nurse rolewhich allows a nurse to access the records of only those patients who are admittedto the ward where that nurse is currently present. To program this requirement, weuse the resource access constraint mechanism as shown in Figure 10. As part of theconstraint specification, we require that access should be granted to the nurse foronly those patient records for which the value of the WardID field in the patient’srecord matches the nurse’s current ward location. In this way the requirement P4given in Section 3.1 is satisfied.

Operation AccessWardPatientInfo {

Precondition TRUEAction PatientDB InvokeSession accessPatientInformation

AccessConstraint (WardID = CurrentWard.getWardID())

}

Fig. 10. Example of resource access constraint primitive

4. GENERATIVE MIDDLEWARE

We have taken a generative approach for creating the execution environments ofcontext-aware applications from their high-level design specifications [Kulkarni andTripathi 2007]. The central element of this approach is creation of application-specific components from the generic middleware components by specializing themiddleware components with application specific policies. The generic componentsencapsulate protocols for context-based service discovery and binding, and enforce-ment of context-based access control and multi-user coordination constraints. Thegeneric components provided in the middleware include the following managers.

Activity Template Manager: This manager maintains the activity template andenforces the security policies, which identify the roles and their operations that areallowed to instantiate that template.

Activity Manager: The primary function of an activity manager is to manage aspecific instance of an activity template. An activity manager creates the activity’snamespace, the role managers corresponding to the roles defined in the activity, theobject 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 support-ing the user interaction models for accessing various resources and services throughrole operations. The role manager performs the functions of constraining users’admission to the role, evaluation of operation preconditions, and performing rolemembership authentication on operation invocations.

Object Manager: An object manager supports the user-interaction models byperforming the requested method invocations by role operations. It acts as a proxyfor forwarding these invocations to the currently bound service. An object managerperforms event-triggered dynamic binding actions and also enforces object-levelaccess control policies.



The following kinds of requirements were addressed in developing the architectureof this middleware.

Generative Process Requirements: These requirements are related to the design ofthe managers, and generation of an application’s execution environment.—A system architecture needs to be developed that enables composing of var-

ious managers and their interaction protocols for creating and managing theexecution environment of a context-aware application.

—Appropriate architectures need to be designed for the various generic managersto enable their specialization based on an activity’s specification.

—Mechanisms need to be developed for deriving application-specific policies froman application’s specification for creating its execution environment.

Decentralized Management Requirements: These requirements are related to themanagement aspects of an activity. Specifically, the middleware needs to addressthe 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 ororganizations may be trusted to manage different roles and objects of anactivity.

—Because coordination and access control constraints are based on events, thesystem needs to ensure the authenticity of event sources, inferred from thedesign specification.

4.1 Approach Overview

The process of generating a context-aware application’s execution environmentis partitioned into three phases as shown in Figure 11. The first phase is thedesign phase. The designer has to develop the activity specification correspondingto the application requirements. The designer has to also develop the requiredapplication components, active-space services, and if necessary, application-specificcontext models and context services utilizing the context services available in theactive-space.

Design Phase Compilation

− Design Context

Specification− Create Activity

Managers− Create Instance

Instances− Derive Policy

DOM tree− Create Instance

− Create Activity

− Derive Policy

− Create Template

InstantiationPhasePhase

ModelsTemplates

Template Manager

DOM tree

Fig. 11. Three phases in context-aware application generation

The second phase is the compilation phase, which is executed by the middlewarefor a given activity template. The primary function of the compilation phaseis to create the data structures and the policy objects required for generatingthe execution environment for an activity instance from the template. This isdone just once for an activity template, thus reducing the time required in its



instantiation. The two basic entities created in this phase are the activity’s templatemanager, and the template policies. The activity template manager maintains arepresentation of the activity template in the form of its XML Document ObjectModel (DOM) tree. The template policy objects are maintained with the activitytemplate manager. These template policy objects are parameterized. This meansthat the instance specific information such as the names of the various roles andobjects are maintained as parameters within these template policy objects. Thespecific values for these parameters are specified only during the third phase, whichis the instantiation phase.

In the instantiation phase the following steps are executed. The activity templatemanager 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 particulartemplate that is being instantiated. The activity manager refines the templatepolicies with the instance specific information, such as the names for the variousentities defined in that activity instance. The activity manager then creates the rolemanagers, the object managers, and starts the reaction threads for the activity-levelreactions. The role managers create object managers corresponding to the objectsthat are defined in the role’s namespace. Lastly, the activity manager creates theactivity template managers for any nested activity templates.

Discovery Service Infrastructure Context

Application Execution Environment

Trusted Server

Active space Environment

Legend: User Interaction Discovery Binding

Services Components

Activity Manager Role Manager Object Manager

UCI UCIUCI

Application−specificApplication−specific Application−specific

ServicesApplication

Fig. 12. Architectural overview of a context-aware application

In Figure 12 we present an overview of the execution environment and com-ponents of a context-aware application. The application execution environmentconsists of managers specialized according to the activity’s specification. Thesemanagers are active objects that support remote interfaces through Java RMIand are run on the trusted servers. These servers provide a trusted environmentfor hosting and running the various managers that are instantiated as part of anapplication’s execution environment. For a single user application such servers may



be run on the user’s device. For a multi-user application, such servers may be runin 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 tasksby 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 XMLDOM tree representation. In Figure 13 we present how a template tree for anactivity evolves when different instances of that activity are created. In this figurewe only show nodes for activities, roles, and objects. Each of these nodes is a rootof a subtree. For example, a role node is the root of the subtree containing one ormore operations, an object node is the root of the subtree containing one or morebinding reactions, etc. In case of an activity template node, all of its sub-nodes aretemplate-based.

A top-level System activity is defined for providing the namespace for all ac-tivity templates created in the system. A system-defined role, called Convener,is responsible for instantiating the activity templates corresponding to the top-level activities. In part (a) of Figure 13 we show the template for the patientinformation activity. When an activity’s template is created, it is appended as achild of the System activity. The instance tree of an activity is appended as a childof that activity’s template root node. The instance tree represents the runtimedata-structure that maintains the execution state of an activity. The instance treecorresponding to the activity instance named Opthalmology is shown in part (b) ofFigure 13. This activity defines a new namespace containing nurse and doctor rolesthat are independent of other activity instances. The names of various nodes inthe instance tree are part of the namespace of the activity template which is beinginstantiated. For example, when the activity instance Opthalmology is created,the name of this instance is System.PatientInformation.Opthalmology. Because theactivity instance names are strongly tied with the scope of the activity template forwhich the current activity instance is created, the activity instance is appended asa child of the template node. A nested activity template PatientCare is specifiedfor 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 showtwo instances of the PatientCare activity one with name Patient1, and the otherwith 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 tothe 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 theexecution environment of an application. For the activity manager such functionsinclude creating managers for roles and objects defined in that activity. For the rolemanagers, the functions are enforcing context-based access control and coordinationpolicies, and executing the role operations. In case of object managers, the functionsperformed are context-based service discovery and binding, and enforcing object-level access control policies. In Section 4.5 and 4.6 we present the architecture of



��

��

��

��

(a) Creation of PatientInformation activity template

Service

Role Instance

Role Template

Object Instance

Object Template

Nested Template

Activity Instance

Activity Template

Legend:PatientInformationConvener

NurseDoctorLocationDB

PatientPatientCare

System

��

��

��

��

��

��

��

��

��

��

PatientCare

��

��

��

��

��

��

��

��

��

��

��

��

DoctorTests

Laboratory

Nurse Specialist

ServiceLocationPatientCare PatientDB

ServiceDoctor Nurse

Convener

(b) Creation of Opthalmology activity instance

PatientInformation

��

��

System

LocationPatientDB

Doctor Nurse

OpthalmologyOwner=Convener

Tests

PatientCare

��

��

Laboratory

(c) Creation of instances for nested activity PatientCare

SpecialistNurseDoctor

Laboratory

Owner=DoctorOwner=Doctor

Doctor Nurse SpecialistTests

Laboratory

Patient1 Patient2

Doctor Nurse SpecialistTests

��

��

��

��

��

��

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 pro-gramming model supports the notion of an owner of an activity, who is responsiblefor managing that activity. As a default rule, the role that instantiates an activityis designated as its owner. Otherwise, it is possible to specify a different role as theowner of an activity. In Figure 13, the Convener role is the owner of the activityinstance for the Opthalmology activity instance. In Figure 13(c), all PatientCare



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 ondifferent trusted servers belonging to the owners. Each manager object is giventhe 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 andexecuted on different servers belonging to the Convener role, who is the owner ofthe Opthalmology activity. The corresponding DOM subtrees for these roles areplaced at those servers. Similarly, the managers for the objects in an activity arecreated on the owner’s trusted servers. When a person in the Doctor role createsan instance of the PatientCare activity, its managers are created and executed onthe trusted server under the control of the Doctor role.

HandlerEvent

Operation:Access

Opthalmology

Activity Manager: Opthalmology

NurseEventApprovalAccessEvent

Opthalmology

#

constraintAdmission

Nurse

isPresent(members(Doctor))CurrentWard.

Doctor

AccessApprovalisPresent(thisUser)CurrentWard.

Role Manager: Nurse Role Role Manager: Doctor Role

Subscription PoliciesNotification Policies

^^

processingEvent

DOM Treereference

Subscriber

PreconditionAction

HandlerEvent

ReportsDoctor

Operation:ApprovePatientDataAccess

Action

Event(nurseID=thisUser)

EventApprovalAccessDoctor

EventNotifier

��

��

��

��

��

��

Fig. 14. Example of event subscription and notification policies

4.4 Policy Derivation for Runtime Management

The core of the compilation phase is the policy derivation procedure. The goalof this procedure is to derive the policies required for the runtime managementof an activity. The following types of policies are used in our middleware: (a)role admission policies, (b) coordination and access control policies, (c) context-based object binding policies, (d) object-level access control policies, (e) resourceaccess constraints, and (f) event subscription and notification policies. The first twokinds of policies are maintained with role managers, the next three kinds of policiesare maintained with object managers, and the event subscription and notificationpolicies are maintained by both.

Policies are represented in two basic forms: as Java objects, or as referencesto the nodes of the activity’s DOM tree. The policies that need to be derived byanalyzing the entire activity specification are maintained as Java objects. The event



subscription and notification policies, and the object-level access control policiesfor an object manager are maintained in this form. Policies that are specificto only a single entity are represented as pointers to the appropriate constraintspecification nodes in the activity’s instance tree representation. The policies thatare maintained in this form include role admission policies, access control policiesthat involve queries to context services, context-based object binding policies, andresource access constraints.

Event subscription/notification policies: The purpose of these policies is to ensuresecure event communication among various role managers, object managers, andthe activity manager of an instantiated activity. The event subscription policies fora manager specify the other managers that are allowed to subscribe to a given typeof event generated by this manager. The event notification policies for a managerspecify 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 theevents. Both these policies are determined by analyzing the activity specificationduring the compilation phase. The basic rule in policy derivation is to determinefor each role, object, and activity the various kinds of events that are used in theconstraint specification, and derive event subscription and notification policies forthose events.

The subscription and notification policies are derived in the template form fromthe activity template during the compilation phase. Then, as part of instanti-ating an activity instance from that template, these template policy objects arespecialized with the names of the specific role managers and object managerscorresponding to the activity instance that is being instantiated. This two-stepprocess helps in avoiding the expensive computation step of analyzing the activityinstance tree for deriving instance policies.

Figure 14 shows the event subscription and notification policies for the Nurseand the Doctor roles in the Opthalmology activity. The subscription policy for theDoctor role indicates that the Nurse role manager is allowed to subscribe to theAccessApprovalEvent from the Doctor role manager. The notification policy forthe Nurse role indicates that the Doctor role manager is a valid notifier of theAccessApprovalEvent. Whenever any Doctor role member invokes the ApprovePa-tientDataAccess operation, the AccessApprovalEvent is generated and notified tothe Nurse role manager. The event handler in the Nurse role manager updates thisevent’s count in the precondition tree specified for the AccessDoctorReports roleoperation.

Object-level access control policies: An object’s access control policies determinewhich roles and their operations are permitted to invoke a given method of theobject. These policies are maintained in the form of an access control list (ACL) forthe object. In our model, method invocations on an object may be specified at twoplaces: 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 <role, operation> 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 theactivity. On the other hand, for a role’s private objects, such an ACL can referto that role’s operations only. Similar to the subscription and notification policies,



the ACLs for an object are derived and maintained in the template form duringthe compilation phase, and specialized with activity-specific information during theinstantiation phase. In Figure 15 we present the ACL entries for the PatientDBobject defined in the PatientInformation activity specification. The Doctor in thePatientInformation activity $X can invoke the createReports method on it, and theNurse 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 byincorporating the information about the instantiated activity. For example, forthe Opthalmology activity, the instantiated access control policy looks as shown inFigure 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. Example of instantiated Access Control List (ACL)

4.5 Role Manager Architecture

A role manager performs two functions within the constructed execution environ-ment of a context-aware application. First, a role manager provides mechanismsthat enable users to perform application-specific tasks. Second, a role manager pro-vides trusted environment for enforcing task-specific context-based access controland coordination policies.

In Figure 17 we present the components of a role manager and interactions amongthem. The shaded elements are constructed for each role manager based on the



ReferenceRole Node

2

1

Events Events

��

��

��

��

��

��

��

��

5

(4)Check

Precondition

ProtocolsAuthentication

PreconditionNode Update

InterfaceInvocation

events,

InterfaceNotifier

InterfaceSubscriber

DOM Tree node referencePolicies

Component referenceEvent−flowControl−flowLegend:

ManagerTo Object

Action

Reference

(3)

Non−shaded elements: Generic Role Manager

DispatchOperation

FunctionsRole AdmissionRole Membership

Database

Node

Operation start/finish

Notification eventsApplication−specific

Role Member Private Object Space

Action Nodes

Action Dispatch

Policies

��

��

Event NotificationPolicies

PoliciesEvent Handling

Subscription

Table

Table

PoliciesAdmission

Fig. 17. Architecture of a Role Manager

activity specification, whereas the non-shaded elements are available as part of thegeneric role manager architecture.

The role manager contains an Operation Dispatch Table, which maintains refer-ences to the operation nodes in the activity’s instance DOM tree. The role manageralso maintains a list of the users who are currently admitted to that role. For everysuch user, an object manager is created corresponding to each object that is definedin the role’s private object space.

The role manager implements three interfaces: an invocation interface, a sub-scriber interface, and a notifier interface. The invocation interface supports opera-tion invocations by the role members through their UCIs. The subscriber interfaceis used by the other managers to subscribe to the events that are generated bythis role manager. The notifier interface is used for notifying remote events to thismanager.

Invocation of a role operation involving object method execution leads to ac-cessing of the service to which that object is currently bound. The steps takenby 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 methodinvocation (step 1). Authorization tickets are used to ensure that role operationinvocations are being performed by valid role members. Such a ticket contains anoperation’s name, and its parameters. The role manager verifies the ticket, extractsthe operation’s name from it, and then dispatches the operation execution byconsulting the operation dispatch table (steps 2 and 3). The role manager evaluatesthe precondition associated with the invoked operation using the operation’s DOMtree representation (step 4). If the precondition is true, the role manager passes themethod name and the method parameters to the object manager that is specified as



Subscriber Interface

1

Invocation Interface Notifier Interface

TableBinding Reaction

Binding Policies

(Using Reflection)To Service

Reaction NodeReference

��

��

Context Events

Non−shaded elements: Generic Object Manager

Control−flow Event−flowLegend: Component reference

Reference

Object NodeReferenceService

2

ProtocolsAuthentication

HandlerEvent

6543Dispatch

Operation

Access control policiesObject−level

Binding/Rebinding Events

ListMethod

NameOperation

::Node

ReactionEventName

��

��

filterconstraint

Resource access:

PoliciesSubscription

::

:

Fig. 18. Architecture of an Object Manager

part of the operation’s action (step 5). For this, the role manager uses a standardinterface implemented by the object manager. The object manager in turn invokesthe method on the currently bound service using reflection. A role operation maycontain 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 performscontext-based binding actions, thereby maintaining a reference to the appropriateservice of a given type under the current context conditions. Second, it enforcesmethod-level access control policies. This involves authenticating the role managerwhose member requested the method invocation, verifying that the invoked methodis permitted by the object ACL, and enforcing the resource access constraints. InFigure 18 we present the architecture of an object manager derived from the cor-responding generic manager. The shaded elements are constructed for each objectmanager based on the activity specification, whereas the non-shaded elements areavailable 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 andUCI to request method invocations. The subscriber interface is used by othermanagers to subscribe to the events that are generated by the object manager.Each object manager generates object binding and rebinding events whenever theobject’s binding changes [Kulkarni and Tripathi 2008a]. The notifier interface isused for receiving such events from other object managers and context events fromcontext services.

A request for method invocation may arrive from a role manager or a UCI. Theobject manager handles such requests as follows (steps 1 to 6). The object managerfirst 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’sACLs (step 2). The object manager then constructs the method parameters byapplying the specified resource access constraint filter on these parameters (steps 3and 4). We describe resource access constraints in Section 4.6.2. Finally, using



Java’s reflection API the object manager invokes the specified method on thecurrently bound service (steps 5 and 6). If the method invocation is specifiedusing the session invocation primitive (InvokeSession), the object manager createsa session with the service. Corresponding to such a session the object managermaintains information such as the identity of the role member initiating the session,and session-level authentication tickets. It also creates any session-specific userinterface components, if such components are provided for that session. The objectmanager terminates the session when the user who initiated the session explicitlyterminates it.

An object manager maintains two kinds of policies, the binding policies, andresource access constraints.

4.6.1 Object Binding Policies. These policies specify the following: when toperform the binding actions, how to identify the service to which the object shouldbe bound, and what context information, if any, should be used in the discoveryprocess. These policies are derived from the activity specification and maintainedin the binding reaction table in the following form: <context-event, binding reactionnode>. Each object manager subscribes to all the context events that are requiredas part of its binding reactions. These reactions get triggered when a context eventis delivered to the object manager.

4.6.2 Resource Access Constraints. A resource access constraint is a mechanismthat is used by the object manager to enforce context-based access control onresources that are managed by a service. There are two approaches for enforcingsuch constraints. In one approach, the object manager constructs a filter based onthe specified resource access constraints and passes this filter to the service as partof the method invocation. The service applies this filter and grants access to onlythose resources that satisfy the filter condition. The services need to be designedto support appropriate interfaces that can accept the access constraint filter as aparameter. In case a service does not provide such an interface, the filtering canbe done by the object manager itself. This corresponds to the second approach. Inthis approach, the object manager is able to access all the resources managed bythe service. To the role member, however, it grants access to only those resourceswhich satisfy the access constraint.

In Figure 19 we present the runtime evaluation of the access constraint examplewhich was earlier presented in Section 3.4. The PatientDB object manager grantsaccess to only those database records for which the WardID field in the patientrecords has the value equal to the location of the Nurse role member who is invokingthe operation.

4.7 Tool Support

Designing a context-aware application using our framework involves a number ofsteps. One has to design the required active-space services, the context services, anddevelop the activity specification. The active-space services and the context servicescan be designed using standard programming languages and design methodologies.The cost of developing the context services can be amortized across various appli-cations. For instance, several of our applications used the location service, whichwas developed once. We used an agent-based event aggregation system [Tripathi



=


UserCooridnation

Interface (UCI) Manager

Role: Nurse

Operation:AccessWardPatientInfo

Action

Precondition

InvokeSession

WardID

AccessConstraint

CurrentWard.getWardID()

GUI

method

ServicePatientDB ObjectNurse RoleManager

Precondition

EventHandler

response

Action


Components of Application Runtime Environment

response

ServiceReference

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 userlocations, number and identities of people present in a room, proximity of a userto a physical entity, and so on. For assisting the designer in creating activityspecifications, we provide a syntax-driven Activity Template Editor for creating theXML specifications.

5. EVALUATION

In this section we present the evaluation of the programming model and the genera-tive middleware. The programming model is evaluated for its support of designingdifferent kinds of context-aware applications. In Section 5.1 we briefly discusssome of the context-aware applications that we developed using this framework. InSection 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 generativemiddleware is evaluated in Section 5.4 for its support towards automating the task ofgenerating the execution environment of a context-aware application. In Section 5.5we consider the time taken to realize an application’s execution environment.

In evaluating our framework we have purposely avoided its comparison with otherprogramming frameworks for context-aware applications. This is because there isno single standard programming model or framework for context-aware applicationsagainst which our model and approach can be directly compared. In our discussionof the related work (Section 6) we provide a detailed comparative analysis ofour framework with other frameworks and systems for context-aware applicationdevelopment.



5.1 Testbed Applications

We developed several context-aware applications in our testbed environment us-ing 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 twoapplications and the patient information system can be found in [Kulkarni 2009],whereas the details of the latter can be found in [Ahmed 2004]. These applicationsserved as a basis for evaluating the programming model and the generative middle-ware.MusicPlayer (MP): This application primarily exercised context-based service dis-covery and binding mechanisms in the design model. This application runs on theuser’s mobile device, and depending on the context conditions it streams musiceither to the user’s headphones or to the audio player in the room where the useris currently present. This application implements the following requirements. (1)When the user enters a room, this application automatically starts streaming musicto the room’s audio player, only if no other person is present in the room. (2) Whenthe user leaves the room or when some other person enters the room, the applicationreverts streaming music to the device’s audio player.

Components developed for this application included, an audio streaming compo-nent, and an audio player service, which played the audio streams received fromthe sender. Both these components were developed using Java Media Framework(JMF). The audio player services were run in different rooms and also on theuser’s device. The services in various rooms were registered with the discoveryservice. The context information required for this application included the user’slocation, the user’s arrival in and departure from various rooms, the arrivals anddepartures of other people in the room where the user was present, and the numberof people present in the room where the user was present. For obtaining thiscontext information we reused the context agents that we had developed for thepatient information system.Whiteboard (WB): This is a collaborative application which serves as a shareddiscussion 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 threedifferent implementations of this application for the following three policies. (1) Themoderator grants access to participants in first come first serve (FCFS) manner.(2) The moderator grants access to any requesting participant. (3) Participantsvote to select the next person who can use the board.

With this application, we tested event-based coordination mechanisms in thedesign model. Application-defined events were used for representing participantrequests and the subsequent grants given by the moderator.

The application components developed for whiteboard included a drawing com-ponent. The primary context information was the application’s internal coordina-tion state corresponding to the requests made by different participants and accessgranted by the moderator.Distributed Meeting (DM): This is a distributed meeting application spanning mul-tiple rooms. The meeting involves a chairperson, a secretary, and number of



participants who may be present in different rooms. This application implementsthe following requirements. (1) A participant is allowed to perform a classifiedpresentation 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 displayedonly on the projector in the room where the participant is present together withthe chairperson. (3) The presentations made by the chairperson are displayed in allthe rooms. (4) The presentation in a room is terminated if no participant remainsin the room.

For satisfying the first requirement, we used role operation precondition mech-anism. The second requirement was satisfied by defining a private object in theparticipant role. The third requirement could not be satisfied directly in the designmodel. To satisfy this requirement it was necessary to treat multiple active-spaceservices (in this case projector services) as a single group. We had to extend thedesign model for this purpose. This is explained in Section 5.2. The last requirementwas satisfied using an activity-level reaction.

The application component developed for the distributed meeting included adisplay service. An instance of this service was run in different rooms in whichthe meeting was conducted. All these services were registered with the discoveryservice provided in the active-space. The context information required for thisapplication included locations of various users and the number of people presentin different meeting rooms. Similar to the music-player application we reused thecontext 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 theprogramming model and the middleware. Subsequently, we addressed them in thedesign revision.

5.2.1 Binding order. We realized that when multiple objects’ binding actionsare triggered by a specific context event, the order in which objects are bound canbe crucial for correct application behavior. Specifically, it is important to bind theobjects that refer to context-services before binding other objects. We encounteredthe problem due to incorrect binding order in the music player application, whichoccasionally behaved incorrectly. The problem was that one of the object’s bindingreactions depended on the context information which had to be queried from anobject referring to a context service (context object). For this, it was importantto bind the latter object (the context object) first. Doing otherwise led to caseswhere stale context information was used in executing binding actions, causing theapplication to misbehave. To address such situations, we added a construct in thedesign 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 concurrentprocessing of context events by different binding reactions may lead to incorrectapplication behavior. We encountered problems due to this in the music playerapplication. Specifically, an object’s binding was getting over-written causing theapplication to behave incorrectly. To avoid such situations it was important for themiddleware to ensure atomicity in handling context events. In the revised design,we ensure this by requiring that the object managers handle the context events



sequentially. We refer the reader to [Kulkarni and Tripathi 2008a] for the detailsof the problems that we encountered due to not following an appropriate bindingorder and due to concurrent handling of context events.

5.2.3 Service Collections. As noted earlier, the distributed meeting applicationneeded to manage a set of active-space services as a group. We defined the Collec-tion abstraction in the model for this purpose. Multiple services can be bound toa collection. Methods invoked on a collection are executed on all the services thatare currently bound to it.

5.2.4 Revocation of access privileges. We realized that the operation precondi-tion mechanism was not sufficient for enforcing access control policies that requireda task to be executed only while some specified ambient context condition continuedto hold. We encountered this situation in the distributed meeting application.Specifically, the participant was able to continue the presentation of classifiedmaterial even after the chairperson had left the room. We wanted the participant’sprivilege for performing classified presentation to be revoked when the chairpersonwas 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 supportchecking of context conditions after the operation session had begun. For revokinga user’s access privileges, it is crucial to monitor if the context condition associatedwith an operation gets invalidated while an operation’s session is active. We addedContextGuard mechanism [Kulkarni and Tripathi 2008b] in the programming modelfor this purpose. Such a guard can be associated with a role operation. Contextconditions that need to hold while an operation’s session is active can be specifiedusing this mechanism. Such conditions can be different from those specified in anoperation’s precondition. The middleware terminates the operation session if thecontext 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 fail-ure issues related to an object’s binding with an active-space service. The discoveryprotocols may result in a failure because the required service may not be availablein the active-space, or a service may reject an application’s binding request becauseof its own policies. Our experience in developing the testbed applications confirmedthis observation. Consequently, we added support for programmed error recoveryin the programming model [Kulkarni and Tripathi 2008a]. In Section 5.3, we brieflydiscuss the error recovery mechanisms provided in our model.

5.2.6 Limitation. The generative approach does not permit modification andextensions to an application’s execution environment that has been already created.The modification is not possible because the policies are derived and integratedwith the middleware components as part of the application generation process. Acompletely new execution environment needs to be generated when any changesare required in any of the policies related to an already instantiated application.

We believe that this limitation can be overcome for those context-based require-ments for which it is sufficient to evolve an activity by adding new roles, objects, orreactions that are independent from the previously defined entities in that activity.



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

5.3 Extensibility

The design of the programming model for context-aware applications presentedhere was conceived as an extension to an earlier programming model which wehad designed for building CSCW applications [Ahmed 2004]. That programmingmodel supported the concepts of activities, roles, and objects. It also supportedmechanisms for specifying and enforcing coordination constraints. However, thatmodel did not contain mechanisms for context-aware computing. Specifically, therewere no mechanisms for context-based service discovery and binding, context-basedaccess control, and context-triggered task executions. In order to support thesecontext-based functionalities, following extensions were needed. The object man-ager had to be extended with mechanisms for context-based service discovery andbinding. A new manager for handling activity-level reactions had to be introduced.The policy derivation routines had to be modified to take into consideration context-based preconditions and context-based resource access constraints. Furthermore,as identified in Section 5.2, we also extended the design model and the middlewarebased on our experiences in designing the testbed applications. Specifically, inthe design model we added a construct for specifying object binding order andthe ContextGuard construct for specifying context conditions that need to holdwhile an operation’s session is active. In the middleware we made the followingmodifications. We extended the role manager to monitor the context conditionsspecified in a context guard associated with a role operation, and to terminate theoperation’s session when the guard condition fails to hold. To address the issues dueto concurrent handling of context events we modified the object manager to supportatomic handling of such events. A substantial extension to the programming modelwas in the form of mechanisms for programmed error recovery using exceptionhandling 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 middlewaretowards generating an application’s execution environment. For this we measuredthe components that are automatically created by the middleware for the applica-tion. In Table I we present the number of various components that are automaticallygenerated by the middleware for each application. For traditional applicationdevelopment, such components would need to be designed and programmed bythe application designer.

The dynamically created components for a context-aware application include themanagers for the activities, roles, and objects, the subscription and notificationpolicies, object-binding policies, and the access control lists (ACLs) for variousobject managers. The number of activity and role managers is exactly equal tothe number of activities and roles defined in the activity specification. One objectmanager is created for every activity-scope object. For objects that are private toa role, one object manager is created for every object corresponding to every useradmitted to the role.

The total number of subscription and notification policies involving role operation



Table I. Activity characteristics: Various ApplicationsApp. Roles Objects Num of Num of Num of Num of

Subscription Notification Object Binding

Policies Policies ACLs Policies

MP 1 4 3 0 45 8

WB 2 2 18 18 10 2

PI 2 5 2 1 13 4

DM 2 7 4 1 21 7

events depends on the number of event count-based precondition predicates definedin the activity’s specification. Specifically, for a single precondition node involvinga single operation event count based predicate, one instance of a subscription policyand one instance of a notification policy is derived. The total number of subscriptionand notification policies is therefore equal to twice the number of precondition nodescontaining operation event nodes. Additionally, as part of the subscription policies,we also consider all the context events that are subscribed by an activity. The totalnumber of object-binding policies for an object is equal to the number of bindingactions 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 mid-dleware to construct an application’s execution environment. All the experimentswere done on an Intel Pentium 4 CPU 2.6GHz machine with 1GB of RAM.

Table II. Activity Instantiation Times: Various ApplicationsApp. Num of XML Policy Manager Activity

DOM Instance Tree Derivation Instantiation Instantiation

tree Creation

nodes (seconds) (seconds) (seconds) (seconds)

MP 170 6.71 0.05 68.18 77.33

WB 105 3.63 0.90 81.37 86.15PI 85 2.9 0.17 74.10 78.94

DM 163 6.15 0.20 100.75 110.05

In Table II we present average values (over three experiments) for the three stepsinvolved in activity instantiation. These steps are: (1) creation of XML DOM treefor 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 thenumber of nodes present in the XML DOM tree. The time for policy derivationstep is directly proportional to the number of subscription and notification policiesderived for the activity (fourth and fifth columns of Table I). The time for themanager instantiation step is directly proportional to the number of roles andobjects defined in the activity (columns two and three of Table I) and the numberof subscription policies derived for an activity (column four of Table I).



We see that the activity instantiation times for these applications are under twominutes. This indicates that it is possible to realize different application designsfairly quickly, once application-specific resources and services are designed andimplemented.

6. RELATED WORK

The approaches investigated in the literature towards context-aware applicationdevelopment can be broadly categorized as, those based on using domain-specificlanguages (DSLs), those that provide toolkits/libraries for context-aware applica-tion development, and those that provide an adaptive middleware for introducingcontext-awareness within applications.

DSL-based approach: Such an approach consists of using a high-level domain-specific language for programming a context-aware application. The languageprovides abstractions towards this purpose. Our high-level specification languageis such a DSL. Similar to our work, the DiaSpec [Cassou et al. 2009] systemalso uses a DSL-based approach. DiaSpec is a DSL for describing and creatingactive-space services. That framework supports gluing together such services usingdistributed middleware technologies. However, the framework does not supportcoordination between users and access control over services. In contrast, our DSL istargeted toward pervasive activities and specialized towards coordination and accesscontrol of users and active-space services. We assume the active-space services,similar to those constructed by DiaSpec, are already developed and deployed in theenvironment. Hence our work is complementary to DiaSpec.

A DSL for context-aware applications can be considered as an architecture de-scription language (ADL) for specifying architectures of such applications. Thenotion of an activity in our model provides logical scope for an application. This issimilar to scoping provided by an architecture description in general purpose ADLssuch as Darwin [Magee et al. 1995], or Rapide [Luckham et al. 1995]. We alsosupport nested activities which allow dynamically creating sub-scopes consisting ofusers and tasks for specific functions. The notion of dynamic object binding inour model is conceptually similar to the notion of dynamic modification of appli-cation configurations in such ADLs. Rather than a general purpose architecturedescription language, we provide a domain-specific design model for context-awareapplications. It is specifically developed for user-centric distributed applicationswith the role-based model as a central element of context-based access controland coordination. It provides abstractions representing users through roles andservices through objects. External components and services are integrated with anapplication through the binding rules.

Toolkits/library based approach: In this approach a toolkit or a library in ageneral 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. Olympusprograms are written in C++. The coordination between different Olympus tasksis achieved by writing Lua scripts. A distinguishing aspect of our model as compared



to Olympus is handling of object bindings. In our model it is possible to specifymultiple context-based rules for binding an object to different active-space servicesunder different context conditions. In Gaia, a virtual entity (which is similar to ourobject abstraction) can be bound only once, when the Olympus program is instan-tiated in a specific active-space. The Gaia middleware binds such an entity to thebest available resource in that space. In comparison to our discovery model whichonly considers current context, Gaia’s discovery process takes into considerationresource 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-basedaccess control. Gaia defines roles that are specific to different physical spaces inan active-space [Sampemane et al. 2002]. Such roles are managed by the securityservice running in that active-space. In Gaia, the use of context information indefining roles is thus restricted to the granularity of a physical area. In contrastour system differs from Gaia in the following ways. First, in our system roles aresupported within the programming model itself. This is not the case in Olympus.Second, the mechanisms of role operation precondition and resource access con-straint in our model provide fine-grain integration of context information in accesscontrol policies.

Other researchers have also developed RBAC models specifically for context-aware pervasive computing applications, e.g., the GRBAC model [Covington et al.2001]. In that model context-based access control is performed by defining differentenvironmental roles pertaining to different context conditions. Such a definitionleads to large number of roles in an access control system, as there might bepotentially many environmental states that are relevant for an application. Throughthe resource access constraint mechanism we enforce access control requirementsthat depend on the relationship of a resource’s attributes with the context infor-mation, such as the identity and the location of the role member who is accessingthe resource. Similar requirements have been discussed and addressed previouslyin [Giuri and Iglio 1997; Ge and Osborn 2004]. The mechanisms of parameterizedprivileges [Giuri and Iglio 1997] and parameterized roles [Ge and Osborn 2004]essentially perform access control based on an object’s contents. Content-basedaccess control ideas can be traced back to the work on access control based on datatypes in programming languages [Jones and Liskov 1978].

In RCSM [Yau et al. 2002] containers are used to introduce context-awareness inapplication components. A container encapsulates an application component andinterfaces with context services. The containers are programmed using the context-aware interface definition language provided in the RCSM system. Containers reactto changes in context conditions and invoke application component’s methods whenthe specified context conditions are detected. Such a container-based approachis mostly useful for programming event-condition-action (ECA) based context-triggered task executions. One.World system [Grimm et al. 2004] defines an event-based programming model for programming pervasive computing applications. Ap-plications are programmed in Java. An application consists of a collection ofevent-handlers reacting to contextual events. In contrast to both RCSM andOne.World, we support both, asynchronous event handling (through reactions),and synchronous user interactions (through role operations). The synchronous



interaction model naturally supports programming of context-based access controland coordination policies in our model, which is not the case for RCSM andOne.World.

There are several toolkits developed for integrating context data as part ofcontext-aware applications [Dey et al. 2001; Judd and Steenkiste 2003; Julien andRoman 2006; Henricksen and Indulska 2004]. The Context Toolkit [Dey et al. 2001]provides an abstraction of a context widget, similar to GUI widgets, to collectcontext data from distributed sensors. A virtual database abstraction for collectingcontext information, along with a SQL-like language for querying context-basedinformation is defined in [Judd and Steenkiste 2003]. The EgoSpaces system [Julienand Roman 2006] provides a middleware to support a declarative model for contextspecification and detection. The framework presented in [Henricksen and Indulska2004] uses a graphical approach for context modeling. The design model forcontext-aware applications presented here is orthogonal to such context detectionsystems and infrastructures. In our testbed environment we have designed an agentbased context detection infrastructure [Tripathi et al. 2007]. One can replace thiswith any other system for context detection. The main requirements for sucha context detection system are the following. First, it should provide query andnotification interfaces through which an application may obtain the required contextinformation. Second, it should provide integrity and authenticity of the sensordata, as applications may use the context information in enforcing access controlrequirements. In our system, this is achieved using an authentication protocoldeveloped earlier by us for mobile agents [Karnik and Tripathi 2001].

Middleware-based approach: The main element of this approach is the use ofan adaptive middleware for introducing context-awareness in an application. Thesystems that belong to this category include Aura [Poladian et al. 2006; Garlanet 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 dis-tinction between our model and the Aura system is the use of roles in our modelfor representing users. This enables us to program context-based access controland coordination requirements of an application. Aura does not support suchrequirements.

In Chisel, CARISMA, and PROSE, adaptations are triggered by policies thatare separate from an application’s design. In contrast to the above systems, inour model the context-based adaptations are specified in an application’s designitself. An advantage of this approach is that one can analyze an application’sdesign specification to verify its security and coordination properties [Ahmed andTripathi 2007]. A disadvantage is that the policies cannot be changed, once an ap-plication’s execution environment has been created. Chisel treats the context-basedadaptations of an application as its non-functional behaviors, or aspects, which areseparate from the application. For certain applications, it may not be possible tosatisfy the adaptation requirements by performing such a functional/non-functionalseparation. For example, in the patient information system, the context-triggeredbinding of the objects is the application’s primary requirement and cannot beseparated out as an aspect.

The philosophy expounded by systems such as Chisel and CARISMA is to cus-



tomize the middleware based on application requirements. A similar approachtowards toolkits for programming CSCW and workflow applications has been pro-pounded in the past [Dourish 1998; Nutt 1996]. For instance, the frameworkpresented in [Dourish 1998] uses reflection to specialize a generic toolkit for CSCWapplications for the needs of the particular collaborative application that is beingdeveloped.

The work presented in this paper is also related to two well-known programmingmethodologies, generative programming, and component integration models.

Generative programming: The generative programming framework presented herehas similarities with other generative programming approaches [Zhand and Jarz-abek 2003; Smaragdakis et al. 2004; Batory et al. 2003]. This is seen in theseparation between an activity’s template and its instances, and use of specializationfor creating application-specific components from their generic counterparts. Thereare two aspects in which our generative middleware differs from the above men-tioned systems. First, unlike the program generator system of [Smaragdakis et al.2004], our middleware is an application generator. The output of the instantiationphase is a running application in which the components may bind to differentunderlying services under different context conditions. Second, we use policies forthe purpose of specialization of generic components. One advantage of this policy-based approach is that policies precisely characterize the variation points in thegeneric components.

Component integration models: Our approach for construction of context-basedcollaboration systems can be compared to component integration models such asJava Beans [Banavar et al. 1998], and service integration models such as BPEL[Chakraborty and Lei 2004]. Though component integration models, as in [Banavaret al. 1998], support auto generation of applications, due to the lack of a higher-level specification model, without custom coding, they cannot support differentcoordination policies for participants and access control policies on resources andcontext services. In [Chakraborty and Lei 2004], separation of specification from itsrealization of context-based business processes are achieved through an extensionof BPEL. However these are limited to business transactions.

7. FUTURE WORK

There are several aspects of this work where further investigation can help inmaking this framework more practical. One direction is generation of tests for anapplication from its activity specification. In the literature two broad approacheshave 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-awareapplication’s code that are affected by context information, and generating teststhat exercise all possible control and data flows involving these special points. Ahigh-level specification model such as ours can be helpful in identifying these specialprogram points and generating the corresponding tests. For instance, consider theCurrentWard object (Figure 6). A control-flow test for the BindCurrentWard reac-tion consists of testing that when the UserArrivalEvent is generated the discovery-based binding action is executed. A data-flow test consists of testing that the



UserArrivalEvent being utilized in the reaction’s discovery-based binding actionis same as the one that triggered the reaction. We envision that an activity’sspecification can be used to generate such tests.

Another direction in which our work can be extended is verification of context-based properties of context-aware applications using model checking techniques.Verification can help in designing correct specifications for context-aware applica-tions. In our previous work [Ahmed and Tripathi 2007] we have used model checkingfor verifying the security, coordination, and information-flow properties of CSCWapplications. Those techniques can be extended to verify contextual propertiessuch 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-levelprogramming approaches such as ours can be made usable for persons who arenot traditional programmers. This is important as the application domains encom-passed by context-aware pervasive computing tend to involve a variety of users someof whom may not have software engineering background. For such users, it shouldbe possible to design and build active-space applications for their specific needs.The domain-specific high-level programming framework presented here, howsoeverhelpful, could still be a barrier to such users as it requires a designer to understandconcepts such as roles, events, binding, and access-control, necessarily the purviewof only those with a traditional software engineering background. Thus, there cer-tainly exists a need to build systems that can further lower the barrier of developingactive-space applications. This problem falls under the broader scope of makingprogramming tasks approachable to non-programmers. In this regard certain usergroups such as teens and artists have received attention by researchers. Systemssuch as Scratch [Resnick et al. 2009] and OpenFrameworks [OpenFrameworks ] havebeen created for these communities. It remains to be seen if such approaches canbe developed for designing active-space applications.

8. CONCLUSIONS

In this paper we have presented the architecture of a programming framework forbuilding context-aware CSCW applications using generative programming tech-niques. The execution environment of a context-aware application is generatedfrom its domain-specific design model. This design model provides mechanismsfor context-based dynamic binding of application objects to ambient services, andintegrates context-based access control and coordination mechanisms in a role-basedmodel. A policy-driven middleware is used for generating the distributed executionenvironment of an application. For this purpose a set of generic components arespecialized using policy modules that are derived from an application’s designspecification. These policy modules are related to dynamic binding of objects,role-based access control, and event communication. In this paper a case-studyapplication is used to demonstrate this design model and the architecture of thegenerative middleware. We have implemented a number of context-aware appli-cations in our testbed environment to evaluate and demonstrate the capabilitiesof this system. The results of our evaluations demonstrate the benefits of using



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 Informationand System Security (TISSEC) 10, 2, 7.

Banavar, G., Doddapaneni, S., Miller, K., and Mukherjee, B. 1998. Rapidly BuildingSynchronous 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 Real-World 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. InICSE ’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 andCoordination: 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 InternationalConference on Generative Programming and Component Engineering, (GPCE’09), 137–146.

Ceri, S. and Widom, J. 1990. Deriving Production Rules for Constraint Maintenance. InProceedings of the Sixteenth International Conference on Very Large Databases. 566–577.

Chakraborty, D. and Lei, H. 2004. Pervasive Enablement of Business Processes. In SecondIEEE 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 DescribingCollaborative 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 aToolkit 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.

Evered, M. and Bogeholz, S. 2004. A Case Study in Access Control Requirements for aHealth Information System. In ACSW Frontiers ’04: Proceedings of the Second Workshop

on Australasian Information Security, Data Mining and Web Intelligence, and SoftwareInternationalisation. 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. IEEEPervasive Computing 1, 2, 13–21.



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 PervasiveApplications. 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 andCommunications, PERCOM’04. 77–86.

Jones, A. K. and Liskov, B. H. 1978. A Language Extension for Expressing Constraints onData 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 PervasiveComputing and Communications, PERCOM’03. 133–142.

Julien, C. and Roman, G.-C. 2006. EgoSpaces: Facilitating Rapid Development of Context-Aware 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 AdaptationFramework. In POLICY ’03: Proceedings of the 4th IEEE International Workshop on Policiesfor Distributed Systems and Networks. IEEE Computer Society, Washington, DC, USA, 3–14.

Kulkarni, D. 2009. Mechanisms for Access Control and Application-level Recovery in Context-Aware 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 Workshopon 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 Context-Aware 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 PervasiveComputing Systems. In Proceedings of the 13th ACM Symposium on Access control Modelsand 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. InProceedings 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. Springer-Verlag, London, UK, 137–153.

Malone, T. W. and Crowston, K. 1994. The Interdisciplinary Study of Coordination. ACMComputing Surveys (CSUR) 26, 1 (March), 87 – 119.



Nutt, G. J. 1996. The Evolution towards Flexible Workflow Systems. Distributed SystemsEngineering 3, 276–294.

OpenFrameworks. http://www.openframeworks.cc/. Available at URLhttp://www.openframeworks.cc/.

Poladian, V., Pedro, S. J., Garlan, D., Schmerl, B., and Shaw, M. 2006. Task-BasedAdaptation 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. SpringerBerlin / 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 andCommunications, PERCOM ’05. 7–16.

Resnick, M., Maloney, J., Monroy-Hernandez, A., Rusk, N., Eastmond, E., Brennan, K.,Millner, A., Rosenbaum, E., Silver, J., Silverman, B., and Kafai, Y. 2009. Scratch:

Programming for All. Commun. ACM 52, 11, 60–67.

Roman, M., Hess, C. K., Cerqueira, R., Ranganathan, A., Campbell, R. H., and Nahrstedt,

K. 2002. Gaia: A Middleware Platform for Active Spaces. Mobile Computing andCommunications Review 6, 4, 65–67.

Sampemane, G., Naldurg, P., and Campbell, R. H. 2002. Access control for Active Spaces. InAnnual Computer Security Applications Conference (ACSAC2002).

Sandhu, R., Coyne, E., Feinstein, H., and Youman, C. 1996. Role-Based Access ControlModels. IEEE Computer 29, 2 (February), 38–47.

Schilit, B., Adams, N., and Want, R. 1994. Context-Aware Computing Applications. In IEEEWorkshop 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 tomake them. In PEPM ’04: Proceedings of the 2004 ACM SIGPLAN Symposium on PartialEvaluation and Semantics-based Program Manipulation. ACM, New York, NY, USA, 92–100.

Tripathi, A. 2002. Adaptive Middleware: Challenges Designing Next-Generation MiddlewareSystems. CACM 45, 6 (June), 39–42.

Tripathi, A., Ahmed, T., Kumar, R., and Jaman, S. 2002. Design of a Policy-Driven Middlewarefor Secure Distributed Collaboration. In Proceedings of International Conference on DistributedComputing Systems 2002. 393 – 400.

Tripathi, A., Kulkarni, D., and Ahmed, T. 2005. A Specification Model for Context-BasedCollaborative Applications. Elsevier Journal on Pervasive and Mobile Computing 1, 1 (May-

June), 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 EventMonitoring System. Software - Practice & Experience 37, 5, 493–522.

Wang, Z., Elbaum, S., and Rosenblum, D. S. 2007. Automated Generation of Context-AwareTests. 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 Context-

Sensitive 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 KnowledgeEngineering, SEKE’03.


A Generative Programming Framework for Context-Aware CSCW Applications

Documents

Transcript of A Generative Programming Framework for Context-Aware CSCW Applications