Context-aware systems represent extremely complex and heterogeneous systems. The need for middleware to bind components together is well recognized and many attempts to build middleware for context-aware systems have been made. We provide a general introduction about the evolution of the middlewares and then we proceed with an analysis of the requirements and the issues for context-aware middleware.

1. CONTEXT-AWARE MIDDLEWARE
Marco Bessi Leonardo Bruni
June 16, 2009
Context-Aware Middleware Argomenti avanzati di Ingegneria del Software – 1

2. Outline
Introduction
Introduction
Possible approaches
Middleware
Traditional MW
New Generation MW
Is it necessary?
Requirements
Problems
Possible approaches
Classification
Object oriented
Ontology oriented
Data oriented
Context-Aware Middleware Argomenti avanzati di Ingegneria del Software – 2

3. Introduction
y Middleware
y Traditional MW
y New Generation MW
y Is it necessary?
y Requirements
y Problems
Possible approaches
Introduction
Context-Aware Middleware Argomenti avanzati di Ingegneria del Software – 3

4. Middleware
Introduction
y Middleware
y Traditional MW
y New Generation MW
y Is it necessary?
y Requirements
y Problems
Possible approaches
“Middleware is an enabling layer of software that resides between
the application program and the networked layer of heterogeneous
platforms and protocols. It decouples applications from any
dependencies on the plumbing layer that consists of
heterogeneous operating systems, hardware platforms and
communication protocols. (Source: Davis Linthicum)”
Context-Aware Middleware Argomenti avanzati di Ingegneria del Software – 4

5. From Traditional Middleware ...
Introduction
Existing middleware technologies have been built adhering to the metaphor of
y Middleware
y Traditional MW the Black Box.
y New Generation MW
y Is it necessary?
It provides:
y Requirements
q communication and coordination services;
y Problems
Possible approaches q special application services;
q management services.
Traditional distributed system assume a stationary execution environment that
contrast with the extremely dynamic scenario of the context-aware computing.
Context-Aware Middleware Argomenti avanzati di Ingegneria del Software – 5

6. ... to New Generation Middleware
Introduction
Modern distributed applications need a middleware that is capable of adapting
y Middleware
y Traditional MW to environment changes and that supports the required level of quality of
y New Generation MW service.
y Is it necessary?
y Requirements Context-awareness involves:
y Problems
q acquisition of contextual information;
Possible approaches
q reasoning about context;
q 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 common
semantic understanding of contextual information.
Context-Aware Middleware Argomenti avanzati di Ingegneria del Software – 6

7. Is it necessary?
Introduction
y Middleware q it simplify the task of creating and maintaining context-aware systems;
y Traditional MW
y New Generation MW
q it provide uniform abstraction and reliable service for common application;
y Is it necessary? q it make it easy to incrementally deploy new sensors and context-aware
y Requirements
y Problems
agents in the environment;
Possible approaches q it would be independent of hardware, operating system and programming
language.
Context-Aware Middleware Argomenti avanzati di Ingegneria del Software – 7

8. Requirements [1]
Introduction
Some requirements different from traditional middleware have to be considered
y Middleware
y Traditional MW for the context-aware scenario.
y New Generation MW
y Is it necessary? q support for heterogeneity: hardware components ranging from
y Requirements resource-poor sensors, actuators and mobile client devices to
y Problems
high-performance servers must be supported, as must a variety of
Possible approaches
networking interfaces and programming language;
q support for mobility: all components can be mobile, and the
communication protocols must therefore support appropriately flexible
forms of routing; context information may need to migrate with
context-aware components;
q scalability: context processing components and communication protocol
must perform adequately in very changing domains;
q support for privacy: flows of context information between the distributed
components of a context-aware system must be controlling according to
user’s privacy needs and expectations;
Context-Aware Middleware Argomenti avanzati di Ingegneria del Software – 8

9. Requirements [2]
Introduction
y Middleware q tolerance for component failures: sensors are likely to fail in the
y Traditional MW ordinary operation of a context-aware system; disconnection may also
y New Generation MW
y Is it necessary?
occur;
y Requirements q ease of deployment and configuration: it must be easily deployed and
y Problems
configured to meet user and environmental requirements;
Possible approaches
q dynamic reconfiguration: detecting changes in available resources and
reallocating them or notify the application to change its behavior;
q asynchronous paradigm: decoupling the client and server components
and delivering multicast messages.
Context-Aware Middleware Argomenti avanzati di Ingegneria del Software – 9

