Serveurs d’application

1. Serveurs d’application Architecture Le standard J2EE Etude de cas: EDF GDF .NET de Microsoft

2. 1. Architecture avec SA Serveur Web Serveur Web Présentation Application Données Appareil mobile Serveur WAP SGBD Browser Web Serveur d’application Application ERP Client Java Parefeu Application mainframe Client VB/C++ … …

3. Serveur d’application • Serveur d’entreprise avec • support des composants • standards CORBA, COM, EJB • middleware objet • support des transactions • standards CORBA, Open Group (XA) • environnement de développement intégré • composants, transactions • équilibrage de charge entre serveurs • support de XML et des Web services • interface avec moniteurs transactionnels et MOM • NB: serveur d’application  serveur Web + servlet (ex. Apache+Tomcat)

4. Equilibrage de charge et disponibilité Cookie A,B En cas de panne de A, basculement automatique sur B Serveur A primaire Réplication de l’état des processus clients Serveur B Secondaire Cluster

5. Le problème d’accès aux données • Compromis entre performances et flexibilité difficile à obtenir • performances : s’appuyer au maximum sur le serveur BD => procédures stockées • flexibilité : composants métiers encapsulant l’accès aux données Où mettre la logique applicative ? Composants métiers Procédures stockées Serveur d’application Serveur de données

6. Accès BD en C/S 2 tiers • Développement d’applications BD en 2 étapes • conception de la BD • création des tables et des contraintes d’intégrité • programmation des procédures stockées Très efficace • procédures stockées et contraintes d’intégrité exécutées sur le serveur BD Evolution difficile • la modification d’une définition de données implique la recompilation des procédures stockées

7. Composants avec accès BD • Similaire au C/S + efficace - composants non autonomes Gestionnaire de commandes Produit Commande Select C.a, P.b, … From C, P Where …

8. Composants encapsulant leurs données • Principe d’îlot de données • ensemble de données entièrement contenu dans un composant métier • exige une forte localité des données/composant + composants autonomes - performances Gestionnaire de commandes Produit Commande

9. Comment améliorer les performances • Faire des composants métiers à gros grain • encapsulation des données fortement corrélées • par ex. 5 à 10 définitions de tables relationnelles • Exploiter les vues relationnelles • pour les données partagées entre plusieurs composants • Mettre en œuvre un cache de données au niveau du serveur d’application • transformation objet/relationnel

10. 2. Le standard J2EE (Sun et al.) • De nombreuses API • EJB: modèle de composants serveurs • JNDI: accès aux services d’annuaire DNS, LDAP • RMI: invocation de méthodes Java à distance • JIDL: Java IDL - interface Corba • JSP: Java Server Pages (Java ds pages HTML) • JMS: Java Messaging Service • JTS: Java Transaction Service (basé sur OTS) • JDBC: accès aux BD via SQL • JDO: Java Data Objects • JAX: Java XML • JCA: Java Connector Architecture • ...

11. JAX • Pour intégrer XML et les services web • JAX-RPC (Java API for XML RPC) pour effectuer des appels de messages SOAP • JAXM (Java API for XML Messaging) pour envoyer des documents XML via SOAP • JAXR (Java API for XML Registries) pour accéder des annuaires de services de type UDDI

12. Architecture d’un serveur J2EE Logique métier Logique de présentation Container Web Container EJB Java Server Page HTML/XML Entity Bean Session Bean Java Bean Servlet Support Comm. TCP/IP, HTTP, RMI, IIOP, SOAP, etc. Services de base JDBC, JTS, JNDI, JMS, JDO, JAX, etc.

13. Principaux serveurs J2EE

14. WebSphere Application Server • Support J2EE complet • Support des transactions • Interopérabilité avec le moniteur TXSeries • Serveur HTTP basé sur Apache • Support des clusters • partitionnement des applications et équilibrage de charge • Intégration avec • Studio Application Developer • DB2 pour la gestion de données et le stockage de XML • Tivoli pour la gestion de réseau • Versant enJin pour les objets persistants

15. WebLogic (BEA-Oracle) • Support J2EE complet • Serveur HTTP intégré • Plugins pour Apache, IIS, Iplanet • Support des transactions • interopérabilité avec le moniteur BEA Tuxedo • Support des clusters • disponibilité et équilibrage de charge • Environnement de développement • WebLogic Builder pour le développement Java • WebLogic Workshop pour les Web services • Intégration avec • Nokia WAP server pour les mobiles • TopLink (WebGain) pour le mapping objet-relationnel • Versant enJin pour les objets persistants

