View
1
Download
0
Category
Preview:
Citation preview
07/10/2008 EPU Dep SI IAM01 1
IAM01
Middleware for Ubiquitous
ComputingPar Jean-Yves Tigli
tigli@essi.fr
Polytech‟ Nice Sophia Antipolis
Instructors
Main Instructor : Jean-Yves Tigli
Email : tigli@polytech.unice.fr
EPU Dep SI – J.-Y. Tigli
tigli@polytech.unice.fr307/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
EPU Dep SI – J.-Y. Tigli
tigli@polytech.unice.fr407/10/2008
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.
EPU Dep SI – J.-Y. Tigli
tigli@polytech.unice.fr507/10/2008
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.
EPU Dep SI – J.-Y. Tigli
tigli@polytech.unice.fr607/10/2008
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.
EPU Dep SI – J.-Y. Tigli
tigli@polytech.unice.fr707/10/2008
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.
EPU Dep SI – J.-Y. Tigli
tigli@polytech.unice.fr807/10/2008
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)
EPU Dep SI – J.-Y. Tigli
tigli@polytech.unice.fr907/10/2008
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
tigli@polytech.unice.fr1007/10/2008
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)
Students Project*, JY Tigli - S. Lavirotte - G
.Rey (according to the kind of exercise) (TD 4 h)
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
tigli@polytech.unice.fr1107/10/2008
Partie 1 : Introduction to Middleware
By Jean-Yves Tigli
tigli@essi.fr
Polytech‟ Nice Sophia Antipolis
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
EPU Dep SI – J.-Y. Tigli
tigli@polytech.unice.fr1207/10/2008
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
EPU Dep SI – J.-Y. Tigli
tigli@polytech.unice.fr1307/10/2008
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)
EPU Dep SI – J.-Y. Tigli
tigli@polytech.unice.fr1407/10/2008
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
tigli@essi.fr
Polytech‟ Nice Sophia Antipolis
EPU Dep SI – J.-Y. Tigli
tigli@polytech.unice.fr2007/10/2008
EPU Dep SI – J.-Y. Tigli
tigli@polytech.unice.fr2107/10/2008
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 »
EPU Dep SI – J.-Y. Tigli
tigli@polytech.unice.fr2207/10/2008
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
EPU Dep SI – J.-Y. Tigli
tigli@polytech.unice.fr2307/10/2008
Energy Crisis: Not Everything
Obeys Moore‘s Law!
EPU Dep SI – J.-Y. Tigli
tigli@polytech.unice.fr2707/10/2008
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,…
...
EPU Dep SI – J.-Y. Tigli
tigli@polytech.unice.fr2907/10/2008
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
EPU Dep SI – J.-Y. Tigli
tigli@polytech.unice.fr3007/10/2008
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
EPU Dep SI – J.-Y. Tigli
tigli@polytech.unice.fr3107/10/2008
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
...
EPU Dep SI – J.-Y. Tigli
tigli@polytech.unice.fr32
Pervasive Computing
Ubiquitous Computing
Ambient Intelligence
Disappearing Computer
Invisible Computing
07/10/2008 EPU Dep SI IAM01 34
Partie 3 : Middleware for
Ubiquitous computing
By Jean-Yves Tigli
tigli@essi.fr
Polytech‟ Nice Sophia Antipolis
EPU Dep SI – J.-Y. Tigli
tigli@polytech.unice.fr3507/10/2008
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
EPU Dep SI – J.-Y. Tigli
tigli@polytech.unice.fr3707/10/2008
First Step in Middleware evolution,
Standards are disturbed … Software environment evolution
Heterogeneity and Dynamicity
Towards adaptive software
?
Interface Standard Intergiciel Plateforme (s)
EPU Dep SI – J.-Y. Tigli
tigli@polytech.unice.fr3807/10/2008
Example : Java for Devices
And more and more JSR
This is the first part of the course …
About J2ME
About Compact .Net Frameworks .;.
EPU Dep SI – J.-Y. Tigli
tigli@polytech.unice.fr4007/10/2008
EPU Dep SI – J.-Y. Tigli
tigli@polytech.unice.fr4107/10/2008
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
EPU Dep SI – J.-Y. Tigli
tigli@polytech.unice.fr4207/10/2008
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
EPU Dep SI – J.-Y. Tigli
tigli@polytech.unice.fr4807/10/2008
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
EPU Dep SI – J.-Y. Tigli
tigli@polytech.unice.fr5207/10/2008
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
Recommended