10. Problems [1]
Introduction
Balance of user control
y Middleware
y Traditional MW Context-aware applications:
y New Generation MW
y Is it necessary? q not only require middleware for distribution transparency of components;
y Requirements
y Problems q but also support personalization and adaptation based on
Possible approaches context-awareness.
But, context-aware applications may not always adapt as the user expects, and
may cause users to feel loss of control over the behavior of their applications.
Autonomous context-aware systems must provide mechanisms to strike a
suitable balance between user control and software autonomy.
Context-Aware Middleware Argomenti avanzati di Ingegneria del Software – 10

11. Problems [2]: Conflicts
Introduction
A context-aware system may modify its own behavior by means of adaptation.
y Middleware
y Traditional MW
Applications may introduce ambiguities, contradictions or other logical
y New Generation MW
y Is it necessary?
inconsistencies.
y Requirements
y Problems
Typologies:
Possible approaches q intra-profile conflict: a conflict exist inside the profile of an application
running on a particular device; it is local to a middleware instance;
q inter-profile conflict: a conflict exist between the profiles of applications
running on different devices; it is distributed among various middleware
instances.
Conflict resolution mechanism
Whenever a service that incorporates a conflict is requested,a conflict
resolution mechanism has to be run to solve the conflict and find out which
policy to use to deliver the service.
Context-Aware Middleware Argomenti avanzati di Ingegneria del Software – 11

12. Introduction
Possible approaches
y Classification
y Object oriented
y Ontology oriented
y Data oriented
Possible approaches
Context-Aware Middleware Argomenti avanzati di Ingegneria del Software – 12

13. Classification
Introduction
Possible approaches
q Object-oriented middleware:
y Classification
y Object oriented 3 Reflection and reflective middleware;
y Ontology oriented
y Data oriented
3 Meta-space, meta-model, meta-object.
q Ontology-oriented middleware:
3 SOCAM: ontology, architecture, performance.
q Data-oriented middleware:
3 Publish-subscribe: adding context, API, SPCF protocol;
3 TOTA: tuples, architecture, API.
Context-Aware Middleware Argomenti avanzati di Ingegneria del Software – 13

14. Background on reflection
Introduction
A reflection system is one that is capable of reasoning about itself (besides
Possible approaches
reasoning about the application domain).
y Classification
y Object oriented
q In a reflective system, we call
y Ontology oriented
y Data oriented
base-level the part of the system that perform processing about the
application domain as in conventional systems;
meta-level the part of the system whose subject of computation is the
system’s self representation;
meta-object the entities that populate the meta-level.
q Two styles of reflection
procedural: the representation of the system is a program that is
generally written in the same language of the system;
declarative: uses a set of declarative statements as a representation of
the system.
Context-Aware Middleware Argomenti avanzati di Ingegneria del Software – 14

15. Reflective middleware: introduction
Introduction
Possible approaches
q language independent reflective architecture1 featuring:
y Classification
y Object oriented 3 a per object meta-space;
y Ontology oriented
y Data oriented 3 the use of meta-model to structure meta-spaces;
3 the use of object graphs for composite components.
q focus on:
3 configuration;
3 reconfiguration;
3 extension.
1
F. M. Costa, H. A. Duran, N. Parlavantzas, K. B. Saikoski, G. Blair, G. Coulson: Lancaster University
Context-Aware Middleware Argomenti avanzati di Ingegneria del Software – 15

16. General principles
Introduction
Possible approaches
q use of the CORBA IDL to describe computational interface
y Classification
y Object oriented 3 object can have multiple interfaces
y Ontology oriented
y Data oriented
3 three kinds of interfaces supported: operational, stream and signal
3 explicit bindings (local or distributed) can be created between
compatible interfaces
q use of procedural reflection
q meta-spaces support objects on a per object (or per interface) basis
3 a fine level of control can be obtained
3 enforces consistency
q the meta-space is structured as a set of four orthogonal meta-models
3 simplifies the meta-interface by maintaining a separation of concern
between different system aspects
3 other meta-models can be defined
Context-Aware Middleware Argomenti avanzati di Ingegneria del Software – 16

