IAM01 Middleware for Ubiquitous Computing

07/10/2008 EPU Dep SI IAM01 1

IAM01

Middleware for Ubiquitous

ComputingPar Jean-Yves Tigli

[email protected]

Polytech‟ Nice Sophia Antipolis

mailto:[email protected]

Syllabus

12 weeks

07/10/2008 EPU Dep SI IAM01 2

Instructors

Main Instructor : Jean-Yves Tigli

Email : [email protected]

EPU Dep SI – J.-Y. Tigli

[email protected]/10/2008


Instructors

Other Instructors :

Didier Donsez, Professor, at the University University

Joseph Fourier - Grenoble 1

Stéphane Lavirotte, MCF Université de Nice – Sophia

Antipolis

Gaëtan Rey, MCF Université de Nice – Sophia Antipolis

Michel Riveill, Professor at the University of Nice – Sophia

Antipolis

From companies :

Vincent Hourdin, MobileGov



ABSTRACT :

Ubiquitous computing names the third wave in

computing, just now beginning.

Alan Kay of Apple calls this “Third Paradigm” computing.

Friedemann Mattern, explains this trend from four

technological reasons: miniaturization of devices, new

materials, progress in communication technologies and

better sensors.

Anyway, ubiquitous computing introduces new

challenges in the software engineering domain leading to

numerous innovations for middleware.



ABSTRACT :

After introducing such challenges, we divide the

course in three kinds of sessions.

The first one presents current approaches already

introduced for the software design of applications on

mobile device.

In the second, we introduce the main research works

led on the topic preparing the future of ubiquitous

computing like, context-awareness, adaptive

middleware and wearable computing.



ABSTRACT :

Then, the student project period is intended for a

personal practical work of the student (see (*) in the

courses details). Every student chooses, according to

his focus of interest, one of these three kinds of

exercises:

Writing a scientific paper on a research topic of the domain,

Writing a journalistic paper on a technological topic of the

domain,

Designing and developing software for ubiquitous computing

applications in the continuation of the practical works of this

master course.

All these productions are presented in a final session.



OBJECTIVES

The main purpose of this course is to provide a

survey and skills for middleware in mobile and

ubiquitous computing. A second objective is to

introduce the main topics of research that

prepare future evolutions of this domain.



CONTENTS:

Ubiquitous Computing : Vision and Challenges,

J.Y. Tigli (C 3h)

Framework for Mobile Device : J2ME, M. Riveill

(C 3h)

Framework for Mobile Device : J2ME, M. Riveill

(TD 4h)

Framework for Mobile Device : Compact .Net

Framework, J.Y. Tigli (C 3h)

Framework for Mobile Device : Compact .Net

Framework, J.Y. Tigli (TD 4h)



CONTENTS: Middleware based on Web Services for Device :

UPnP and DPWS, S. Lavirotte (C 2h / TD 2 h)

OSGi middleware for Mobile Device, D. Donsez

(C 3h /TD 2h)

Android middleware for Mobile Device, G. Rey

(C 2h / TD 2h)

Survey on research topics for Middleware in

Ubiquitous Computing, JY Tigli (C 3h)

Adaptive Middleware, S. Lavirotte (2h C) -

Middleware for Wearable Computing, JY Tigli

(2h C) EPU Dep SI – J.-Y. Tigli


CONTENTS: Middleware for Context awareness, G. Rey (3h

C)

WComp Environment, JY Tigli (C 2h / TD 2h)

Students Project*, JY Tigli - S. Lavirotte - G

.Rey (according to the kind of exercise) (TD 4 h)





Presentations and assessment (All the

instructors)EPU Dep SI – J.-Y. Tigli


Partie 1 : Introduction to Middleware

By Jean-Yves Tigli

[email protected]


From « A Survey of Adaptive Middleware »

SeyedMasoud Sadjadi

www.cse.msu.edu/~sadjadis

Software Engineering and Networking Systems Laboratory, Department of

Computer Science and Engineering, Michigan State University

www.cse.msu.edu/sens




http://www.cse.msu.edu/~sadjadis

Motivation

Problem

complexity of interprocess communication

heterogeneity of platforms

