Repr

1

• Représentation efficace des données dans un
  intergiciel schizophrène

• Thomas Quinot

• Senior software engineer, AdaCore

• Séminaire Performance et GénéricitéLRDE, 5
  novembre 2008

2
Plan

• Contexte
• Larchitecture dintergiciel schizophrène
• Représentation neutre des interactions
• Any, un conteneur universel typé
• Structure dAny
• Fonction de représentation
• Shadow Any, un accesseur structuré universel
• Parcours pertinents dans la structure dAny
• Définition dune structure propre à les fournir à
  moindre coût
• Mise en œuvre
• Shadow Any dans PolyORB/CORBA
• Performances
• Extensions
• (Dé)Sérialisation bypass
• Application à dautres modèles de répartition
  (DSA)
• Conclusion

3
Intergiciel schizophrène Exigences

• Intergiciel pour systèmes temps réel répartis
  comme COTS
• Réduire le coût et le risque derreurs
• Exigences industrielles
• Domaines avionique, espace, transport
• Familles sûreté, déterminisme, intégrité
• Lintergiciel pour STRR doit sadapter
• Choix de protocoles, politiques de qualité de
  service de sécurité
• Ressources disponibles vs sémantique souhaitée
  concurrence, ordonnancement, empreinte mémoire
• Normes RT-CORBA, DDS
• Extensions Résistance aux défaillances, haute
  intégrité, etc.
• Comment concentrer lexpertise sur une
  plate-forme dintergiciel
• Tout en prenant en compte de nouvelles exigences
  normes ?

4
Crise de lintergiciel

• Exigences contradictoires sur lintergiciel,
  élément clé de linteraction
• Configuration
• Adaptation à larchitecture cible
• Genericité
• Adaptation du modèle de répartition aux besoins
  de lapplication
• Interoperabilité entre modèles de répartition
• Paradoxe de lintergiciel
• Prise en compte des composants applicatifs
  hérités
• Intégration des systèmes dinformation
• Élaboration de la confiance dans lintergiciel
• Vérification formelle de la mise en oeuvre
• Propriétés comportementales, métriques,
  consommation de ressources
• Quality of Service les termes à la mode
• Temps réel, résistance aux défaillances,
  rapidité

5
Intergiciel configurable

• Exigence Pouvoir contrôler le comportement de
  certaines fonctions
• Aspects concernés
• Paramétrage découplé des composants de
  lintergiciel
• Canaux de communication
• Adaptation aux ressources et aux fonctionnalités
  de la plateforme dexécution
• Choix des fonctionnalités nécessaires pour
  lapplication
• Solutions
• Composants configurables
• Agencement faiblement couplé par patrons de
  conceptionset frameworks
• Pour chaque composant
• choix dune mise en œuvre adaptée
• agencement par Strategy, Abstract factory
• Exemple existant
• TAO
• Spécialisé pour un modèle de répartition (CORBA)
• Efficace mais conception complexe
• Objectif offrir une flexibilité comparable

6
Intergiciel générique

• Exigence Pouvoir décliner une boîte à outils
  selon les paradigmes de multiples modèles de
  répartition
• Aspects concernés
• Paramétrage de lassemblage de composants
• Choix des concrétisations de composants
• Définition des fonctionnalités partagées
• Solutions
• Intergiciels génériques factorisation de code
• Personnalités instances dintergiciel générique
• Exemples existants
• Jonathan/Quarterware
• Frameworks pour la construction dintergiciels
• Factorisation limitée (10-25)
• Objectif augmenter la factorisation de code

7
Intergiciel interopérable

• Exigence interopérabilité entre modèles de
  répartition (DSA, CORBA)
• Aspects concernés
• Communication M2M (Middleware 2 Middleware)
• Solutions
• Passerelles / mandataires
• Coûteux, difficultés de maintenance et de passage
  à léchelle
• Usage de protocoles communs (par ex. web
  services)
• Contrainte qui limite lintégration de lexistant
• Exemples existants
• Peu nombreux
• CorbaWeb
• Interoperabilié CORBA / web services
• Objectif offrir une solution efficace et unifiée

8
Intergiciel sûr

• Exigence lutilisation dun intergiciel ne
  remet pas en cause le déterminisme de
  lapplication