17. The structure of meta-space
Introduction
Possible approaches
y Classification
y Object oriented
y Ontology oriented
y Data oriented
Context-Aware Middleware Argomenti avanzati di Ingegneria del Software – 17

18. Encapsulation meta-model
Introduction
The encapsulation meta-model relates to the set of methods and associated
Possible approaches
attributes of a particular object interface.
y Classification
y Object oriented
y Ontology oriented
y Data oriented
Context-Aware Middleware Argomenti avanzati di Ingegneria del Software – 18

19. Compositional meta-model
Introduction
The compositional meta-model deals with the way a composite object is
Possible approaches
composed, i.e. how its components are inter-connected, and how these
y Classification
y Object oriented
connection are manipulated. The composition of an object is represented as an
y Ontology oriented object graph.
y Data oriented
Context-Aware Middleware Argomenti avanzati di Ingegneria del Software – 19

20. Environment meta-object
Introduction
The environment meta-object is in charge of the environmental computation of
Possible approaches
an object interface, i.e. how the computation is done. It deals with message
y Classification
y Object oriented
arrivals, dispatching, marshalling, concurrency control, etc.
y Ontology oriented
y Data oriented
Context-Aware Middleware Argomenti avanzati di Ingegneria del Software – 20

21. Resource meta-model
Introduction
The resource meta-model is concerned with both the resource awareness and
Possible approaches
resource management of objects in the platform. Resource provide an
y Classification
y Object oriented
operating system independent view of threads, buffer, etc. Resource are
y Ontology oriented managed by resource managers, which map higher level abstraction of
y Data oriented
resource onto lower ones.
Context-Aware Middleware Argomenti avanzati di Ingegneria del Software – 21

22. Performance evaluation
Introduction
Possible approaches
y Classification
y Object oriented
y Ontology oriented
y Data oriented
Context-Aware Middleware Argomenti avanzati di Ingegneria del Software – 22

23. Ontology oriented
Introduction
Possible approaches
q Ontology
y Classification
y Object oriented 3 formal explicit description of concepts in a domain of discourse
y Ontology oriented
y Data oriented
3 provides a vocabulary for representing knowledge and for
describing specific situation
q OWL (Web Ontology Language)
3 is an Open W3C standard
3 is much expressive than other languages such as RDFS
q First-order predicate calculus
3 basic form: Predicate(Subject, Value)
3 e.g.: Location(Tom, bathroom) ; Status(Door, closed)
3 possible to combine the predicate and Boolean algebra
3 e.g.: FoodPreference(FamilyMembers, foodItems) ≡
FoodPreference(Tom, FoodList1) ∨ FoodPreference(Alice,
FoodList2)
Context-Aware Middleware Argomenti avanzati di Ingegneria del Software – 23

24. Representation of context
Introduction
Possible approaches
y Classification
y Object oriented
y Ontology oriented
y Data oriented
Context-Aware Middleware Argomenti avanzati di Ingegneria del Software – 24

25. Representation of context
Introduction
Possible approaches
y Classification
y Object oriented
y Ontology oriented
y Data oriented
raw data
Context-Aware Middleware Argomenti avanzati di Ingegneria del Software – 24

26. Representation of context
Introduction
Possible approaches
y Classification
y Object oriented
y Ontology oriented
y Data oriented
raw data
ID = John, Activity = lie down, Place = bed
Context-Aware Middleware Argomenti avanzati di Ingegneria del Software – 24

27. Representation of context
Introduction
Possible approaches
y Classification
y Object oriented
y Ontology oriented
y Data oriented
(John,has posture,lie-down) (John,location,bed)
raw data
ID = John, Activity = lie down, Place = bed
Context-Aware Middleware Argomenti avanzati di Ingegneria del Software – 24

28. Representation of context
Introduction
Possible approaches
y Classification
y Object oriented
y Ontology oriented
y Data oriented
(John,has posture,lie-down) (John,location,bed)
raw data
ID = John, Activity = lie down, Place = bed
Context-Aware Middleware Argomenti avanzati di Ingegneria del Software – 24

29. Advantages of an ontology-based approach
Introduction
Possible approaches
q describes context semantically in a way which is independent of
y Classification programming language or underlying operating system
y Object oriented
y Ontology oriented q enables formal analysis of domain knowledge
y Data oriented
q takes in account the following characteristics of context information:
3 context information has a great variety
3 context information varies in different sub-domains
3 context information is interrelated
3 context information inconsistent
q shares common understanding of the structure of context information
q enables reuse of domain knowledge
Context-Aware Middleware Argomenti avanzati di Ingegneria del Software – 25

