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

1. Représentation efficace des données dans un intergiciel schizophrène Thomas Quinot Séminaire Performance et GénéricitéLRDE, 5 novembre 2008 Senior software engineer, AdaCore

2. Plan • Contexte • L’architecture d’intergiciel schizophrène • Représentation neutre des interactions • Any, un conteneur universel typé • Structure d’Any • Fonction de représentation • Shadow Any, un accesseur structuré universel • Parcours pertinents dans la structure d’Any • Définition d’une structure propre à les fournir à moindre coût • Mise en œuvre • Shadow Any dans PolyORB/CORBA • Performances • Extensions • (Dé)Sérialisation bypass • Application à d’autres 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 d’erreurs • Exigences industrielles : • Domaines : avionique, espace, transport • Familles : sûreté, déterminisme, intégrité • L’intergiciel pour STRR doit s’adapter : • 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 l’expertise sur une plate-forme d’intergiciel Tout en prenant en compte de nouvelles exigences & normes ?

4. “Crise de l’intergiciel” • Exigences contradictoires sur l’intergiciel, élément clé de l’interaction • Configuration : • Adaptation à l’architecture cible • Genericité : • Adaptation du modèle de répartition aux besoins de l’application • Interoperabilité entre modèles de répartition • Paradoxe de l’intergiciel • Prise en compte des composants applicatifs hérités • Intégration des systèmes d’information • Élaboration de la confiance dans l’intergiciel • 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 l’intergiciel • Canaux de communication • Adaptation aux ressources et aux fonctionnalités de la plateforme d’exécution • Choix des fonctionnalités nécessaires pour l’application • Solutions : • Composants configurables • Agencement faiblement couplé par patrons de conceptionset frameworks • Pour chaque composant… • … choix d’une 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 l’assemblage 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 d’intergiciel générique • Exemples existants : • Jonathan/Quarterware • Frameworks pour la construction d’intergiciels • 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 l’intégration de l’existant • Exemples existants • Peu nombreux • CorbaWeb • Interoperabilié CORBA / web services • Objectif : offrir une solution efficace et unifiée

8. Intergiciel sûr • Exigence : l’utilisation d’un intergiciel ne remet pas en cause le déterminisme de l’application • Aspects concernés : • Vérification de la correction de l’intergiciel • Solutions: • Description formelle de l’intergiciel • Tests • Preuve de propriétés comportementales • Pas d’exemples 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. AWS (WEB) Personnalitésapplicatives CORBA (OOR) DSA (RPC) MOMA (MOM) DIOP (UDP) Personnalitésprotocolaires SOAP (XML) IIOP (TCP) MIOP (multicast) 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 d’un intergiciel générique pour un modèle de répartition donné • Créé à partir d’un ensemble restreint de composants réutilisables ou spécifiques Couche neutre Coeurd’intergiciel

11. Intergiciel schizophrène : une analogie Perso. applicative = Front-end • Couche neutre • « Cœur » de PolyORB • Similaire au langage intermédiaire d’un compilateur • Personnalités = front-ends et back-ends • Utilisation de patrons de conception pour la configurabilité • Configuration afin de satisfaire les exigences de l’application • 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 d’un intergiciel schizophrène • Généricité dans PolyORB => vue canonique des fonctions de l’intergiciel • 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 d’exécution pour traiter les événements générés par l’application ou l’extérieur, ordonnance les traitements, aiguille les requêtes, contrôle l’état global de l’intergiciel Network

13. App. code Reference Execution servant Addressing Activation request surrogate Binding coding Representation access pt Transport Protocol 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 l’opérations • Paramètres sous forme d’une 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 d’Any • 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. Elém Elém Elém Elém Elém Elém Agrégat Agrégat Construction naïve d’Any • Exemple : séquence de structures Agrégat Agrégat Elém Elém Elém

17. Elém Elém Elém Elém Elém Elém Agrégat Agrégat Sérialisation • Parcours en profondeur d’abord • Piloté par les TypeCodes à chaque nœud de l’arbre Séq (3) Agrégat Struct Agrégat Struct Struct El Elém El Elém El Elém El Elém El Elém El Elém El Elém El Elém El Elém 3 B V R B V R B V R

18. Elém Elém Elém Elém Elém Elém Agrégat Agrégat Désérialisation • A partir du TypeCode (connu à l’avance) • Et des données sérialisées • Reconstruction de l’arbre • Puis de la structure de données originale 3 B V R B V R B V R Séq Agrégat Struct Agrégat Struct Struct El Elém El Elém El Elém El Elém El Elém El Elém El Elém El Elém El Elém

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 d’Any • Pour les opérations de • Sérialisation • Désérialisation • … l’arbre est toujours parcouru en profondeur d’abord Pas de traitements globaux de l’arbre : une vue locale est suffisante

21. Shadow Any • Remplace l’agrégat générique par un type spécifique • Façade adossé à la donnée stockée réelle MaSéqStruct

22. Elém Elém Elém Elém Elém Elém 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 d’un 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 l’objet 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_Content’Class Création d’un contenu étranger (allocation gérée par le client) • {Get,Set}_Aggregate_Count • {Get,Set}_Aggregate_Element • By_Reference : Demande d’une façade pour mise à jour • By_Value : Demande d’une façade pour lecture • Au retour, si By_Value, l’appelant doit utiliser Set_Aggregate_Element pour mettre à jour (cas d’un discriminant ou d’une borne) • La durée de vie de l’Any doit être >= celle de la donnée • Nécessité de cloner dans le cas d’un appel asynchrone • Mais le clonage reste plus efficace que dans le cas d’un arbre d’Any 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 l’emplacement mémoire de la structure de données) • Suppose un moyen de faire passer l’information de représentation à travers la couche neutre • Peut bénéficier de l’assistance du générateur de code (production de clauses de représentation) • Application à d’autres personnalités de répartition • Support à l’exé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 d’un intergiciel schizophrène : • Le remplacement d’un 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 d’améliorations futures : • Extension à d’autres personnalités applicatives • Sérialisation bypass (actuellement pour les séquences de types élémentaires)