A survey about context-aware middleware

Context-Aware Middleware Argomenti avanzati di Ingegneria del Software – 1

CONTEXT-AWARE MIDDLEWARE

Marco Bessi Leonardo Bruni

June 16, 2009

Outline

Introduction

Possible approaches


IntroductionMiddlewareTraditional MWNew Generation MWIs it necessary?RequirementsProblems

Possible approachesClassificationObject orientedOntology orientedData oriented

Introduction

Introduction

❖ Middleware

❖ Traditional MW

❖ New Generation MW

❖ Is it necessary?

❖ Requirements

❖ Problems

Possible approaches


Middleware

Introduction

❖ Middleware

❖ Traditional MW



❖ Requirements

❖ Problems

Possible approaches


“Middleware is an enabling layer of software that resides betweenthe application program and the networked layer of heterogeneousplatforms and protocols. It decouples applications from anydependencies on the plumbing layer that consists ofheterogeneous operating systems, hardware platforms andcommunication protocols. (Source: Davis Linthicum)”

From Traditional Middleware ...

Introduction

❖ Middleware

❖ Traditional MW



❖ Requirements

❖ Problems

Possible approaches


Existing middleware technologies have been built adhering to the metaphor ofthe Black Box.

It provides:

● communication and coordination services;

● special application services;

● management services.

Traditional distributed system assume a stationary execution environment thatcontrast with the extremely dynamic scenario of the context-aware computing.

... to New Generation Middleware

Introduction

❖ Middleware

❖ Traditional MW



❖ Requirements

❖ Problems

Possible approaches


Modern distributed applications need a middleware that is capable of adaptingto environment changes and that supports the required level of quality ofservice.

Context-awareness involves:

● acquisition of contextual information;

● reasoning about context ;

● modifying ones behavior based on the current context.

It would define a common model of context.

It would also ensure that different agents in the environment have a commonsemantic understanding of contextual information.

Is it necessary?

Introduction

❖ Middleware

❖ Traditional MW



❖ Requirements

❖ Problems

Possible approaches


● it simplify the task of creating and maintaining context-aware systems;

● it provide uniform abstraction and reliable service for common application;

● it make it easy to incrementally deploy new sensors and context-awareagents in the environment;

● it would be independent of hardware, operating system and programminglanguage.

Requirements [1]

Introduction

❖ Middleware

❖ Traditional MW



❖ Requirements

❖ Problems

Possible approaches


Some requirements different from traditional middleware have to be consideredfor the context-aware scenario.

● support for heterogeneity: hardware components ranging fromresource-poor sensors, actuators and mobile client devices tohigh-performance servers must be supported, as must a variety ofnetworking interfaces and programming language;

● support for mobility: all components can be mobile, and thecommunication protocols must therefore support appropriately flexibleforms of routing; context information may need to migrate withcontext-aware components;

● scalability: context processing components and communication protocolmust perform adequately in very changing domains;

● support for privacy: flows of context information between the distributedcomponents of a context-aware system must be controlling according touser’s privacy needs and expectations;

Requirements [2]

Introduction

❖ Middleware

❖ Traditional MW



❖ Requirements

❖ Problems

Possible approaches


● tolerance for component failures: sensors are likely to fail in theordinary operation of a context-aware system; disconnection may alsooccur;

● ease of deployment and configuration: it must be easily deployed andconfigured to meet user and environmental requirements;

● dynamic reconfiguration: detecting changes in available resources andreallocating them or notify the application to change its behavior;

● asynchronous paradigm: decoupling the client and server componentsand delivering multicast messages.

Problems [1]

Introduction

❖ Middleware

❖ Traditional MW



❖ Requirements

❖ Problems

Possible approaches


Balance of user controlContext-aware applications:

● not only require middleware for distribution transparency of components;

● but also support personalization and adaptation based oncontext-awareness.

But, context-aware applications may not always adapt as the user expects, andmay cause users to feel loss of control over the behavior of their applications.

Autonomous context-aware systems must provide mechanisms to strike asuitable balance between user control and software autonomy.

Problems [2]: Conflicts

Introduction

❖ Middleware

❖ Traditional MW



❖ Requirements

❖ Problems

Possible approaches


A context-aware system may modify its own behavior by means of adaptation.

Applications may introduce ambiguities, contradictions or other logicalinconsistencies.