30. SOCAM
Introduction
Possible approaches
q SOCAM2 : Service-Oriented Context-Aware Middleware
y Classification
y Object oriented 3 an architecture for the building and rapid prototyping of
y Ontology oriented
context-aware services
y Data oriented
3 it provides support for
s acquiring
s discovering
s interpreting
s accessing
various contexts to build context-aware services
3 it’s a distributed middleware
2
Tao Gu, Hung Keng Pung, Da Qing Zhang: University of Singapore
Context-Aware Middleware Argomenti avanzati di Ingegneria del Software – 26

31. SOCAM: Design of context ontology
Introduction
Possible approaches
q two-layer hierarchical approach
y Classification
y Object oriented Common upper ontology: it captures general concepts
y Ontology oriented
y Data oriented
Domain-specific ontology: it’s a collection of low-level ontologies which
apply to different sub-domains
Context-Aware Middleware Argomenti avanzati di Ingegneria del Software – 27

32. SOCAM: Context classification
Introduction
Possible approaches
q two main categories
y Classification
y Object oriented direct context: directly acquired or obtained from a context provider
y Ontology oriented
y Data oriented
sensed context: acquired from physical sensor
defined context: defined by a user
indirect context: derived by interpreting direct context through context
reasoning
Context-Aware Middleware Argomenti avanzati di Ingegneria del Software – 28

33. SOCAM: Architecture
Introduction
Possible approaches
y Classification
y Object oriented
y Ontology oriented
y Data oriented
Context-Aware Middleware Argomenti avanzati di Ingegneria del Software – 29

34. SOCAM: Performance evaluation
Introduction
Possible approaches
y Classification
y Object oriented
y Ontology oriented
y Data oriented
Context-Aware Middleware Argomenti avanzati di Ingegneria del Software – 30

35. Publish-Subscribe: Why add context? [1]
Introduction
Complex communication pattern need to take into account the situation in which
Possible approaches
the information to be communicated is produced or consumed.
y Classification
y Object oriented To convey this information into the published messages, Publish-Subscribe (and
y Ontology oriented
y Data oriented
its content-based incarnation) encode the “context” of the publisher into the
messages.
This approach is limiting and inefficient.
Context-Aware Middleware Argomenti avanzati di Ingegneria del Software – 31

36. Publish-Subscribe: Why add context? [2]
Introduction
Matching inversion
Possible approaches
Conventional content-based publish-subscribe system:
y Classification
y Object oriented q messages hold data, subscriptions hold constraints on these data;
y Ontology oriented
y Data oriented q the data model and the matching semantics are unsuited for this case.
Necessity to invert the conventional matching process to consider constraints
embedded into messages and data embedded into subscriptions.
Efficiency
q Reduce the overhead of the subscription and unsubscription processes
(saving bandwidth);
q Reduce the time required to match messages.
Separation of concerns
Components in charge of publishing messages and subscribing to them differ
from those in charge to detecting and communicating context change.
Context-Aware Middleware Argomenti avanzati di Ingegneria del Software – 32

37. Publish-Subscribe: API
Introduction
Each node n can3 :
Possible approaches
y Classification q set its current context by invoking the setContext(c) operation;
y Object oriented
y Ontology oriented q subscribe to messages matching the content filter fmsg and coming from
y Data oriented
publishers whose context matches the context filter fctx through the
subscribe(fmsg ; fctx ); the unsubscribe(fmsg ; fctx ) operation does the
opposite;
q publish messages for subscribers whose context matches the context
filter fctx by invoking the publish(m; fctx ) operation.
3
G. Cugola, A. Margara: Politecnico di Milano; M. Migliavacca: Imperial College London
Context-Aware Middleware Argomenti avanzati di Ingegneria del Software – 33

