Objets Distribus et Composants Les applications actuelles et

Objets Distribués et Composants Les applications actuelles et futures Cours Harmonisation

Chronique d’une invasion annoncée Pourquoi? Comment? Qui : Corba / COM-DCOM / Java RMI…

Pourquoi ? • Maturation de la technologie orientée objet – ADA, Modula – Smalltalk , C++, Java • Maturation des communications Client. Serveur – sockets – RPC – couches OSI

L’héritage de la programmation par objets Communication par envoi de messages Encapsulation et Interface Héritage et Composition

Objets = briques logicielles • Assembler des briques élémentaires • Réduire la complexité des systèmes d’information Séparation entre interface et implémentation Représentation et types de données Mécanismes d’abstraction

Séparation entre interface et implémentation • séparation de la définition et de l’implémentation : encapsulation • interface : partie visible de l’objet • implémentation : partie privée inaccessible depuis d’autres objets • interface = contrat entre l’objet et le monde extérieur

Séparation entre interface et implémentation • Assemblage des objets dépend uniquement des interfaces, le changement local d’un objet ne perturbe pas l’ensemble de l’application. Importance de la nomenclature des objets substitution logique liée à la substitution physique

Représentation et Types de données • Définition de nouveaux types • Choix d’un type pour une donnée (ex. montant) devient une contrainte sur la conception. Types de données Abstraits considérés comme des types de base

Mécanismes d’abstraction • Abstraction des données : essence du procédé de construction de systèmes d ’information à base d ’objets distribués • par Classe et/ou Composition Des mises en œuvre différentes selon les cas

L’héritage de la programmation Client Serveur Appel de procédures à distance Importance du marshalling Des serveurs accessibles simultanément par plusieurs clients Enregistrement des serveurs dans des annuaires de noms Communication connectée ou par message…. .