Typologies:

● intra-profile conflict: a conflict exist inside the profile of an applicationrunning on a particular device; it is local to a middleware instance;

● inter-profile conflict: a conflict exist between the profiles of applicationsrunning on different devices; it is distributed among various middlewareinstances.

Conflict resolution mechanismWhenever a service that incorporates a conflict is requested,a conflictresolution mechanism has to be run to solve the conflict and find out whichpolicy to use to deliver the service.

Possible approaches

Introduction

Possible approaches

❖ Classification

❖ Object oriented

❖ Ontology oriented

❖ Data oriented


Classification

Introduction

Possible approaches

❖ Classification

❖ Object oriented


❖ Data oriented


● Object-oriented middleware:

✦ Reflection and reflective middleware;

✦ Meta-space, meta-model, meta-object.

● Ontology-oriented middleware:

✦ SOCAM: ontology, architecture, performance.

● Data-oriented middleware:

✦ Publish-subscribe: adding context, API, SPCF protocol;

✦ TOTA: tuples, architecture, API.

Background on reflection

Introduction

Possible approaches

❖ Classification

❖ Object oriented


❖ Data oriented


A reflection system is one that is capable of reasoning about itself (besidesreasoning about the application domain).

● In a reflective system, we call

base-level the part of the system that perform processing about theapplication domain as in conventional systems;

meta-level the part of the system whose subject of computation is thesystem’s self representation;

meta-object the entities that populate the meta-level.

● Two styles of reflection

procedural: the representation of the system is a program that isgenerally written in the same language of the system;

declarative: uses a set of declarative statements as a representation ofthe system.

Reflective middleware: introduction

Introduction

Possible approaches

❖ Classification

❖ Object oriented


❖ Data oriented


● language independent reflective architecture1 featuring:

✦ a per object meta-space;

✦ the use of meta-model to structure meta-spaces;

✦ the use of object graphs for composite components.

● focus on:

✦ configuration;

✦ reconfiguration;

✦ extension.

1F. M. Costa, H. A. Duran, N. Parlavantzas, K. B. Saikoski, G. Blair, G. Coulson: Lancaster University

General principles

Introduction

Possible approaches

❖ Classification

❖ Object oriented


❖ Data oriented


● use of the CORBA IDL to describe computational interface

✦ object can have multiple interfaces

✦ three kinds of interfaces supported: operational, stream and signal

✦ explicit bindings (local or distributed) can be created betweencompatible interfaces

● use of procedural reflection

● meta-spaces support objects on a per object (or per interface) basis

✦ a fine level of control can be obtained

✦ enforces consistency

● the meta-space is structured as a set of four orthogonal meta-models

✦ simplifies the meta-interface by maintaining a separation of concernbetween different system aspects

✦ other meta-models can be defined

The structure of meta-space

Introduction

Possible approaches

❖ Classification

❖ Object oriented


❖ Data oriented


Encapsulation meta-model

Introduction

Possible approaches

❖ Classification

❖ Object oriented


❖ Data oriented


The encapsulation meta-model relates to the set of methods and associatedattributes of a particular object interface.

Compositional meta-model

Introduction

Possible approaches

❖ Classification

❖ Object oriented


❖ Data oriented


The compositional meta-model deals with the way a composite object iscomposed, i.e. how its components are inter-connected, and how theseconnection are manipulated. The composition of an object is represented as anobject graph.

Environment meta-object

Introduction

Possible approaches

❖ Classification

❖ Object oriented


❖ Data oriented


The environment meta-object is in charge of the environmental computation ofan object interface, i.e. how the computation is done. It deals with messagearrivals, dispatching, marshalling, concurrency control, etc.

Resource meta-model

Introduction

Possible approaches

❖ Classification

❖ Object oriented


❖ Data oriented


The resource meta-model is concerned with both the resource awareness andresource management of objects in the platform. Resource provide anoperating system independent view of threads, buffer, etc. Resource aremanaged by resource managers, which map higher level abstraction ofresource onto lower ones.

Performance evaluation

Introduction

Possible approaches

❖ Classification

❖ Object oriented


❖ Data oriented


Ontology oriented

Introduction

Possible approaches

❖ Classification

❖ Object oriented


❖ Data oriented


● Ontology

✦ formal explicit description of concepts in a domain of discourse