• Aspects concernés
• Vérification de la correction de lintergiciel
• Solutions
• Description formelle de lintergiciel
• Tests
• Preuve de propriétés comportementales
• Pas dexemples existants
• Objectif fournir un intergiciel formellement
  vérifié pour les systèmes critiques

9
PolyORB un intergiciel schizophrène

• Logiciel libre
• Projet de recherche ENST / LIP6
• Premières versions beta en 2001
• Portable vers toutes les cibles où GNAT est
  supporté
• Industrialisation par AdaCore
• Plus de 8 ans de développement, 205 kSLOCs
  (2008-11)
• Membre du consortium ObjectWeb
• PolyORB 2.5.1 publié par AdaCore en 2009 avec
  GNAT Pro 6.2.1
• Personnalités supportées CORBA, DSA, IIOP
• Personnalités additionnelles MIOP, SOAP, MOMA,
  AWS
• Travaux de recherche DDS, TDMA
• Nouvelles fonctionnalités Service de mémoire
  partagée répartie, améliorations de performances

10
Personnalités cohabitantes et coopérantes

• Réunion de deux approches architecturales
• Généricité
• Architecture unifiée
• Composants génériques, interfaces abstraites
• Personnalités
• Instanciation dun intergiciel générique pour un
  modèle de répartition donné
• Créé à partir dun ensemble restreint de
  composants réutilisables ou spécifiques

Couche neutre
Coeurdintergiciel
11
Intergiciel schizophrène une analogie
Perso. applicative Front-end

• Couche neutre
•  Cœur  de PolyORB
• Similaire au langage intermédiaire dun
  compilateur
• Personnalités front-ends et back-ends
• Utilisation de patrons de conception pour la
  configurabilité
• Configuration afin de satisfaire les exigences de
  lapplication
• Par exemple support de modèles de parallélisme
  sans tâches, parallélisme déterministe
  (Ravenscar), parallélisme libre
• La couche neutre fournit les sept fonctions
  fondamentages
• Adressage, liaison, représentation, protocole,
  transport, activation, exécution
• Sujet de la vérification formelle

Couche neutre langage intermédiaire
Perso. protocolaire Back-end
12
Voyage au coeur dun intergiciel schizophrène

• Généricité dans PolyORB gt vue canonique des
  fonctions de lintergiciel
• Setp fonctions coordonnées par le µBroker
• Composants annexes dictionnaires, queues,
  filtres
• Indépendant des modèles de répartition
• µBroker, intergiciel local
• Alloue des ressources dexécution pour traiter
  les événements générés par lapplication ou
  lextérieur, ordonnance les traitements, aiguille
  les requêtes, contrôle létat global de
  lintergiciel

Network
13
Intergiciel schizophrène en action
DSA
CORBA
Hello Server
Hello Client


Neutral Core Middleware


request receiving analysis

SOAP
network
14
Représentation neutre des requêtes et des données

• Représente complètement une interaction entre
  composants applicatifs
• Contient
• Nom de lopérations
• Paramètres sous forme dune liste de NamedValues
• Any (conteneur universel typé)
• Nom
• Direction (in/out/in out)
• Au retour
• Valeur renvoyée (Any)
• Exception (Any)
• Fonction de représentation
• Dans la personnalité protocolaire
• Conversion entre la forme neutre et une forme
  transmissible

15
Structure dAny

• Conteneur universel typé, avec comptage de
  références
• Inspiré de la DII CORBA
• Smart pointer désignant un Any_Contents
• Any_Contents type abstrait
• TypeCode
• Pointeur vers la donnée stockée
• Any_Contents dérivés
• Un pour chaque type élémentaire
• Any_Content_Aggregate pour les types composites

16
Construction naïve dAny

• Exemple séquence de structures

Agrégat
Agrégat
Elém
Elém
Elém
17
Sérialisation

• Parcours en profondeur dabord
• Piloté par les TypeCodes à chaque nœud de larbre

Agrégat
Séq (3)
Agrégat
Struct
Struct
Struct
Elém
Elém
Elém
El
El
El
Elém
Elém
Elém
El
El
El
Elém
Elém
Elém
El
El
El
3
B
V
R
B
V
R
B
V
R
18
Désérialisation