38. Publish-Subscribe: Shortest Path Context Forwarding
(SPCF) protocol
Introduction
Messages are forwarded along the shortest path tree rooted at the publisher,
Possible approaches
using information about context and interests of downstream clients to decide
y Classification
y Object oriented
the branches to follow and those to prune.
y Ontology oriented
y Data oriented q Each broker runs a link state protocol to built its own view of the
dispatching network (without the client) and calculate the shortest path
trees (SPT) rooted to each broker in the network;
q Message forwarding uses these trees together with two tables (which are
kept by each broker):
3 context table: it maps brokers (identifier) to the set of contexts of
their clients;
3 content table: it stores, for each broker Bp , each context cp among
those of the clients attached to Bp , and each neighbor N, the set of
content filters and contexts coming from attached to brokers that
are downstream along N in the SPT rooted at Bp .
Context-Aware Middleware Argomenti avanzati di Ingegneria del Software – 34

39. Tuples On The Air (TOTA): Approach
Introduction
The key objectives of TOTA 4 are:
Possible approaches
y Classification q promotes decoupled and adaptive interactions by providing application
y Object oriented components with simple and expressive context information;
y Ontology oriented
y Data oriented q actively support adaptivity by discharging application components from
duty of dealing with network and application dynamics.
Relies on “spatially distributed tuples”.
TOTA adds and updates information in these tuples to reflect context and
connectivity. Agents “sense” these tuples to get context information and to
communicate.
4
M. Mamei, F. Zambonelli, L. Leonardi: Universit di Modena e Reggio Emilia
Context-Aware Middleware Argomenti avanzati di Ingegneria del Software – 35

40. TOTA: Overview
Introduction
Distributed tuples used to represent context and to support communication;
Possible approaches
y Classification q Tuples are not associated with a node;
y Object oriented
q Tuples autonomously propagate and diffuse through the network.
y Ontology oriented
y Data oriented
Computational model
q Peer-to-peer network;
q Nodes may be mobile and have a neighborhood;
q Each agent can store tuples and “lets” tuples diffuse through network.
Context-Aware Middleware Argomenti avanzati di Ingegneria del Software – 36

41. TOTA tuples and propagation rule
Introduction
TOTA tuples
Possible approaches
y Classification q Injected into the system from a particular node;
y Object oriented
q Defined by “content” and “propagation rule” T = (C, P );
y Ontology oriented
y Data oriented
3 C is an ordered set of typed fields representing the information
carried on by the tuple;
3 P determines how tuple is distributed and propagated in the
network.
Propagation rule
q Determines scope of the tuple (i.e. distance at which such tuple should
be propagated);
q Evaluated at each hop;
3 Determines how the tuples content may be changed;
3 Determines how propagation may be affected by presence/absence
of other tuples.
Context-Aware Middleware Argomenti avanzati di Ingegneria del Software – 37

42. TOTA: Architecture [1]
Introduction
Possible approaches
y Classification
y Object oriented
y Ontology oriented
y Data oriented
Context-Aware Middleware Argomenti avanzati di Ingegneria del Software – 38

43. TOTA: Architecture [2]
Introduction
The TOTA middleware is constituted by three main parts:
Possible approaches
y Classification q TOTA API: it is the main interface between the application and the
y Object oriented
middleware;
y Ontology oriented
y Data oriented q Event interface:
3 it is the component in charge of asynchronously notifying the
application about the income of a new tuple or about the fact a new
node has been connected/disconnected to the node’s
neighborhood;
q TOTA engine: the core of TOTA
3 it is in charge of maintaining the TOTA network by storing the
references to neighboring nodes and to manage tuple’s propagation
by opening communication socket to send and receive tuples.
Context-Aware Middleware Argomenti avanzati di Ingegneria del Software – 39

44. TOTA: API
Introduction
Possible approaches
q void inject(Tuple t): it is used to inject the tuple passed as an argument
y Classification in the TOTA network;
y Object oriented
y Ontology oriented
q ArrayList read(Tuple t): it returns a collection of tuples locally present in
y Data oriented the tuple space and matching the template passed as parameter;
q ArrayList delete(Tuple t): it extract from the local middleware all the
tuples matching the template and return them to the invoking component;
q void subscribe(Tuple t, String reaction): it associates the execution of
a reaction method in the component in response to the occurrence of
events matching the template tuple passed as first parameter;
q void unsubscribe(Tuple t, String reaction): it removes matching
subscriptions.
Context-Aware Middleware Argomenti avanzati di Ingegneria del Software – 40

45. Introduction
Possible approaches
The end
The end
Context-Aware Middleware Argomenti avanzati di Ingegneria del Software – 41