changing conditions

Functional

Environmental

Traditional Middleware

addresses the first two problems to some extent

is limited in supporting adaptation

Adaptive Middleware

addresses all three problems

still ongoing research



Definitions

...middleware is a general term for any programming that

serves to "glue together" or mediate between two

separate and usually already existing programs. (...)

Software that provides a link between disparate

applications. (Computeruser dictionary; Lycos

tech dictionary)



10/7/200815

Definitions

... middleware must allow the interoperability of the

applications that are based on it. (Laurent Kott, General

Delegate to Technology Transfers at INRIA. (2002))

the intersection of the stuff that network engineers don’t

want to do with the stuff that applications developers

don’t want to do. (Kenneth J. Klingenstein ('99))

10/7/200816

Definitions

Middleware can be viewed as a reusable, expandable

set of services and functions that are commonly needed

by many applications to function well in a networked

environment. (NGI workshop, '97)

... a customizable set of components which can be

tailored to the needs of an application. (Middleware

2001)

17

Background Traditional Middleware

connectivity software

below application and above operation system layer

provides high-level programming abstractions

Middleware Classification by Emmerich [1]

Traditional Middleware

Message-Oriented

Middleware

Transactional

Middleware

Procedural

Middleware

Object-Oriented

Middleware

Object-Oriented Middleware

Java RMICORBA DCOM

18

Example : CORBA CORBA

Common Object Request Broker Architecture.

A distributed object framework by OMG.

Supports distributed object-oriented computing across

heterogeneous hardware devices, operating systems,

network protocols, and programming languages.

Components

Object

Servant

Client

IDL Compiler

Stub

Skeleton

ORB Core

GIOP/IIOP

CORBA architecture [2].

19

Examples : Java RMI & DCOM Java RMI

Java Remote Method Invocation.

A Java distributed object framework by JavaSoft.

Supports distributed computing across heterogeneous hardware devices

and operating systems using the Java Virtual Machine (JVM).

Serialization.

DCOM

Distributed Component Object Model.

A Windows distributed object framework by Microsoft.

An extension to the COM that supports heterogeneous programming

languages and network protocols.

Provides a binary standard like C++ vtable.

“Object proxies” and “object stubs” in DCOM are referred as “IDL stubs”

and “IDL skeleton” in CORBA, respectively!

Partie 2 : Introduction to Ubiquituous

Systems byJean-Yves Tigli

[email protected]







1. La Vision du Chercheur (1991) :

« Ubiquituous Computing »

Informatique Pervasive, Ubiquitaire, Omniprésente, Evanescente, Ambiante …

[Weiser 1991]

« Silicon-based information technology, is far fromhaving become part of the environment »



Partie 2 : 4 raisons de Friedemann

Mattern ETH - Computer Science - Prof. Friedemann Mattern

Université de Zurich – Suisse

Moore„s Law

New materials

Progress in communication technology

Better sensors

First Reason for Ubiquitous

Computing: Moore‘s Law (1965) Processing speed and storage

capacity double every 18 months

“cheaper, smaller, faster“

Exponential increase

will probably go on for the

next 10 years at same rate

First



Disk Storage Density



Bit Storage Density



Generalized Moore‘s Law



Energy Crisis: Not Everything

Obeys Moore‘s Law!



Barriers



2nd Reason: New Materials

Whole eras named after materials

e.g., „Stone Age“

More recently: semiconductors, fibers

information and communication technology

Organic semiconductors

change the external appearance of computers

« Plastic » laser

opto electronics, flexible displays,…

...



3rd Trend: Progress in

Communication Technologies Fiber optics: from Gbit/s to Tbit/s

Powerline technique

coffee maker „automatically“ connected to the Internet

Wireless

mobile phone: GSM, UMTS

wireless LAN (> 10 Mbit/s)

Body area networks



4th Reason: Better Sensors

Very small cameras and microphones

pattern recognition, assisted by heuristics

(„user is in a meeting…“)

speaker recognition, speech controlled devices

Fingerprint sensor on mobile objects

(„we already know this guy“)

Many other types of sensors (e.g., „location“)

Autonomous perception of the user„s environment

establishing contextual relations

recognition of objects



All Trends Together

Lead to a New Era Progress in

computing speed

communication bandwidth

material sciences

sensor technology

computer science concepts

Miniaturization

energy usage

battery technique

display technologies

Price

...


[email protected]

Pervasive Computing

Ubiquitous Computing

Ambient Intelligence

Disappearing Computer

Invisible Computing

(Simoneit, 2004)

Embeddedness versus Mobility

07/10/2008 EPU Dep SI IAM01 34

Partie 3 : Middleware for

Ubiquitous computing

By Jean-Yves Tigli

[email protected]





4.1 Numerous Smart Objects in the

Environment …

WSI Reference Model

Internet

Web Services

UPnP

PANs

RF Tags

http://citeseer.ist.psu.edu/cache/papers/cs/2694

3/http:zSzzSzpaula.oulu.fizSzPublicationszSzCub

ezSzWWRF7.pdf/the-cyperworld-reference-

model.pdf

Computered target model is changing

… Depuis Von Neumann … les évolutions …

27 juin 200836 Rainbow-Ubiq

E/

S

CO

M

CP

UDAT

A

Energ

ie

Pervasion

Temps

1960

1970

19902000 - 2010

Adapté de « Nano-informatique et intelligence ambiante », JB Waldner, Hermes Science Publishing, 2007



First Step in Middleware evolution,

Standards are disturbed … Software environment evolution

Heterogeneity and Dynamicity

Towards adaptive software

?

Interface Standard Intergiciel Plateforme (s)



Example : Java for Devices

And more and more JSR



4.3.1 .Net Frameworks

This is the first part of the course …

About J2ME

About Compact .Net Frameworks .;.





Second step in Middleware evolution :

how to deal with more and more

devices and smart objects ?

New challenges for Middlewares … they must be

adaptative

Ubiquitous computing constrains

New challenges for Middlewares … they must

be adaptative

They must deal with Multiple (users, devices…)

Heterogeneity (devices, plateforms…)

Dynamicity of the environment



Advanced Key Paradigms for

adaptation Computational Reflection

Component-Based Design

Aspect-Oriented Programming

Software Design Patterns

44

Computational Reflection The ability of a program to reason about, and possibly

alter, its own behavior [3].

Enables a system to “open up” its implementation details

for such analysis without revealing the unnecessary

parts or compromising portability [4].

Terminology

Relationship between meta-level and base-level objects.

Base-level

Meta-level

MOP

Casually connected

Per-ORB, per-class,

per-object, and per-

interface reflection

Base Level

Meta Level Meta Object Protocols

45

Component-Based Design Software components

Software units that can be independently produced,

deployed, and composed by third parties [5].

Self-contained

Commodity-of-the-shelf (COTS)

Component-based design (CBD)

large scale reuse of software

Composition

late binding

Component-Based Middleware

DCOM

EJB

CCMIndependent Components

46

Aspect-Oriented Programming Complex programs are composed of different

intervened cross-cutting concerns [6].

Cross-cutting concerns:

Properties or areas of interest such as QoS, energy

consumption, fault tolerance, and security.

Terminology

AOP in action.

Aspect

Basic Functionality

Aspect Language

Aspect Weaver

Static

Dynamic

Woven Code

Basic

Functionality

Cross-Cutting

Aspects

Aspect WeaverWoven Code

47

Software Design Patterns Enables reuse of best software design practices [7].

Benefits

common vocabulary for communicating insight and

experience about recurring problems

Patterns commonly used in adaptive middleware

Class diagram.

Façade

Wrapper

Interceptor

Strategy

Service Configurator

Virtual Component

Taxonomy … different points of view

Middleware Layers

Adaptation Type

Application Domain



49

Kernel

Application

Distribution

Common-Services

Host-Infrastructure

Domain-Services

Mid

dle

war

e L

ayer

s

kernel boundary

process boundary

layer boundary

Middleware Layers

Domain-Services

Tailored to a specific class of

distributed applications

Common-Services

Functionality such as fault

tolerance, security, load

balancing and transactions

Distribution

Programming-language

abstraction

Host-Infrastructure

Platform-abstraction

Schmidt [8] decomposed

middleware into four layers:

Middleware layers [8]

Note: an adaptive middleware project

may fall in more than one layer.

50

Adaptation Type

Static Middleware

Customizable Middleware

Enables developers to compile (and link) customized versions of applications.

Configurable Middleware

Enables administrators to configure the middleware after compile time.

Dynamic Middleware

Tunable Middleware

Enables administrators to fine-tune applications during run time.

Mutable Middleware

Enables administrators to dynamically adapt applications at run time.

Development Time

Adaptive Middleware

Static Middleware

Customizable Configurable Tunable Mutable

Compile Time Startup Time Run Time

Dynamic Middleware

Adaptation Type

Application Lifetime

Note: an adaptive middleware project may provide more that one adaptation.

51

Application Domains …

QoS-Oriented Middleware

supports real-time and multimedia applications

Example:

avionics systems, video conferencing and Internet telephony

Dependable Middleware

supports critical distributed applications that are required to be correctly operational

Example:

military command and control and medical applications

Embedded Middleware

supports small footprints

Examples:

smart phones, hand-held devices, and industrial controllers

Adaptive Middleware

Dependable MiddlewareQoS-Oriented Middleware Embedded Middleware

Examples

Real-Time Middleware

Embedded Middleware



53

Real-Time Middleware TAO

Schmidt et al.

CORBA compliant ORB

Classification

Distribution layer

Configurable and Tunable MW

Real-time MWTAO Architecture [9].

Servant1Configurator Servant2Configurator

TAOConfigurator

DomainConfigurator

ConcurrencyStrategy

SchedulingStrategy

SecurityStrategy

MonitoringStrategy

Reified DynamicTAO [10].

DynamicTAO

– UIUC

– A reflective TAO

Classification

– Distribution layer

– Tunable MW

– Real-time MW

54

Embedded Middleware

Minimum Middleware

Enables minimum footprint applications

For a specific application-domain

Fixed minimum core

For one specific application

No fixed core

Swappable Middleware

Enables optional portions of middleware to swap in

and out dynamically

Fixed minimum core

Embedded Middleware

Minimum Middleware Swappable Middleware

55

Key Paradigms and Standards

Computational

Reflection

Component-

Based Design

Aspect-

Oriented

Programming

Software-

Design Patterns

Reliable-

Communication

Middleware

CORBA

Java RMI

DCOM

Third Step… towards Context-aware

Middlewares

Environment

Devices

Measurments

ObserversModem

extractionEvaluation Adaptation

Conflicts

resolution

56

Middleware Context Managing

Framework

Centralized Context Manager

Pros

Overcome memory and processor

constraints of

small mobile devices

Cons

One single point of failure

Example 1 : Middleware CASS

(Context-awareness sub-structure) Centralized middleware approach

Local caching on the client side

Example 2 : Middleare Hydrogen

Specializing in mobile devices

Remote context and local context

Context sharing

In a peer-to-peer manner

Object oriented approach

Superclass ContextObject

Example 2 : Middleware Hydrogen

(cont’d)

All located on the same device

Context Server

Synchronous and asynchronous methods

All inter-layer communication is based on a XML-protocol

Example 3 : Middleware CORTEX Context-aware middleware approach

Use of STEAM

A location-aware event-based middleware service

Supports a graphical development tool

Specify relevant sensors and actuators

Define fusion networks

Specify context hierarchy and production rules

Example 4 : Middleware Gaia

Another middleware infrastructure

Extends typical operating systems concepts to include context-

awareness

Others examples :

SOCAM (Service-oriented Context-Aware Middleware)

Centralized context interpreter

CoBrA (Context Broker Architecture)

Agent based architecture

(Centralized) context broker

Context Knowledge Base, Context Inference Engine, Context Acquisition Module, Privacy Management Module

Broker federations

Context Toolkit

Peer-to-peer architecture, still needs a centralized discoverer

Distributed sensor units (widgets), interpreters and aggregators

Object-oriented API: super class BaseObject

64

References[1] Wolfgang Emmerich. Software engineering and middleware: a roadmap. In

Proceedings of the Conference on The future of Software engineering, pages 117-129, 2000.

[2] http://www.cs.wustl.edu/~schmidt/corba-overview.html.

[3] Pattie Maes. Concepts and experiments in computational reflection. In Proceedings of the ACM Conference on Object-Oriented Languages (OOPSLA), December 1987.

[4] G. Kiczales, J. d. Rivieres, and D. G. Bobrow. The Art of Metaobject Protocols. MIT Press, 1991.

[5] Clemens Szyperski. Component Software: Beyond Object-Oriented Programming. Addison-Wesley, 1999.

[6] Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides. Design Patterns: Elements od Reusable Object-Oriented Software. Addison-Wesley Professional Computing Series. Addison-Wesley Publishing Company, New York, NY, 1995.

[7] G. Kiczales, J. Lamping, A. Mendhekar, C. Maeda, C. Videira Lopes, J. M. Loingtier, and J. Irwin. Aspect-oriented programming. In Proceedings of the European Conference on Object-Oriented Programming (ECOOP). Springer-Verlag LNCS 1241, June 1997.

[8] Douglas C. Schmidt. Middleware for real-time and embedded systems. Communications of the ACM, 45(6), June 2002.

[9] D. C. Schmidt, D. L. Levine, and S. Mungee. The design of the TAO real-time object request broker. Computer Communications, 21(4):294-324, April 1998.

[10] Fabio Kon, Manuel Román, Ping Liu, Jina Mao, Tomonori Yamane, Luiz Claudio Magalhaes, and Roy H. Campbell. Monitoring, security, and dynamic configuration with the dynamicTAO reflective ORB. In Proceedings of the IFIP/ACM International Conference on Distributed Systems Platforms (Middleware 2000), New York, April 2000.

65

References[11] T. Fitzpatrick, G. Blair, G. Coulson, N. Davies, and P. Robin. Supporting adaptive

multimedia applications through open bindings. In Proceedings of International Conference on Congurable Distributed Systems (ICCDS'98), May 1998.

[12] R. Koster. A Middleware Platform for Information Flows. PhD thesis, Department of Computer Science, University of Kaiserslautern, Germany, July 2002.

[13] John A. Zinky, David E. Bakken, and Richard E. Schantz. Architectural support for quality of service for CORBA objects. Theory and Practice of Object Systems, 3(1), 1997.

[14] Martin Geier, Martin Steckermeier, Ulrich Becker, Franz J. Hauck, Erich Meier, and Uwe Rastofer. Support for mobility and replication in the AspectIXarchitecture. Technical Report TR-I4-98-05, Univ. of Erlangen-Nuernberg, IMMD IV, 1998.

[15] Victor C. Zandy and Barton P. Miller. Reliable network connections. In ACM MobiCom 2002, Atlanta, September 2002.

[16] C. Marchetti, L. Verde, and R. Baldoni. CORBA request portable interceptors: A performance analysis. In the 3nd International Symposium on Distributed Objects and Applications (DOA 2001), Rome, Italy, Sept. 2001.

[17] L. Moser, P. Melliar-Smith, P. Narasimhan, L. Tewksbury, and V. Kalogeraki. The eternal system: an architecture for enterprise applications. In the 3rd International Enterprise Distributed Object Computing Conference (EDOC'99), July 1999.

[18] Sun Microsystems. EmbeddedJava Application Environment. http://java.sun.com/products/embeddedjava/.

[19] Raymond Klefstad, Douglas C. Schmidt, and Carlos O'Ryan. Towards highly configurable real-time object request brokers. In Fifth IEEE International Symposium on Object-Oriented Real-Time Distributed Computing, April - May 2002.

Annexe 1 : Paradigmes dans les

middleware context-aware

Composants Objets Services Evénements Aspects

Gaia V

RCSM V V

CARMEN V V

Amigo V V

CORTEX V V

Aura V V

CAMidO V V

CARISMA V

Oxygen V

SAFRAN V V V

WComp V V V V

Annexe 2 : Techniques utilisées pour

l’adaptation

MOP Proxy Container Tissage Interception

middleware

génération

Gaia V

RCSM V V

CARMEN V

Amigo

CORTEX V

Aura V V

CAMidO V V V

CARISM

A

V

Oxygen V

SAFRAN V V

WComp V V ? V

Annexe 3 : Caractéristiques des

middlewareHétérogénéit

é

Réactivit

é

Mobilité Découvert

e

Passage à

l‟échelle

Gaia V V V V

RCSM V V

CARMEN V V V

Amigo V V V V

CORTEX V V V V

Aura V V V

CAMidO V

CARISM

A

V V V

Oxygen V V

SAFRAN V

WComp V V V V V

Annexe 4 : Mise en place de

l’adaptationAdaptation

Middleware Application

transparent Profil règles

Gaia V

RCSM V

CARMEN V

Amigo V

CORTEX V

Aura V

CAMidO V

CARISMA V

Oxygen V

SAFRAN V

SOCAM V

WComp V

•Transparent : Le middleware réagit au changement de contexte sans

que les applications en soient informées

• Profil : Les applications fournissent au middleware des informations

(ex: les services qui l’intéresse ) pour que le middleware réalise l’adaptation

•Règles : Les applications fournissent des règles au middleware pour l’évaluation du contexte

Annexe 5 : Informations pour l’évaluation

du contexteLes applications ne fournissent

pas d‟instructions au

middleware en vue de

l‟adaptation

Les applications fournissent

des instructions au middleware

en vue de l‟adaptation

RCSM V(application=ensemble de

composants)

CARMEN V

CORTEX V(application=ensemble

d‟objets sensibles)

Aura V

CAMidO V

CARISMA V

Oxygen V

SAFRAN V

WComp V(applications=assemblage)

• Instruction : soit des informations relatives à un profil pour l’application, soit un

ensemble de règles en vue de l’adaptation

Annexe 6 : Prise en compte du

contexteDécouverte dynamique

de nouvelles entités

Déduction

d‟infos de plus

haut niveau

Historique des

contextes

observés

Apprentissag

e

Utilisation de

préférences

Interface

utilisateur pour

configuration

Gaia V,X V V V

RCSM V,X V

CARMEN V,X V V

SOCAM V V V

Amigo V V V V V

CORTEX V

Aura V V V V V

CAMidO V V V

CARISM

A

V

Oxygen V,X V V V

SAFRAN V

WComp V V

Annexe 7 : Résolution des conflits &

sécurité Résolution des conflits

d‟adaptation

Sécurité

Gaia V

RCSM

CARME

N

V V

Amigo

CORTE

X

Aura V

CAMidO

CARISM

A

V

Oxygen V

SAFRAN

WComp V

• Sécurité : Ce sont les politiques et les procédures qui permettent d'éviter

les intrusions (confidentialité) dans le système avec des mécanismes d’authentification

Annexe 8 : Séparation des

préoccupationsSéparation des préoccupations

Gaia

RCSM V

CARMEN

Amigo

CORTEX

Aura

CAMidO V

CARISMA V

Oxygen

SAFRAN V

WComp V

Annexe 9 : Dynamicité de l’adaptationAdaptation

statique

Adaptation

dynamique

Gaia V

RCSM V

CARMEN V

Amigo

CORTEX V V

Aura V ?

CAMidO V V

CARISM

A

V

Oxygen V

SAFRAN V

WComp V

• Statique : L’adaptation se réalise lors de la compilation ou du chargement

de l’application

• Dynamique : L’adaptation se réalise à l’exécution

Annexe 10 : Centralisation des conditions,

règles de déclenchement

Middleware Type d’architecture Mise en œuvre

Centralisé middleware Centralisé application Centralisé composant Décentralisé

Gaia X Dans l’entité

RCSM X Une interface contenant

les règles par composant

CARMEN X Dans un LDAP spécialisé

Amigo X Dans l’entité ANS

CORTEX X Règles associés aux objets

sensibles

Aura X Dans l’entité du

middleware

environnement manager

CAMidO X Interfaces associées à une

application

CARISMA X Métadonnées associées à

une application

Oxygen X Dans l’entité du

middleware core

SAFRAN X Des scripts sont associés

aux composants

dynamiquement (pas de

distribution)

WComp X Schémas contextuels

Documents

IAM01 Middleware for Ubiquitous Computing