Introduction - Hébergements web

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 ClientServeur
– 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
}= 1
} = 10000
Exemple : annuaire des surnoms
ASN.1
et
norme
ISO
Protocole := CHOICE {
enregistrerReq [0] SEQUENCE{PrintableString nom,
PrintableString surnom}
enregistrerRep[1] BOOLEAN,
listerReq [2] NULL,
listerRep [3] SET OF Personnes, ….}
XDR et
RPC
de
SUN
Programme surnoms {
version {
boolean enregistrer(nomSurnom) = 1;
listePersonnes lister(void)=2
}= 1
} = 10000
Générateurs de Stubs
Spécifications
des données
XDR
ASN1
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 (x500, nis, dns…)
• Synchronisation (transaction …)
• Sécurité
Des Annuaires de Noms
Yellow Pages
X500
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
Objet2
Objet3
Objet1
Client
Client Serveur
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> ListePersonnes;
interface Surnoms{
exception ExisteDeja{string surnom;};
boolean enregistrer(in Personne personne) raises (ExisteDeja);
…..
};
};
1- Exemple introductif
Compilation interface IDL
Surnoms.idl
jidl Surnoms.idl
Client
StubForSurnoms.java
Client.java
Compilateur IDL/Java
Répertoire grid
Répertoire grid
Répertoire
grid
Répertoire
Surnoms
Surnoms.java
I
SurnomsHelper.java
SurnomsHolder.java
A écrire
Généré
Serveur
_SurnomsImplBase.java
SurnomsImpl.java
Serveur.java
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
Machine locale
Machine distante
InterfaceDistante
InterfaceDistante
Souche
Squelette
Appel méthode m()
Appel méthode m()
ClasseLocale
Remote
ClasseDistante
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
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 ("NameService");
CosNaming::
NamingContext
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 (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
Lookup : où est objetDistant ?
client
registre
Il est ici
result
Envoyez le stub
stub
Le voici
stub
result = objetDistant.m()
squelette
objet
Distant
RMIRegistry + ClassLoader
client
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 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 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
JavaSoft
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 : / 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 ….
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 (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é ?
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
III. Composants :
3. CORBA C.
Modèle abstrait de composant CORBA
réceptacle
*
Payer,
sélectionner,
prendre
Implémentation de facette
Facettes
Consommateur
Fournisseur
Ouvrir,
remplir,
mettre Monnaie…
Réparateur
Ouvrir capot,
fermer,
Température
On/Off
Puit d’évènements
Attributs
Prise de courant
Prise d’eau
Plus de monnaie
*
vide
Source d’évènements
30
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, J2EE
+ 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 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 middlewares
génériques (Jonathan, PolyOrb, ...)
Avoir une approche architecturale ?
des design patterns
Faire 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 pour
sortir les schémas communs
extérioriser quand et comment on les utilise
ne pas confondre les problèmes avec XML