Ejb advanced2010

285 views
251 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
285
On SlideShare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
14
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Ejb advanced2010

  1. 1. 09/12/2010EJB avancés Objectif : Etudier la configuration du contexte d’exécution  Sa mise en œuvre implicite  Et explicite Transactions Sécurité Timer Récapitulatif PerformancesLes transactions Concept fondamental dans les applications distribuées Indispensables pour une exécution sûre des services Difficiles à mettre en œuvre Problèmes de performances 1
  2. 2. 09/12/2010Atomicité Garantir une exécution tout ou rien Difficile sur un système centralisé Encore plus dans une architecture distribuée  Nombreuses possibilités derreursConcurrence daccès Cause de nombreux problèmes Comment garantir des exécutions correctes ? Et des performances acceptables ? 2
  3. 3. 09/12/2010Les propriétés ACID Atomicité Consistence Isolation DurabilitéLes modèles de transactions Flat Nested Flexible Distributed ... 3
  4. 4. 09/12/2010Flat TransactionsNested Transaction 4
  5. 5. 09/12/2010Distributed TransactionJava Transaction Service Fournit linterface avec des moniteurs transactionnels  Communication avec les moniteurs (XAResource)  Communication avec les serveurs dapplication (TransactionManager)  Communication avec les clients (UserTransaction) 5
  6. 6. 09/12/2010Transactions et EJB Container Managed  Le container se charge de tout  Approche déclarative Bean Managed  Transaction gérée par programme dans les beans Client Controlled  Transaction programmée du coté clientBean Managed 6
  7. 7. 09/12/2010Container ManagedClient Controlled 7
  8. 8. 09/12/2010Gérer la visibilité des transactions ?Les attributs de transaction (Containermanaged) 8
  9. 9. 09/12/2010ExempleTransactions et types de beans 9
  10. 10. 09/12/2010Linterface UserTransactionStatut des transactions 10
  11. 11. 09/12/2010Utilisation dans un client Encore de linjectionLisolation Garantir la cohérence des accès concurrent  Sérialisabilité (les exécutions concurrentes sont équivalentes à des exécutions en série) Problèmes classiques  Lecture impropre  Perte de mise à jour Utilisations de verrous mais  Deadlock  Pénalités sur les performances 11
  12. 12. 09/12/2010Les niveaux disolation READ UNCOMMITED  Pas disolation – on voit tout – on ne tient pas compte des verrous en lecture READ COMMITED  On ne lit que des résultats commités – mais lectures non répétables REPEATABLE READ  Les lectures sont répétables mais lecture fantomes (nouvelles données en cours de transaction) SERIALIZABLE Mise en oeuvre dépendante des serveurs dapplication et des base de donnéesContainer Managed Concurrency 12
  13. 13. 09/12/2010Concurrent access + TimeoutBean Managed Concurrency 13
  14. 14. 09/12/2010Contrôle optimiste ou pessimiste Pessimiste : on évite les problèmes à priori  Problèmes de performance Optimiste : on vérifie a posteriori quil ny en a pas eu  Meilleure performance  Risque de perdre du travailConclusion Les transactions sont faciles à mettre en oeuvre Mais difficile à contrôler  Quelles garanties on veut avoir ?  Quels scénarios sont les plus probables ?  Quels compromis entre performances et sureté de lexécution sont acceptables ? 14
  15. 15. 09/12/2010La sécurité Aspect fondamental des applications distribuées Quels sont les risques ? Quels sont les parties critiques de lapplicationLes fonctions Authentification  Est-tu bien celui que tu prétends être ? Autorisation  As-tu bien le droit de faire ça ? Intégrité des données  Les données peuvent elles être modifiées Confidentialité des données  As-tu le droit de lire ces données ? 15
  16. 16. 09/12/2010Sécurité des applications Web Premier point dinteractions avec les utilisateurs Dépend des specs servlet et J2EE 3 modes dauthentification  HTTP Basic and Digest  Form Based  HTTPS Client authentification (certificat) 16
  17. 17. 09/12/2010Autorisation dans les applications Web Déclarative  Règles de sécurité dans le descripteur Programmée  Contrôles de sécurité dans les servlets  Contexte de sécuritéConfidentialité/Intégrité Basé sur un transport sécurisé (HTTPS) Contraintes dans le descripteur de déploiement (CONFIDENTIAL, INTEGRAL, NONE) 17
  18. 18. 09/12/2010Sécurité dans les EJB Authentification basée sur JAAS  Java Authentication and autorisation ServiceSubject Container pour principal et credentials The Subject in Detail Principal Principal Principal Public Public Credential Subject Public Credential Credential Private Private Credential Private Credential Credential 18
  19. 19. 09/12/2010Principal Identifie un Subject Un Subject = plusieurs principals1. package java.security;2. public interface Principal {3. ...4. public String getName();5. }Role, User, Group 19
  20. 20. 09/12/2010Différents login modules Pluggable Authentication Application Login Context Login Modules NTLogin UnixLogin MyLogin Module Module Module JndiLogin Krb5Login DbLogin Module Module Module NT Unix Biometric Authentication Authentication Authentication Kerberos LDAP Server RDBMS AuthenticationLe fonctionnement de JAAS 20
  21. 21. 09/12/2010Login ConfigurationExemple de login 21
  22. 22. 09/12/2010Le CallBackHandlerLes autorisations Autorisations programmées  Codées dans les Beans Autorisations déclarées  Le container prend en charge le contrôle des autorisations 22
  23. 23. 09/12/2010Les roles Un rôle = une collection didentités  Employé  Etudiant  Administrateurs  ...La déclaration de la sécurité Les roles utilisés Le rôle par défaut Le rôle autorisé Tout le monde peut le faire 23
  24. 24. 09/12/2010Les annotations @RolesAllowed @PermitAll @DenyAll La définition au niveau de la méthode surcharge la définition au niveau de la classeProgagation de la sécurité @RunAs(admin)  Surcharge le rôle du contexte de lappelant  La méthode va sexécuter avec le rôle admin 24
  25. 25. 09/12/2010La propagation de la sécurité Lidentité et les rôles sont transmis par le contexte Lidentité de lappelant Vérification de son rôleAutre exemple (from Oracle) 25
  26. 26. 09/12/2010Description par fichier de configurationDeclaratif ou programmée Déclaratif :  Découplage du code métier et de la définition de la sécurité  Mais .... cest insuffisant Programmée  Complique le code  Mais permet un contrôle au niveau des instances 26
  27. 27. 09/12/2010Sécurité et WebServices Comment sécuriser des appels de Web Services de bout en boutXML Signature et XML Encryption Permettent le transfert de documents XML entre des noeuds inconnus Les parties cryptées ne seront lisibles que par les noeuds qui connaissent les clés. Tout le message na pas besoin dêtre crypté/signé 27
  28. 28. 09/12/2010SAML Security Assertion Markup Language Assertion = Security token Utilisées par les PEP (Policy Enforcement Point) SAML Authority : emets les token  Token = le sujet est authentifié par moi ou jautorise le sujet à faire A et B ou le sujet a le rôle X Le PEP doit faire confiance à lautoritéWS-Security The security context is in the message 28
  29. 29. 09/12/2010Conclusion sur la sécurité Encore difficile à mettre en oeuvre Encore plus dans un environnement distribué Nombreux standards  Ça progresse dans le domaine des Web ServicesEJB Timer Comment déclencher des actions à des instants particuliers  Opérations de maintenance  Batch processing  Deadline dans des workflows Comment permettre dappeler des services à des instants donnés 29
  30. 30. 09/12/2010Timer Service API javax.ejb.TimedObject javax.ejb.Timer javax.ejb.TimerHandle javax.ejb.TimerServiceTimerService Permet de créer un Timer 30
  31. 31. 09/12/2010Interactions avec les EJBCréation automatique de Timers 31
  32. 32. 09/12/2010EJB et Timer Portable Facile à mettre en oeuvre Granularité des services Limitations dans la définition des timersL’exemple Duke Bank 32
  33. 33. 09/12/2010La structure de l’applicationLes Session Beans AccountController CustomerController TxController  Implantation des méthodes métiers de l’application  Facade pour les clients  Masquent la représentation du modèle 33
  34. 34. 09/12/2010 34
  35. 35. 09/12/2010Les Entity ClassesEntity Account 35
  36. 36. 09/12/2010Les requêtesLa table 36
  37. 37. 09/12/2010Application d’administrationApplication Web 37
  38. 38. 09/12/2010EJB et Web CustomerBean  Composant représentant le client dans la vuePerformance http://java.sun.com/developer/technicalArticles/ebeans/ej b_30/ Conception des applications  Un appel par cas d’utilisation  Stateful vs Stateless  Gestion de la persistence  Gestion des différents niveaux de cache  Consistence vs availability 38
  39. 39. 09/12/2010 That’s all folkshttp://www.youtube.com/watch?v=gBzJGckMYO4 39

×