✦ provides a vocabulary for representing knowledge and fordescribing specific situation

● OWL (Web Ontology Language)

✦ is an Open W3C standard

✦ is much expressive than other languages such as RDFS

● First-order predicate calculus

✦ basic form: Predicate(Subject, Value)

✦ e.g.: Location(Tom, bathroom) ; Status(Door, closed)

✦ possible to combine the predicate and Boolean algebra

✦ e.g.: FoodPreference(FamilyMembers, foodItems) ≡FoodPreference(Tom, FoodList1) ∨ FoodPreference(Alice,FoodList2)

Representation of context

Introduction

Possible approaches

❖ Classification

❖ Object oriented


❖ Data oriented



Introduction

Possible approaches

❖ Classification

❖ Object oriented


❖ Data oriented


raw data


Introduction

Possible approaches

❖ Classification

❖ Object oriented


❖ Data oriented


raw data

ID = John, Activity = lie down, Place = bed


Introduction

Possible approaches

❖ Classification

❖ Object oriented


❖ Data oriented


raw data

ID = John, Activity = lie down, Place = bed

(John,has posture,lie-down) (John,location,bed)

Advantages of an ontology-based approach

Introduction

Possible approaches

❖ Classification

❖ Object oriented


❖ Data oriented


● describes context semantically in a way which is independent ofprogramming language or underlying operating system

● enables formal analysis of domain knowledge

● takes in account the following characteristics of context information:

✦ context information has a great variety

✦ context information varies in different sub-domains

✦ context information is interrelated

✦ context information inconsistent

● shares common understanding of the structure of context information

● enables reuse of domain knowledge

SOCAM

Introduction

Possible approaches

❖ Classification

❖ Object oriented


❖ Data oriented


● SOCAM2: Service-Oriented Context-Aware Middleware

✦ an architecture for the building and rapid prototyping ofcontext-aware services

✦ it provides support for

■ acquiring■ discovering■ interpreting■ accessing

various contexts to build context-aware services

✦ it’s a distributed middleware

2Tao Gu, Hung Keng Pung, Da Qing Zhang: University of Singapore

SOCAM: Design of context ontology

Introduction

Possible approaches

❖ Classification

❖ Object oriented


❖ Data oriented


● two-layer hierarchical approach

Common upper ontology: it captures general concepts

Domain-specific ontology: it’s a collection of low-level ontologies whichapply to different sub-domains

SOCAM: Context classification

Introduction

Possible approaches

❖ Classification

❖ Object oriented


❖ Data oriented


● two main categories

direct context: directly acquired or obtained from a context provider

sensed context: acquired from physical sensordefined context: defined by a user

indirect context: derived by interpreting direct context through contextreasoning

SOCAM: Architecture

Introduction

Possible approaches

❖ Classification

❖ Object oriented


❖ Data oriented


SOCAM: Performance evaluation

Introduction

Possible approaches

❖ Classification

❖ Object oriented


❖ Data oriented


Publish-Subscribe: Why add context? [1]

Introduction

Possible approaches

❖ Classification

❖ Object oriented


❖ Data oriented


Complex communication pattern need to take into account the situation in whichthe information to be communicated is produced or consumed.

To convey this information into the published messages, Publish-Subscribe (andits content-based incarnation) encode the “context” of the publisher into themessages.

This approach is limiting and inefficient.

Publish-Subscribe: Why add context? [2]

Introduction

Possible approaches

❖ Classification

❖ Object oriented


❖ Data oriented


Matching inversionConventional content-based publish-subscribe system:

● messages hold data, subscriptions hold constraints on these data;

● the data model and the matching semantics are unsuited for this case.

Necessity to invert the conventional matching process to consider constraintsembedded into messages and data embedded into subscriptions.

Efficiency

● Reduce the overhead of the subscription and unsubscription processes(saving bandwidth);

● Reduce the time required to match messages.

Separation of concernsComponents in charge of publishing messages and subscribing to them differfrom those in charge to detecting and communicating context change.

Publish-Subscribe: API

Introduction

Possible approaches

❖ Classification

❖ Object oriented


❖ Data oriented


Each node n can3:

● set its current context by invoking the setContext(c) operation;

● subscribe to messages matching the content filter fmsg and coming frompublishers whose context matches the context filter fctx through thesubscribe( fmsg; fctx); the unsubscribe( fmsg ; fctx) operation does theopposite;

