View
53
Download
0
Category
Preview:
DESCRIPTION
Objets Distribués et Composants. Les applications actuelles et futures Cours ESSI3 SAR5. 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 - PowerPoint PPT Presentation
Citation preview
Objets Distribuéset Composants
Les applications actuelles et futures
Cours ESSI3 SAR5
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 messagesEncapsulation et InterfaceHé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 objetssubstitution 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 à distanceImportance du marshallingDes serveurs accessibles simultanément par plusieurs clientsEnregistrement des serveurs dans des annuaires de nomsCommunication connectée ou par message…..
Langages de spécifications
• Spécifications des types de données qui transitent sur le réseau
• XDR et RPC de SUN
Protocole := CHOICE { requete [0] REQUETE, reponse [1] REPONSE }
Programme reqrep { version {
REPONSE rerep(REQUETE) = 1 }= 1} = 10000
ASN.1 et norme ISO
Exemple : annuaire des surnoms
XDR et RPC de SUN
Protocole := CHOICE { enregistrerReq [0] SEQUENCE{PrintableString nom,
PrintableString surnom} enregistrerRep[1] BOOLEAN, listerReq [2] NULL, listerRep [3] SET OF Personnes, ….}
Programme surnoms { version {
boolean enregistrer(nomSurnom) = 1; listePersonnes lister(void)=2 }= 1} = 10000
ASN.1 et norme ISO
Générateurs de Stubs
RPCGEN / MAVROS
ASN1 XDR
Librairie marshalling et unmarshalling
squelettes du client et du serveur
Spécificationsdes données
Générateurs
Types de donnéesC Lisp Java
Types de données
C
Fichiersgénérés
Circulation de messages et machines hétérogènes
• Couche de services
• Objets de l’application qui résultent de la conception du modèle
• Couche de transport
• Responsable de l’administration des objets et de l’acheminement des messages
Infrastructure informatique de distribution
Introduction de services
• Gestionnaires de noms (x500, nis, dns…)
• Synchronisation (transaction …)
• Sécurité
Des Annuaires de Noms
Yellow Pages
X500
LDAP
CLIENT SERVEUR
Transport TCP IP...
Service (marshalling..)
transaction sécurité nommage
Infrastructure ?
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
Client Client Serveur Serveur
Objet1
Objet2 Objet3
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
• au moins une interface : Iunknown
• non transmissible par héritage
• composition d’interfaces
• héritage de classe • implémentation de plusieurs interfaces possibles
Générateurs
RMIC / Orbix...
IDL Int. JavaSpécificationsdes données
Générateurs
Fichiersgénérés Stubs Skeletons Proxy
(mise en œuvre de la sérialisationet désérialisation…)
CORBA
module Surnoms {
typedef string Nom ;
struct Personne {Nom nom;
string surnom;};
typedef sequence<Personne> ListePersonnes;
interface Surnoms{
exception ExisteDeja{string surnom;};
boolean enregistrer(in Personne personne) raises (ExisteDeja);
…..
};
};
Surnoms.java
Compilation interface IDL
Client
StubForSurnoms.java _SurnomsImplBase.java
Serveur
SurnomsImpl.javaClient.java
Serveur.java
A écrireGénéré
1- Exemple introductif
Surnoms.idl
Compilateur IDL/Java
Répertoire gridRépertoire grid
Répertoire gridRépertoire Surnoms
I
SurnomsHelper.java
SurnomsHolder.java
jidl Surnoms.idl
RMI
public interface Surnoms extends java.rmi.Remote{public Boolean enregistrer(String nom, String surnom) throws
java.rmi.RemoteException, ServeurSurnoms.surnoms.ExisteDeja ;
…. }
RMI
Classes et Interfaces
ClasseLocale
Souche Squelette
ClasseDistante
InterfaceDistante
Remote
Appel méthode m() Appel méthode m()
Machine locale Machine distante
InterfaceDistante
Comment activer des objets distribués ?
• Messages échangés entre objets =– Requêtes ou Résultats
• Certains envois de messages n’attendent pas de résultats
• Requête = Destinataire + nom de méthode + Paramètres
• Résultat = Donnée ou indication d’une erreur ou d’une défaillance
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
Invoquer les services dont il a besoin par envoi de requêtes
Accès à l’objet destinataire par une référence à son implémentation par l’interface
Rôle du client
Unités autonomes - solidité - robustesse - adaptation
ID
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
ORB pour CORBAnorme Corba 1
DCOM pour OLEnon formelle
JDK
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 ORBset entre ORB et COM
Scénario d ’obtention de la référence du service de nommage
Client ou Serveur ORB
CosNaming::NamingContext
resolve_initial_references ("NameService");
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 Type1. Créer un objet2. 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 (NotFound, CannotProceed, InvalidName, AlreadyBound);
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 (NotFound, CannotProceed, InvalidName)
Interaction Client Enregistreur
client serveur
client registreLookup : où est objetDistant ?
stub
Il est ici
Envoyez le stub
Le voicistub squelette
objetDistant
result = objetDistant.m()
result
RMIRegistry + ClassLoader
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 stub + skeleton– En OLE
• appel direct si in process
• proxy + stub si application fournis uniquement pour les applications MicroSoft
• 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 JavaSecurité,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 uniqueTransport : pour établir une communication entre 2 nœuds et transmettre une requêteMarshalling :transformation de la requête pour passer sur leréseau
Les points communs des middlewares en objets distribués
(aspect réseau)
Activation :activer les implémentations des objetsDispatching :gestion des threadsProtocol :transmission des requêtes entre exécutablesDes services communsServices 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'objetInterface :Permettre l'évolution du codeHéritage / Composition :Gérer les versionsEnvoi de messagesPrivilégier les communications synchrones
Un bref comparatif
Origine Microsoft OMG JavaSoft
Archi COMDCOM
IDL ORBIIOP
Java RMIApplet
Interfaces IUNKnownprédéfinies
Définies enIDL
Définies enJava
Un bref comparatif
Interface+ Agrégationcomposition
Héritage Héritageextends
Langage C++ C C++Smalltalk
Java
Infrastr. Proxystub
Stubskeleton
ProxyR O
Un bref comparatif
Serveur AppliDLL
AppliBiblioBDD
Appli Java
Client AppliDLL
AppliBiblioBDD
Appli JavaApplets
Création IFactory Instanciéen LOO
InstanciéEn Java
Un bref comparatif
Appeldyn.
IDispatch DII Introsp.beans
Ident. Reg. OLE Service denommage
URL
Comm. DCOMDCE
IIOP RMI(TCP/IP)
Des objets distribués aux composants
Chronique d’une invasion annoncée
Pourquoi? Comment?
Qui : / Corba3 CCM/ Web Services
(.net, J2EE) / 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 : OpenCCM,Fractal ….
• 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
Un Service Web, c’est quoi ?
Architecture globale
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
Points communs avec les middlewares objets
AnnuaireUDDI
ClientXMLXML
5 : J’ai compris comment invoquer5 : J’ai compris comment invoquerton service et je t’envoie un documentton service et je t’envoie un document
XML représentant ma requêteXML représentant ma requête
Serveur
2 : J’ai trouvé! Voici le serveur2 : J’ai trouvé! Voici le serveurhébergeant ce service webhébergeant ce service web
3 : Quel est le format d’appel du3 : Quel est le format d’appel duservice que tu proposes? service que tu proposes?
ContratSOAP
ContratSOAP
4 : Voici mon contrat (WSDL)4 : Voici mon contrat (WSDL)
XMLXML
XMLXML
6 : J’ai exécuté ta requête et je te retourne le résultat6 : J’ai exécuté ta requête et je te retourne le résultat
1 :
Je r
ech
erch
e1
: Je
rec
her
che
un
ser
vice
WE
B
un
ser
vice
WE
B
Cycle de vie d’utilisation
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 (W3C)
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é ?
• 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
Un composant, c’est quoi ?
Exemple des différents éléments
25
Création et utilisation de Bank
Client
Server
JNDI
BankHomeImpl
bh: BankHome
Context
1: bh = lookup()
1.1: lookup()
b : Bank
BankBean
2.3.1: new()2.3.2 setSessionContext()2.3.3 ebjCreate()
2: b = create()
2.1: create()
2.2: create()
3: deposit()3.1: deposit() 3.2: deposit()
III. Composants : 2. EJB
E
Exemple de modèle de composant
30
Modèle abstrait de composant CORBA
Imp
lém
enta
tion
de fa
cette
ConsommateurPayer,
sélectionner, prendre
Ouvrir,remplir,
mettre Monnaie…
Fournisseur
Ouvrir capot, fermer,
Réparateur
Fa
cett
es
réceptacle
Prise de courant
Prise d’eau
*
Plus de monnaie
vide
*Température
Source d’évènementsPuit d’évènements
On/Off
Attributs
III. Composants : 3. CORBA C.
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 inrastructures, 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, J2EE + Web Services, .net ....
Savoir les comparerIdentifier les points communsInteropé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 QoS ou non ?(transaction, sécurité ....)
Comment faire interopérer les middlewares ?
Aller vers un middleware standard ? (J2EE / Corba)
Construire une couche au dessus des middlewares ? des familles de middlewares, des middlewaresgénériques (Jonathan, PolyOrb, ...)Avoir une approche architecturale ?
des design patternsFaire interopérer des middlewares existants?
M2M
L’avenir ?
Après les approches par composants,des middlewares au dessus de JMS
Une réflexion de plus haut niveau poursortir les schémas communsextérioriser quand et comment on les utilise
ne pas confondre les problèmes avec XML
Recommended