5© 2006, M. Riveill
Choses à considérer lorsqu'on
construit une application distribuée
Si on prend une application monolithique
Puis
on la transforme en application distribuée,
plusieurs clients se connectent sur plusieurs serveurs
Les serveurs utilisent plusieurs SGBD.
Que faut-il mettre en place ?
6© 2006, M. Riveill
Choses à considérer lorsqu'on
construit une application distribuée
Protocoles d'accès distants (CORBA, RMI, IIOP…)
Gestion de la charge,
Gestion des pannes,
Persistence, intégration au back-end,
Gestion des transactions,
Clustering,
Redéploiement à chaud,
Arrêt de serveurs sans interrompre l'application,
Gestion des traces, règlages (tuning and auditing),
Programmation multithread
Problèmes de nommage
Securité, performances,
Gestion des états
Cycle de vie des objets
Gestion des ressources (Resource pooling)
Requête par message (message-oriented midddleware)
7© 2006, M. Riveill
Qui s'occupe de tout ceci :
l’intergiciel (middleware) !
Dans le passé, la plupart des entreprises programmaient leur
propre intergiciel
Qui adressaient rarement tous les problèmes,
Qui demandait des compétences spécifiques,
Différentes du secteur d'activité de l'entreprise (banque, commerce…)
Difficulté de développement, de maintenance
Aujourd’hui, les entreprises achètent un produit
Oracle, IBM, BEA, …
proposent depuis plusieurs années des solutions…
Il y a aussi plusieurs proposition ‘libre’
Consortium ObjectWeb (Bull, France Telecom et l’INRIA)
Aujourd’hui les intergiciels intègrent : le web, l’accès aux données…
serveurs d'application.
8© 2006, M. Riveill
Serveur d'application : mutualiser les
compétences !
Un serveur d'application fournit les services
intergiciels les plus courants,
Transaction, sécurité, cycle de vie, …
Permettent de se focaliser sur l'application que l'on
développe, sans s'occuper du reste.
Le code est déployé sur le serveur d'application.
Séparation des métiers et des spécificités :
d'un côté la logique métier,
de l'autre les aspects techniques.