● publish messages for subscribers whose context matches the contextfilter fctx by invoking the publish(m; fctx) operation.

3G. Cugola, A. Margara: Politecnico di Milano; M. Migliavacca: Imperial College London

Publish-Subscribe: Shortest Path Context Forwarding(SPCF) protocol

Introduction

Possible approaches

❖ Classification

❖ Object oriented


❖ Data oriented


Messages are forwarded along the shortest path tree rooted at the publisher,using information about context and interests of downstream clients to decidethe branches to follow and those to prune.

● Each broker runs a link state protocol to built its own view of thedispatching network (without the client) and calculate the shortest pathtrees (SPT) rooted to each broker in the network;

● Message forwarding uses these trees together with two tables (which arekept by each broker):

✦ context table: it maps brokers (identifier) to the set of contexts oftheir clients;

✦ content table: it stores, for each broker Bp, each context cp amongthose of the clients attached to Bp, and each neighbor N, the set ofcontent filters and contexts coming from attached to brokers thatare downstream along N in the SPT rooted at Bp.

Tuples On The Air (TOTA): Approach

Introduction

Possible approaches

❖ Classification

❖ Object oriented


❖ Data oriented


The key objectives of TOTA 4 are:

● promotes decoupled and adaptive interactions by providing applicationcomponents with simple and expressive context information;

● actively support adaptivity by discharging application components fromduty of dealing with network and application dynamics.

Relies on “spatially distributed tuples”.

TOTA adds and updates information in these tuples to reflect context andconnectivity. Agents “sense” these tuples to get context information and tocommunicate.

4M. Mamei, F. Zambonelli, L. Leonardi: Universit di Modena e Reggio Emilia

TOTA: Overview

Introduction

Possible approaches

❖ Classification

❖ Object oriented


❖ Data oriented


Distributed tuples used to represent context and to support communication;

● Tuples are not associated with a node;

● Tuples autonomously propagate and diffuse through the network.

Computational model

● Peer-to-peer network;

● Nodes may be mobile and have a neighborhood;

● Each agent can store tuples and “lets” tuples diffuse through network.

TOTA tuples and propagation rule

Introduction

Possible approaches

❖ Classification

❖ Object oriented


❖ Data oriented


TOTA tuples

● Injected into the system from a particular node;

● Defined by “content” and “propagation rule” T = (C, P );

✦ C is an ordered set of typed fields representing the informationcarried on by the tuple;

✦ P determines how tuple is distributed and propagated in thenetwork.

Propagation rule

● Determines scope of the tuple (i.e. distance at which such tuple shouldbe propagated);

● Evaluated at each hop;

✦ Determines how the tuples content may be changed;✦ Determines how propagation may be affected by presence/absence

of other tuples.

TOTA: Architecture [1]

Introduction

Possible approaches

❖ Classification

❖ Object oriented


❖ Data oriented


TOTA: Architecture [2]

Introduction

Possible approaches

❖ Classification

❖ Object oriented


❖ Data oriented


The TOTA middleware is constituted by three main parts:

● TOTA API: it is the main interface between the application and themiddleware;

● Event interface:

✦ it is the component in charge of asynchronously notifying theapplication about the income of a new tuple or about the fact a newnode has been connected/disconnected to the node’sneighborhood;

● TOTA engine: the core of TOTA

✦ it is in charge of maintaining the TOTA network by storing thereferences to neighboring nodes and to manage tuple’s propagationby opening communication socket to send and receive tuples.

TOTA: API

Introduction

Possible approaches

❖ Classification

❖ Object oriented


❖ Data oriented


● void inject(Tuple t) : it is used to inject the tuple passed as an argumentin the TOTA network;

● ArrayList read(Tuple t) : it returns a collection of tuples locally present inthe tuple space and matching the template passed as parameter;

● ArrayList delete(Tuple t) : it extract from the local middleware all thetuples matching the template and return them to the invoking component;

● void subscribe(Tuple t, String reaction) : it associates the execution ofa reaction method in the component in response to the occurrence ofevents matching the template tuple passed as first parameter;

● void unsubscribe(Tuple t, String reaction) : it removes matchingsubscriptions.

The end

Introduction

Possible approaches

The end


A survey about context-aware middleware

Technology

Transcript of A survey about context-aware middleware