Architecture des Applications Réticulaires

Transcription

1 Architecture des Applications Réticulaires Revision : 61 Christian Queinnec Université Paris 6 Deuxième vague

2 UPMC NI nov c C.Queinnec 2/25 Plan et tests 1 Maven Spring 2 Tests 3 Sécurité 4 Conclusions

3 UPMC NI nov c C.Queinnec 3/25 La tendance du moment : Convention over configuration. Maven Spring

4 UPMC NI nov c C.Queinnec 4/25 Maven Bien plus qu Ant (un make utilisant XML)! Normalisation du cycle de développement Normalisation de l organisation et de la dénomination des fichiers Dépôt de bibliothèques jar et leurs différentes versions pour satisfaire les dépendances Unique fichier de configuration pom.xml pour un unique but (un artefact) et un outil pour les joindre tous!

5 UPMC NI nov c C.Queinnec 5/25 Maven : pom < project > < modelversion >4.0.0 </ modelversion > < groupid >fr. upmc. aar </ groupid > < artifactid >Appl </ artifactid > < packaging >jar </ package > < version >1.0 - SNAPSHOT </ version > < dependencies... /> < developpers... /> < plugins... artefact a creer jdk a utiliser artefact a creer systeme d archivage (svn, mercurial,...)... /> </ project >

6 UPMC NI nov c C.Queinnec 6/25 Maven : organisation des fichiers./ pom. xml src / main / java / src / main / resources / src / main / webapp / src / test / java / src / test / resources / target / classes / target /test - classes /

7 UPMC NI nov c C.Queinnec 7/25 Maven : organisation du dépôt groupid / artifactid / version / artifactid - version artifactid - version. sha1 artifactid - version. pom artifactid - version. pom. sha1 junit / junit /3.8.1/ junit jar org / apache / maven / maven /2.0/ maven pom Dépôt central : http :// possibilité de dépôt d entreprise, de projet, etc.

8 UPMC NI nov c C.Queinnec 8/25 Maven : cycle de développement 21 phases : validate initialize generate-sources process-sources generate-resources process-resources compile process-classes generate-test-sources process-test-sources generate-test-resources process-test-resources test-compile test package preintegration-test integration-test post-integration-test verify install deploy

9 UPMC NI nov c C.Queinnec 9/25 Maven : greffons en tout genre Archétypes (génération de squelettes) génération de site Web reflétant la santé du projet (rapports JDepend, PMD, etc.)

10 UPMC NI nov c C.Queinnec 10/25 Spring Conteneur léger en remplacement des serveurs d application Usage d AOP (Aspect Oriented Programming) Intégration de logiciels tiers

11 UPMC NI nov c C.Queinnec 11/25 Architecture de Spring conteneur léger + moteur d AOP autres domaines : DAO Couplage objet-source de données ORM Couplage relationnel-objet JDBC Facilitation de connexion JDBC Context Interprète de configuration Web Cadre d intégration des logiciels Web MVC Le MVC de Spring Remoting masquage de RMI, Web services Scheduling ordonnancement de tâches et plein d autres projets reliés...

12 UPMC NI nov c C.Queinnec 12/25 Injection de dépendances Diminuer les couplages, séparer les préoccupations, faciliter les tests unitaires Injection par constructeur ou modificateur public class C { public class C { public X x; public IX x; public C () { public C() {} this.x = new X (...); public C(IX x) { } this.x = x; } } public setix (IX x) { this.x = x; } } // Dans configuration : // x = new X (); // c = new C(x); // ou // c. setix (x);

13 Conteneur léger Le conteneur léger joue le rôle d un annuaire de Beans, il est obtenable de partout et est paramétré par un fichier applicationcontext.xml. Il est instrumentable ainsi qu un support de transmission d événements. <beans... > <!-- c == > new C() --> <bean id= c class = C name = autres, noms singleton = true lazy - init = true autowire = byname dependency - check = all > <constructor - arg type = int ><value > possible </ value <!-- c. setix (x) --> < property name = IX ref = x /> < property name = truc > < value >... toute sorte de valeur y compris liste, table associative, etc. </ value > </ property > </ bean > <!-- et encore plein de beans > </ beans > UPMC NI nov c C.Queinnec 13/25

14 UPMC NI nov c C.Queinnec 14/25 Programmation par aspects Dans la droite lignée des systèmes de macro de Lisp : manipulation d arbres de syntaxe (en jargon : tissage) Un aspect est une description d un traitement à opérer sur des sources (les sources ne dépendent ainsi pas de l aspect). Un aspect décrit les points où opérer (en jargon join point) et le traitement à effectuer (advice). les points où opérer sont réduits en Spring aux appels de méthodes et aux définitions de classes le traitement enveloppe la méthode d un traitement before, after returning, after throwing et around. le traitement peut aussi ajouter des interfaces et des méthodes (implanté par java.reflect.proxy)