Langages de spécifications • Spécifications des types de données qui transitent sur le réseau Protocole : = CHOICE { requete [0] REQUETE, reponse [1] REPONSE } ASN. 1 et norme ISO • XDR et RPC de SUN Programme reqrep { version { REPONSE rerep(REQUETE) = 1 } = 10000

Exemple : annuaire des surnoms ASN. 1 et norme ISO Protocole : = CHOICE { enregistrer. Req [0] SEQUENCE{Printable. String nom, Printable. String surnom} enregistrer. Rep[1] BOOLEAN, lister. Req [2] NULL, lister. Rep [3] SET OF Personnes, …. } XDR et RPC de SUN Programme surnoms { version { boolean enregistrer(nom. Surnom) = 1; liste. Personnes lister(void)=2 }= 1 } = 10000

Générateurs de Stubs Spécifications des données XDR ASN 1 Générateurs RPCGEN / MAVROS Fichiers Types de générés données C Lisp Java Librairie marshalling et unmarshalling squelettes du client et du serveur Types de données C

Circulation de messages et machines hétérogènes Infrastructure informatique de distribution • Couche de services • Couche de transport • Objets de l’application qui résultent de la conception du modèle • Responsable de l’administration des objets et de l’acheminement des messages

Introduction de services • Gestionnaires de noms (x 500, nis, dns…) • Synchronisation (transaction …) • Sécurité

Des Annuaires de Noms Yellow Pages X 500 LDAP

Infrastructure ? CLIENT SERVEUR transaction sécurité nommage Service (marshalling. . ) Transport TCP IP. . .

Objets distribués • Un programme (objet) peut être à la fois client de certains serveurs et serveur d’autres clients • Il peut y avoir reconfiguration dynamique des rôles Client Serveur

Infrastructure Objets Distribués Objet 2 Objet 3 Objet 1 Client Serveur

Implémentation des objets distribués • Corba indépendant des langages de programmation • Projections C, C++, Java • Un langage de Spécification IDL • Orienté C++ Tout Java

CORBA, DCOM et JAVA • une interface = une unité élémentaire • héritage des interfaces • aucune interface imposée • normalisation des interface • héritage • au moins une interface : Iunknown • non transmissible par héritage • composition d’interfaces de classe • implémentation de plusieurs interfaces possibles

Générateurs Spécifications des données Int. Java IDL Générateurs RMIC / Orbix. . . Fichiers générés Stubs Skeletons Proxy (mise en œuvre de la sérialisation et désérialisation…)

CORBA module Surnoms { typedef string Nom ; struct Personne {Nom nom; string surnom; }; typedef sequence<Personne> Liste. Personnes; interface Surnoms{ exception Existe. Deja{string surnom; }; boolean enregistrer(in Personne personne) raises (Existe. Deja); …. . }; };

1 - Exemple introductif Compilation interface IDL Surnoms. idl jidl Surnoms. idl Client Stub. For. Surnoms. java Client. java Compilateur IDL/Java Répertoire grid Répertoire Surnoms. java I Surnoms. Helper. java Surnoms. Holder. java A écrire Généré Serveur _Surnoms. Impl. Base. java Surnoms. Impl. java Serveur. java

RMI public interface Surnoms extends java. rmi. Remote { public Boolean enregistrer(String nom, String surnom) throws java. rmi. Remote. Exception, Serveur. Surnoms. surnoms. Existe. Deja ; …. }

RMI Classes et Interfaces Machine locale Machine distante Interface. Distante Souche Squelette Appel méthode m() Classe. Locale Remote Classe. Distante

Comment activer des objets distribués ?

Comment activer des objets distribués ? • Mécanisme d’exécution ou de transport – définit comment les messages sont véhiculés de l’objet client vers l’objet serveur (destinataire) – retrouver et activer les objets adéquats • Un objet client a deux manières d’envoyer des messages – invocation statique – invocation dynamique

Invocation statique • Le nom de l’objet destinataire et le message sont connus au moment du développement • Ne permet ni l’ajout ni le retrait d’objets dans les serveurs

Invocation dynamique • Permet au programme client de – découvrir les objets à l’exécution et les interfaces proposés par ces objets – construire dynamiquement messages et requêtes – envoyer et recevoir le résultat de telles requêtes • Rend les systèmes réactifs et faciles à modifier OFFERT PAR CORBA, DCOM et JAVA

L’invocation dynamique • API (DII) de construction de requêtes – sans passer par des souches prégénérées • Un objet Request = un nom d’opération, une liste de couples valeur - type (au sens de l’IR) et une structure pour le résultat – invoke – send_deferred + get_response, poll_response – send_oneway

Invocation dynamique + surcharge • flexibilité du code • briques logicielles avec les mêmes messages pour des objets de différentes natures – définir de nouveaux objets sans modifier l’interface – changements qui n’affectent pas les clients

Rôle du client Invoquer les services dont il a besoin par envoi de requêtes ID Accès à l’objet destinataire par une référence à son implémentation par l’interface Unités autonomes - solidité robustesse - adaptation

Rôle de l’infrastructure • administre les implémentations, la création et la destruction d’objets • réceptionne les requêtes, localise le serveur, vérifie son état et celui du destinataire • active au besoin le serveur, lui envoie les données de la requête • ramène les résultats au client • doit être informée de l’arrêt d’un serveur • doit gérer la persistance

Rôle du serveur • Administrer un flot de requêtes pour un ou plusieurs objets dont il a la responsabilité • Ordonnancer la séquence des opérations de réponses à une requête

Rôle du serveur d’objets • • active si besoin l’objet destinataire recherche et exécute la méthode passe le résultat à l’infrastructure plusieurs requêtes peuvent arriver simultanément • arrêt du serveur : désactiver tous les objets et enregistrer leur état

Un peu plus sur l’infrastructure • transport des messages • localisation des serveurs et des objets • persistance JDK ORB pour CORBA norme Corba 1 DCOM pour OLE non formelle

Transport des messages • Références aux objets – identifiant (libre choix d ’implémentation dans le norme CORBA) – nombres codés sur 128 bits en OLE – url Uniform Resource Locator en Java RMI Performances différentes et incompatibilités entre ORBs et entre ORB et COM

Scénario d ’obtention de la référence du service de nommage ORB Client ou Serveur resolve_initial_references ("Name. Service"); Cos. Naming: : Naming. Context conversion ajout, retrait, lecture, . . .

Enregistrer un objet • Opération pour publier un Objet – en général, opération réalisée par le serveur • Scénario Type 1. Créer un objet 2. Construire un chemin d ’accès (Name) 3. Appeler l ’opération « bind » ou « rebind » avec le chemin et la référence de l ’objet void bind (in Name n, in Object obj) raises (Not. Found, Cannot. Proceed, Invalid. Name, Already. Bound);

Retrouver un objet • Opération réalisée par un client ou un serveur • Scénario type : – construire un chemin d ’accès (Name) – appeler l ’opération « resolve » avec le chemin – convertir la référence obtenue dans le bon type Object resolve (in Name n) raises (Not. Found, Cannot. Proceed, Invalid. Name)

Interaction Client Enregistreur Lookup : où est objet. Distant ? client registre Il est ici result stub Envoyez le stub Le voici result = objet. Distant. m() RMIRegistry + Class. Loader client stub squelette objet Distant serveur

Interface avec l’infrastructure Un peu de vocabulaire • Coté client : – stub en CORBA – proxy en OLE – stub/proxy en Java • Côté Serveur : – stub en OLE – skeleton en CORBA – implémentation d’une interface en RMI • BOA Objects Adaptaters

Mécanisme de Transport : Client - Serveur • Appel direct : DLL (in process - utilisation du même espace mémoire) • Appel indirect : – LRPC (application sur la même machine) passe par le proxy – RPC (sur 2 machines différentes) • IIOP en Corba

Invocations • Invocations statiques – IDL en CORBA – En OLE stub + skeleton • appel direct si in process • proxy + stub si application fournis uniquement pour les applications Micro. Soft • Versions récentes définition du langage ODL • IDL et ODL sont incompatibles

Invocations • Invocations dynamiques – DII en CORBA – IDispatch en OLE – java reflect • Du ressort de l’infrastructure

CORBA vs OLE • définition du serveur très générale laissée à l’implémentation • flexibilité primordiale pour l’intégration de systèmes (BDD…) • processus formel avec l’OMG • un serveur est une application ou une DLL • stratégie commerciale et pratique

Services et Objets Distribués • Services normalisés • Seulement certains sont implémentés • Naming, Trading, Event • Le programmeur doit les connecter… Des services en Programmant avec Java Securité, Threads, Événements Url et Web Non intégrés à RMI

Les points communs des middlewares en objets distribués (aspect réseau) Adressage : à tout objet doit être affecté une référence unique Transport : pour établir une communication entre 2 nœuds et transmettre une requête Marshalling : transformation de la requête pour passer sur le réseau

Les points communs des middlewares en objets distribués (aspect réseau) Activation : activer les implémentations des objets Dispatching : gestion des threads Protocol : transmission des requêtes entre exécutables Des services communs Services de nommage, Interface repository. . .

Les points communs des middlewares en objets distribués (aspect objet) Encapsulation : Interdire l'accès direct au contenu de l'objet Interface : Permettre l'évolution du code Héritage / Composition : Gérer les versions Envoi de messages Privilégier les communications synchrones

Un bref comparatif Origine Microsoft OMG Java. Soft Archi COM DCOM IDL ORB IIOP Java RMI Applet Interfaces IUNKnown Définies en prédéfinies IDL Définies en Java

Un bref comparatif Interface+ Agrégation Héritage composition Héritage extends Langage C++ C C++ Smalltalk Java Infrastr. Proxy stub Stub skeleton Proxy RO

Un bref comparatif Serveur Appli DLL Appli Biblio BDD Appli Java Client Appli DLL Appli Biblio BDD Appli Java Applets Création IFactory Instancié en LOO Instancié En Java

Un bref comparatif Appel dyn. IDispatch DII Introsp. beans Ident. Reg. OLE Service de nommage URL Comm. DCOM DCE IIOP RMI (TCP/IP)

Des objets distribués aux composants Chronique d’une invasion annoncée Pourquoi? Comment? Qui : / Corba 3 CCM/ Web Services (. net, J 2 EE) / EJBs …

Quels Composants ? Une vision « simplifiée » : les Web Services Des composants « normalisés » : CCM Des composants pratiques : EJB Et tout ce que l'avenir nous réserve : Open. CCM, Fractal ….

Un Service Web, c’est quoi ? • • Une « unité logique applicative » Une «librairie» fournissant des données et des services à d’autres applications. Un objet métier déployé sur le web (vision objet) Un « module » ou « composant » (Application avec JAX-RPC : un composant simple avec une interface RMI ) Ø Une sorte d'objet… plutôt qu'un composant

Architecture globale

Points communs avec les middlewares objets Un langage de description : WSDL Une infrastructure : Le Web et http Une communication par envoi de messages : SOAP Du marshalling : XML Un service de nommage « dynamique » : UDDI

Cycle de vie d’utilisation Annuaire UDDI 2 : J’ai trouvé! Voici le serveur hébergeant ce service web 1 : Je recherche un service WEB 3 : Quel est le format d’appel du service que tu proposes? Contrat SOAP 4 : Voici mon contrat (WSDL) XML Client XML Serveur 5 : J’ai compris comment invoquer ton service et je t’envoie un document XML représentant ma requête XML 6 : J’ai exécuté ta requête et je te retourne le résultat

Cycle de vie plus complet… • Déploiement du service Web • Enregistrement du service Web • Découverte du service Web • Invocation du service Web par le client

Pour être de vrais composants… - Description des interfaces requises - Langage pour gérer le flux d’exécution : WSFL - des services spécifiques - sécurité (SAML, …) - transactions (BTP, …) - une découverte des services web (W 3 C)

Des environnements intégrés. net • Toute la mécanique est cachée • On peut se concentrer sur la conception • Aide à l'assemblage ? • Des adeptes et des sceptiques – Passage à l'échelle ? – Evolution ? – Interopérabilité ?

Un composant, c’est quoi ? • Une brique permettant la programmation par assemblage • Une solution facilitant le déploiement, la gestion du cycle de vie des applications logicielles • Une meilleure intégration des services Ø plus qu'un objet

Exemple des différents éléments E

Exemple de modèle de composant

EJB – CORBA 3: Points communs avec les middlewares objets Langages de description : CIDL ou Interfaces Java Infrastructure : RMI / ORB Marshalling : repose sur Corba / RMI Nommage : Home ++ Interface : Héritage + Composition

EJB – CORBA 3: Apports Interfaces entrées et sorties : ports requis et offerts Conteneur : intégration des propriétés non Fonctionnelles (sécurité, persistance, transaction) Home : fabrique et navigation Communication par envoi de message et notification (événement)

Un vrai cycle de vie • Fichier de déploiement • Packaging d'assemblage Approche déclarative basée sur XML

Prochaine invasion dans la lignée ? Approche composant revisitée : Open CCM : une meilleure solution CCM + MDA (+ d'abstraction des infrastructures, projections vers des middlewares connus…) Des Composants à conteneurs ouverts (travaux de recherche) Des composants adaptables (fractal)

Les problèmes à résoudre encore • Problèmes d’interopérabilité – RMI et Corba en Java – entre le monde Microsoft et le reste • Arrivée des Web Services : la solution ? • Les composants encore nouveaux…. – les Enterprise Java Beans – Corba Components – et aussi C# et net

Les plus grosses difficultés • Sont conceptuelles – Comment choisir les composants adaptés ? (manque de sémantique, Web sémantique) – Comment accepter plus de services ? (propriétés non fonctionnelles) Etre plus architecte que programmeur ….

Quelques interrogations ? Comment choisir le bon middleware (intergiciel) ? Il y en a de plus en plus Corba, RMI, DCOM, DSA + CCM, J 2 EE + Web Services, . net. . Savoir les comparer Identifier les points communs Interopérabilité : XML une solution suffisante ?

Des Critères de Comparaisons Autour du concept objet ? Communication synchrone ou asynchrone ? Description via des interfaces ou des messages ? Communication directe ou indirecte ? Spécifique ou indépendant langage ? Possibilité de transformation de messages ou non ? Protocole de communication binaire ou textuelle ? Prise en compte de Qo. S ou non ? (transaction, sécurité. . )

Comment faire interopérer les middlewares ? Aller vers un middleware standard ? (J 2 EE / Corba) Construire une couche au dessus des middlewares ? des familles de middlewares, des middlewares génériques (Jonathan, Poly. Orb, . . . ) Avoir une approche architecturale ? design patterns Faire interopérer des middlewares existants? M 2 M

L’avenir ? Après les approches par composants, des middlewares au dessus de JMS Une réflexion de plus haut niveau pour sortir les schémas communs extérioriser quand et comment on les utilise ne pas confondre les problèmes avec XML