• A partir du TypeCode (connu à lavance)
• Et des données sérialisées
• Reconstruction de larbre
• Puis de la structure de données originale

3
B
V
R
B
V
R
B
V
R
Agrégat
Séq
Agrégat
Struct
Struct
Struct
Elém
Elém
Elém
El
El
El
Elém
Elém
Elém
El
El
El
Elém
Elém
Elém
El
El
El
19
Inconvénients

• Structures allouées dynamiquement
• Comptage de références
• Donc verrouillage
• Copie complète des données
• Nombreuses petites allocations

Construction complexe Coûteuse en temps Coûteuse
en espace
20
Parcours dans les structures dAny

• Pour les opérations de
• Sérialisation
• Désérialisation
• larbre est toujours parcouru en profondeur
  dabord

Pas de traitements globaux de larbre une vue
locale est suffisante
21
Shadow Any

• Remplace lagrégat générique par un type
  spécifique
• Façade adossé à la donnée stockée réelle

MaSéqStruct
22
Parcours dans un Shadow Any (sérialisation)

• Façades des composants créées au vol, sur la pile

MaSéqStruct
MaStruct
MaStruct
MaStruct
Elém
Elém
Elém
23
Parcours dun Shadow Any (désérialisation)

• Structure, tableau comme pour la sérialisation
• Séquences, unions types à discriminants /
  bornes
• Désérialisation des discriminants ou bornes,
  stockage intermédaire dans la façade Shadow Any
• Allocation de lobjet contraint
• Puis parcours usuel

24
Shadow Any dans PolyORB/CORBA

• Type abstrait Aggregate_Content
• Type concret générique
• Types concrets spécifiques générés par IAC
• Wrap
• function Wrap (X access T) return
  Any_ContentClass
• Création dun contenu étranger (allocation gérée
  par le client)
• Get,Set_Aggregate_Count
• Get,Set_Aggregate_Element
• By_Reference Demande dune façade pour mise à
  jour
• By_Value Demande dune façade pour lecture
• Au retour, si By_Value, lappelant doit utiliser
  Set_Aggregate_Element pour mettre à jour (cas
  dun discriminant ou dune borne)
• La durée de vie de lAny doit être gt celle de la
  donnée
• Nécessité de cloner dans le cas dun appel
  asynchrone
• Mais le clonage reste plus efficace que dans le
  cas dun arbre dAny ordinaires

25
Tests de performances jeu de test

• Tests basés sur une séquence de structures
  complexes
• issue de code industriel réel (gestion des
  flots de trafic aérien)

• 21 champs élémentaires
• 25 nœuds
• x 20 000 structures

26
Tests de performances résultats

• Aller-retour de 20 000 structures
• Communication locale sur x86-linux
  (monoprocesseur)
• Sans Shadow Any 9,80 s
• Avec Shadow Any 4,53 s
• Gain de temps 53
• Contrepartie taille du code généré

27
Améliorations futures

• Sérialisation / désérialisation bypass
• Lorsque la représentation native est connue pour
  être conforme à la représentation réseau
• Possibilité de sérialiser / désérialiser par
  copie directe (car le shadow any connaît
  lemplacement mémoire de la structure de données)
• Suppose un moyen de faire passer linformation de
  représentation à travers la couche neutre
• Peut bénéficier de lassistance du générateur de
  code (production de clauses de représentation)
• Application à dautres personnalités de
  répartition
• Support à lexécution implémenté dans la couche
  neutre de PolyORB
• Génération de code spécifique des personnalités
  applicatives
• Réalisée pour CORBA (IDLAC, IAC)
• A implémenter pour DSA (GNAT)

28
Conclusion

• Pour les besoins de la fonction de représentation
  dun intergiciel schizophrène
• Le remplacement dun conteneur universel de
  données par un accesseur univesel
• Permet un gain significatif de performance.
• Implémenté dans un produit industriel, PolyORB
• http//www.adacore.com/
• http//libre.adacore.com/
• Justiciable daméliorations futures
• Extension à dautres personnalités applicatives
• Sérialisation bypass (actuellement pour les
  séquences de types élémentaires)