Serveurs d’application Architecture Le standard J2EE Etude de cas: EDF GDF .NET de Microsoft
1. Architecture avec SA Présentation Application Données … … Appareil mobile Serveur WAP SGBD Serveur Web Browser Web Serveur Web Serveur d’application Application ERP Client Java Parefeu Client VB/C++ Application mainframe … …
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)
Equilibrage de charge et disponibilité En cas de panne de A, basculement automatique sur B Cookie A,B Serveur A primaire Réplication de l’état des processus clients Serveur B Secondaire Cluster
Le problème d’accès aux données Où mettre la logique applicative ? Composants métiers Procédures stockées Serveur d’application Serveur de 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
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
Composants avec accès BD Gestionnaire de commandes Similaire au C/S + efficace - composants non autonomes Commande Produit Select C.a, P.b, … From C, P Where …
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 Commande Produit
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
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 ...
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
Architecture d’un serveur J2EE Logique de présentation Logique métier Container Web Container EJB Java Server Page HTML/XML Session Bean Entity Bean Java Bean Servlet Support Comm. TCP/IP, HTTP, RMI, IIOP, SOAP, etc. Services de base JDBC, JTS, JNDI, JMS, JDO, JAX, etc.
Principaux serveurs J2EE Editeur Produit Points forts Ordre de prix BEA-Oracle WebLogic Transactionnel, outils 10K€ IBM Websphere Transactionnel, intégration avec DB2 UDB Oracle AS Intégré dans l’offre Oracle HP Total-e-server Intégré avec les middlewares HP Borland AppServer Basé sur Visibroker, outils Sun GlassFish Logiciel libre (dernier né) Gratuit Redhat Jboss Logiciel libre Apache Jeronimo Objectweb Jonas
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
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
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
Solution Architecture n-tiers Résultats obtenus 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
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
Versant enJin Serveur d’application Serveur d’application Bean Bean Commande Bean Produit Bean Commande Bean Produit Cache partagé transactions transactions SGBDO Versant Mapping O/R automatique Tiers backend Bases de données
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.
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
Architecture de MTS Internet Information MTS Server (IIS) ADO SQLServer ADO Executive threads wrapper context HTML XML HTTP Oracle Active Server Page (ASP) factory trans. cache DCOM Autres Windows
Modèle de composants MTS 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
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 If (OK) ctxObject.SetComplete () // validation de la transaction Else ctxObject.SetAbort () // annulation de la transaction
Common Language Runtime (CLR) 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
Serveur J2EE versus .NET Serveur J2EE .NET 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
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