15 UPMC NI nov c C.Queinnec 15/25 Exemples de programmation par aspects Pour tout appel à la méthode nommée m(), tourner bean1.m2() avant (ou après ou à la place (proceed() pour retrouver ce qu il aurait fallu faire) À l instanciation de IX, instancier en fait subix étendant IX avec des interfaces ou méthodes additionnelles. On peut soit travailler au niveau des AST ou instrumenter le code-octet.

16 UPMC NI nov c C.Queinnec 16/25 Intégration d autres patrons Intégration de Struts, GWT, Ajax, Hibernate, JMS, etc. Ajout de classes de confort pour assurer l usage de Beans ou de POJO, la configuration des dépendances ou encore des aspects simplificateurs de code (gestion de transactions par ex.)

17 UPMC NI nov c C.Queinnec 17/25 Tests Tests De multiples points de tests : Selenium IDE LWP, HttpUnit Findbugs,JDepend,PMD Perl:Critic,Test::More Cactus junit cohérence Contrôle JS GreaseMonkey Firebug tests de charge tests de sécurité Vue Modèle Cactus

18 UPMC NI nov c C.Queinnec 18/25 de test Tests Côté serveur : GWT a son propre mécanisme à base de Junit Cf. aussi Cactus Comme un client en Perl : LWP, WWW : :Mechanize en Java : HttpUnit, HtmlUnit, JWebUnit Selenium IDE FireBug, GreaseMonkey

19 Authentification HTTP Sécurité Accès à une zone protégée : > GET url < unauthorized WWW - Authenticate : Basic realm =" Secret UPMC " > GET url Authorization : Basic base64("user :password") < page (en clair!) > GET url / sousurl Authorization : Basic base64("user :password") < page (en clair!) liberté du client pour la demande de nom/mot de passe. liberté du serveur de la vérification nom/mot de passe (fichier, base n?dbm, base de données, etc.) Pas de déconnexion prévue. Autre méthode : Digest (avec défi ou nonce). UPMC NI nov c C.Queinnec 19/25

20 UPMC NI nov c C.Queinnec 20/25 Authentification HTTPS Sécurité Côté serveur httpd : imposer une connexion chiffrée SSLv3, TLS imposer que le client s authentifie avec un certificat faire toute sorte de vérification sur ce certificat

21 UPMC NI nov c C.Queinnec 21/25 Authentification SSO Sécurité Authentification (single sign on), CAS, OpenId 307 CAS,OpenID auth form 307+cookie checkcookie getprofileinfo

22 UPMC NI nov c C.Queinnec 22/25 Principes sécuritaires Sécurité D après Open Web Application Security Project : Minimiser la surface attaquable Choix sûrs par défaut Moindre privilège Défense en profondeur Rattrapage d erreur sûr Séparation des rôles Pas de sécurité par obscurité Simplicité Automatisation des tests de correction de vulnérabilité

23 UPMC NI nov c C.Queinnec 23/25 Attaques (nombreuses) Sécurité sql injection exemple (surtout en PHP) : select * from T where nom = $info avec info= or true or = ne jamais faire confiance aux informations provenant des utilisateurs filtrer (black, white lists) select * from T where nom =? langages teintés (Perl) xss (Cross Site Scripting) 1 X injecte du javascript J dans un texte stocké côté serveur S 2 A reçoit de S le texte et exécute le javascript J 3 J peut engendrer une requête vers un site S qui sera émise avec les cookies de A 4 J peut renvoyer à X les résultats obtenus

24 UPMC NI nov c C.Queinnec 24/25 Grand schéma Conclusions Un grand tour depuis les bases jusqu aux clients en passant par les serveurs : ressources statiques Contrôle Vue Modèle service (SOAP,...) Contrôle Vue Modèle Ressources (REST) dynamiques Contrôle relais (Gears) Vue Modèle

25 UPMC NI nov c C.Queinnec 25/25 Conclusions Conclusions Un grand tour depuis les bases jusqu aux clients en passant par les serveurs Comment choisir ses patrons de conception? Différents patrons pour différents types d application Indicateurs externes (livres, support, communauté, caractéristiques, risques, etc.) Prototyper (au moins 2 ou 3 si possible)! Lien : ComparingJVMWebFrameworks