16. 3. Etude de cas: EDF GDF • Application de relation client (CRM) : Niveau1 • Utilisée par 25000 agents de clientèle répartis sur 1300 agences • Gestion commerciale, gestion des contacts, outils marketing, utilitaires (mailings, etc.) • Architecture technique • C/S (client lourd) avec 2 nouvelles versions par an • SI sur mainframes IBM (un centre par département) • Plusieurs BD et une partition CICS par centre • Besoins • Réactivité croissante aux demandes des agents • Déploiement plus rapide des nouvelles versions

17. Solution • Architecture n-tiers • Client léger • WebLogic: serveur J2EE sur plusieurs serveurs • Scort: Progiciel d’intégration avec les applications mainframes avec des composants J2EE sur WebLogic • Résultats obtenus • Satisfaction des besoins • Niveau1 offre 2 modes d’accès transparents aux clients: • Accès aux mainframes en récupérant une connexion pour exécuter des transactions • Smart publishing: navigation en mode publication à la volée

18. Le problème de la persistance des objets • L’état des objets modifiés par les entity beans doit être sauvegardé durant l’exécution • Approche classique: BD relationnelle avec mapping objet-relationnel • en général très inefficace avec des entity beans CMP (cf étude de SQLi mars 2002) • Solutions • propriétaire de type TopLink • mapping vers une BD objet, par ex. Versant enJin • la plus productive et efficace selon SQLi

19. Versant enJin Serveur d’application Serveur d’application Bean Commande Bean Produit Bean Commande Bean Produit Cache partagé transactions transactions SGBDO Versant Mapping O/R automatique Tiers backend Bases de données

20. Avantages de Versant enJin • Persistance des objets Java transparente • simple pour le développeur • pas besoin de programmer en JDBC ou autre • Cache d’objets partagés entre différents serveurs • performances et cohérence via le SGBDO Versant • Mapping objet-relationnel automatique vers les BD existantes • définition de la fréquence de synchronisation • online, batch, etc.

21. 4. Microsoft .NET • Evolution majeure de la plateforme Windows • les APIs Windows sont remplacées par des bibliothèques de classes objet • intégration de C#, Linq • portabilité des applications .NET • Microsoft Intermediate Language (MSIL) exécuté par CLR • sécurité renforcée avec vérification de code • intégration avec COM et Microsoft Transaction Server (MTS) • support direct des services Web, de XML et de SOAP avec Visual Studio .NET

22. Architecture de MTS HTML XML Active Server Page (ASP) Internet Information Server (IIS) MTS SQLServer ADO • Executive • threads • wrapper • context HTTP Oracle • factory • trans. • cache DCOM Autres Windows

23. Modèle de composants MTS • Composant • pas d’état (équivalent à EJB session bean) • Container • executive : entre client et composant serveur • context wrapper • définition du comportement trans. du composant par le développeur (par positionnement d’attributs avec Explorer) • context object • appelé automatiquement par MTS pour coordonner les transactions en 2 phases • Serveur Windows

24. Exemple de code applicatif MTS Set ctxObject = GetObjectContext () // accès à l’objet contexte de MTS { code applicatif } Set objExemple = ctxObject.CreateInstance () // création d’un objet MTS { code applicatif } If (OK) ctxObject.SetComplete () // validation de la transaction Else ctxObject.SetAbort () // annulation de la transaction

25. Le framework.NET VB, C++, C#, Jscript, Java,etc. Outils SOAP et XML Visual Studio .NET ASP.NET Docs HTML XML BCL.NET Base class library ADO.NET Active Data Objects Common Language Runtime (CLR) Windows et COM/MTS

26. Serveur J2EE versus .NET • Serveur J2EE • limité à Java • transactions explicites • généralité • objets avec état: entity beans • problème de performances des beans CMP • portabilité • .NET • multi-langage • transactions implicites • simplicité • objets sans état • utiliser ADO pour l’accès aux données • propriétaire, intégré dans le monde Windows

27. Conclusion sur les serveurs d’application • Un modèle d’architecture réellement distribué • cache la complexité du middleware • Critères de choix d ’un serveur d’application • support des standards • J2EE, Web services • plate-formes supportées • performances et débit transactionnel • environnement de développement