Tour d horizon de Java EE 6

Transcription

1 1 Tour d horizon de Java EE 6 De nos jours, les entreprises évoluent dans une compétition à l échelle mondiale. Elles ont besoin pour résoudre leurs besoins métiers d applications qui deviennent de plus en plus complexes. À notre époque de mondialisation, les sociétés sont présentes sur les différents continents, fonctionnent 24 heures sur 24, 7 jours sur 7 via Internet et dans de nombreux pays ; leurs systèmes doivent être internationalisés et savoir traiter plusieurs monnaies et des fuseaux horaires différents tout ceci en réduisant les coûts, en améliorant le temps de réponse des services, en stockant les données sur des supports fiables et sécurisés et en offrant différentes interfaces graphiques à leurs clients, employés et fournisseurs. La plupart des sociétés doivent combiner ces défis innovants avec leur système d information existant tout en développant en même temps des applications B2B (business to business) pour communiquer avec leurs partenaires. Il n est pas rare non plus qu une société doive coordonner des données stockées à divers endroits, traitées par plusieurs langages de programmation et acheminées via des protocoles différents. Évidemment, ceci ne doit pas faire perdre d argent, ce qui signifie qu il faut empêcher les pannes du système et toujours rester disponible, sécurisé et évolutif. Les applications d entreprise doivent faire face aux modifications et à la complexité tout en étant robustes. C est précisément pour relever ces défis qu a été créé Java Enterprise Edition (Java EE). La première version de Java EE (connue sous le nom de J2EE) se concentrait sur les problèmes que devaient résoudre les sociétés en 1999 : les composants distribués. Depuis, les logiciels ont dû s adapter à de nouvelles solutions techniques comme les services web SOAP ou REST. La plate-forme a donc évolué pour tenir compte de ces besoins en proposant plusieurs mécanismes standard sous forme de spécifications. Au cours des années, Java EE a évolué pour devenir plus riche, plus léger, plus simple d utilisation et plus portable.

2 6 Java EE 6 et GlassFish 3 Ce chapitre fait un tour d horizon de Java EE. Après une présentation rapide de son architecture interne, il présentera les nouveautés de Java EE 6. La seconde partie du chapitre est consacrée à la mise en place de votre environnement de développement pour que vous puissiez vous-même mettre en œuvre les extraits de code présentés dans ce livre. Présentation de Java EE Lorsque l on veut traiter une collection d objets, on ne commence pas par développer sa propre table de hachage : on utilise l API des collections. De même, lorsque l on a besoin d une application transactionnelle, sécurisée, interopérable et distribuée, on ne développe pas des API de bas niveau : on utilise la version entreprise de Java (Java EE). Tout comme l édition standard de Java (Java SE, Standard Edition) permet de traiter les collections, Java EE fournit des moyens standard pour traiter les transactions via Java Transaction API (JTA), les messages via Java Message Service (JMS) ou la persistance via Java Persistence API (JPA). Java EE est un ensemble de spécifications pour les applications d entreprise ; il peut donc être considéré comme une extension de Java SE destinée à faciliter le développement d applications distribuées, robustes, puissantes et à haute disponibilité. Java EE 6 est une version importante. Non seulement elle marche dans les pas de Java EE 5 pour fournir un modèle de développement simplifié, mais elle ajoute également de nouvelles spécifications et apporte des profils et de l élagage pour alléger ce modèle. La sortie de Java EE 6 coïncide avec le dixième anniversaire de la plate-forme entreprise : elle combine donc les avantages du langage Java avec l expérience accumulée au cours de ces dix dernières années. En outre, elle tire profit du dynamisme de la communauté open-source et de la rigueur du JCP. Désormais, Java EE est une plate-forme bien documentée, avec des développeurs expérimentés, une communauté d utilisateurs importante et de nombreuses applications déployées sur les serveurs d entreprises. C est un ensemble d API permettant de construire des applications multi-tier reposant sur des composants logiciels standard ; ces composants sont déployés dans différents conteneurs offrant un ensemble de services. Un peu d histoire Dix ans permettent de se faire une idée de l évolution de Java EE (voir Figure 1.1), qui s est d abord appelé J2EE. La première version, J2EE 1.2, a été initialement développée par Sun et est apparue en 1999 sous la forme d une spécification contenant dix

3 Chapitre 1 Tour d horizon de Java EE 6 7 Java Specification Requests (JSR). À cette époque, on parlait beaucoup de CORBA : c est la raison pour laquelle J2EE 1.2 a été créé en ayant à l esprit la création de systèmes distribués. Les Enterprise Java Beans (EJB) introduits alors permettaient de manipuler des objets service distants avec ou sans état et, éventuellement, des objets persistants (beans entités). Ils étaient construits selon un modèle distribué et transactionnel utilisant le protocole sous-jacent RMI-IIOP (Remote Method Invocation- Internet Inter-ORB Protocol). La couche web utilisait les servlets et les JavaServer Pages (JSP) et les messages étaient envoyés via JMS. Figure 1.1 Historique de J2EE/Java EE. Profil Web EoD Java EE 6 Facilité de développement Java EE 5 Application d'entreprise J2EE 1.2 Robuste, évolutif J2EE 1.3 Services web J2EE 1.4 Élagage Conteneur intégrable JAX-RS Validation des beans Project JPE Servlet JSP EJB JMS RMI/IIOP EJB CMP JCA Services web Gestion Déploiement Annotations Injection JPA WS-* JSF Profil web Mai 1998 Dec specs Sept specs Nov specs Mai specs Q specs INFO CORBA est apparu vers 1988, précisément parce que les systèmes d entreprise commençaient à être distribués (Tuxedo, CICS, par exemple). Les EJB puis J2EE lui ont emboîté le pas, mais dix ans plus tard. Lorsque J2EE est apparu pour la première fois, CORBA avait déjà gagné son statut industriel, mais les sociétés commençaient à utiliser des solutions "tout-java" et l approche neutre de CORBA vis-à-vis des langages de programmation est donc devenu redondante. À partir de J2EE 1.3, la spécification a été développée par le Java Community Process (JCP) en réponse à la JSR 58. Le support des beans entité est devenu obligatoire et les EJB ont introduit les descripteurs de déploiement XML pour stocker les métadonnées (qui étaient jusqu alors sérialisées dans un fichier avec EJB 1.0). Cette version a également réglé le problème du surcoût induit par le passage des paramètres par valeur avec les interfaces distantes en introduisant les interfaces locales

4 8 Java EE 6 et GlassFish 3 et en passant les paramètres par référence. J2EE Connector Architecture (JCA) a été ajoutée afin de connecter J2EE aux EIS (Enterprise Information Systems). INFO JCP est une organisation ouverte créée en 1998 afin de définir les évolutions de la plateforme Java. Lorsqu il identifie le besoin d un nouveau composant ou d une nouvelle API, l initiateur (appelé "leader de la spécification") crée une JSR et forme un groupe d experts. Ce groupe, formé de représentants de diverses sociétés ou organisations, ainsi que de personnes privées, est responsable du développement de la JSR et doit délivrer : 1) une spécification qui explique les détails et définit les bases de la JSR ; 2) une implémentation de référence (RI, Reference Implementation) ; et 3) un kit de test de compatibilité (TCK, Technology Compatibility Kit), c est-à-dire un ensemble de tests que devront satisfaire toutes les implémentations avant de pouvoir prétendre qu elles sont conformes à la spécification. Une fois qu elle a été acceptée par le comité exécutif (EC, Executive Committee), la spécification est fournie à la communauté pour être implémentée. En réalité, Java EE est une JSR qui chapeaute d autres JSR et c est la raison pour laquelle on parle souvent de JSR umbrella. J2EE 1.4 (JSR 151), qui est sorti en 2003, a ajouté vingt spécifications et le support des services web. EJB 2.1 permettait ainsi d invoquer des beans de session à partir de SOAP/HTTP. Un service de temporisation a également été ajouté pour permettre aux EJB d être appelés à des moments précis ou à intervalles donnés. Cette version fournissait un meilleur support pour l assemblage et le déploiement des applications. Bien que ses supporters lui aient prédit un grand avenir, toutes les promesses de J2EE ne se sont pas réalisées. Les systèmes créés grâce à lui étaient trop complexes et les temps de développement, souvent sans commune mesure avec les exigences de l utilisateur. J2EE était donc considéré comme un modèle lourd, difficile à tester, à déployer et à exécuter. C est à cette époque que des frameworks comme Struts, Spring ou Hibernate ont commencé à émerger et à proposer une nouvelle approche dans le développement des applications. Heureusement, Java EE 5 (JSR 244) fit son apparition au deuxième trimestre de 2006 et améliora considérablement la situation. Il s inspirait des frameworks open-source en revenant à un bon vieil objet Java (POJO, Plain Old Java Object). Les métadonnées pouvaient désormais être définies grâce à des annotations et les descripteurs XML devenaient facultatifs. Du point de vue des développeurs, EJB 3 et la nouvelle spécification JPA représentèrent donc plus un bond prodigieux qu une évolution de la plate-forme. JSF (JavaServer Faces) fit également son apparition comme framework standard de la couche présentation et JAX-WS 2.0 remplaça JAX-RPC comme API pour les services web SOAP.

5 Chapitre 1 Tour d horizon de Java EE 6 9 Aujourd hui, Java EE 6 (JSR 316) poursuit sur cette voie en appliquant les concepts d annotation, de programmation POJO et la politique "convention plutôt que configuration" à toute la plate-forme, y compris la couche web. Il fournit également un grand nombre d innovations comme la toute nouvelle API JAX-RS 1.1, simplifie des API matures comme EJB 3.1 et en enrichit d autres comme JPA 2.0 ou le service de temporisation. Les thèmes principaux de Java EE 6 sont la portabilité (en standardisant le nommage JNDI, par exemple), la dépréciation de certaines spécifications (via l élagage) et la création de sous-ensembles de la plate-forme au moyen de profils. Dans ce livre, nous présenterons toutes ces améliorations et montrerons comment Java Enterprise Edition est devenu à la fois bien plus simple et bien plus riche. Standards Java EE repose sur des standards. C est une spécification centrale qui chapeaute un certain nombre d autres JSR. Vous pourriez vous demander pourquoi les standards sont si importants puisque certains des frameworks Java les plus utilisés (Struts, Spring, etc.) ne sont pas standardisés. La raison est que les standards, depuis l aube des temps, facilitent la communication et les échanges des exemples de standards bien connus concernent les langues, la monnaie, le temps, les outils, les trains, les unités de mesure, l électricité, le téléphone, les protocoles réseau et les langages de programmation. Quand Java est apparu, le développement d une application web ou d entreprise passait généralement par l utilisation d outils propriétaires : on créait son propre framework ou l on s enfermait en choisissant un framework commercial propriétaire. Puis vint l époque des frameworks open-source, qui ne reposent pas toujours sur des standards ouverts. Vous pouvez donc utiliser une solution open-source qui vous enferme dans une seule implémentation ou en choisir une qui implémente les standards et qui sera alors portable. Java EE fournit des standards ouverts implémentés par plusieurs frameworks commerciaux (WebLogic, Websphere, MQSeries, etc.) ou open-source (GlassFish, JBoss, Hibernate, Open JPA, Jersey, etc.) pour gérer les transactions, la sécurité, les objets à état, la persistance des objets, etc. Aujourd hui plus que jamais dans l histoire de Java EE, votre application peut être déployée sur n importe quel serveur d applications conforme, moyennant quelques modifications mineures. Architecture Java EE est un ensemble de spécifications implémentées par différents conteneurs. Ces conteneurs sont des environnements d exécution Java EE qui fournissent cer-

6 10 Java EE 6 et GlassFish 3 tains services aux composants qu ils hébergent : gestion du cycle de vie, injection de dépendances, etc. Les composants doivent respecter des contrats bien définis pour communiquer avec l infrastructure de Java EE et avec les autres composants, et ils doivent être assemblés en respectant un certain standard (fichiers archives) avant d être déployés. Java EE étant un surensemble de la plate-forme Java SE, les API de cette dernière peuvent donc être utilisées par n importe quel composant de Java EE. La Figure 1.2 présente les relations logiques qui relient les conteneurs. Les flèches représentent les protocoles utilisés par un conteneur pour accéder à un autre. Le conteneur web, par exemple, héberge les servlets qui peuvent accéder aux EJB via le protocole RMI-IIOP. Figure 1.2 Conteneurs standard de Java EE. <<executionenvironment>> Conteneur web Servlet JSF RMI / IIOP <<executionenvironment>> Conteneur EJB EJB HTTP SSL SSL HTTP RMI / IIOP RMI / IIOP <<executionenvironment>> Conteneur Applets Applet Conteneur d'applications client Application Composants L environnement d exécution de Java EE définit quatre types de composants que doivent supporter toutes les implémentations : Les applets sont des applications graphiques exécutées dans un navigateur web. Elles utilisent l API Swing pour fournir des interfaces utilisateurs puissantes. Les applications sont des programmes exécutés sur un client. Il s agit le plus souvent d interfaces graphiques ou de programmes non interactifs qui ont accès à toutes les fonctionnalités de la couche métier de Java EE.

7 Chapitre 1 Tour d horizon de Java EE 6 11 Les applications web (composées de servlets, de filtres de servlet, d écouteurs d événements web, de pages JSP et de JSF) s exécutent dans un conteneur web et répondent aux requêtes HTTP envoyées par les clients web. Les servlets permettent également de mettre en place des services web SOAP et REST. Les EJB (Enterprise Java Beans) sont des composants permettant de traiter la logique métier en modèle transactionnel. On peut y accéder localement et à distance via RMI (ou HTTP pour les services web SOAP et REST). Conteneurs L infrastructure de Java EE est découpée en domaines logiques appelés conteneurs (voir Figure 1.2). Chacun d eux joue un rôle spécifique, supporte un ensemble d API et offre des services à ses composants (sécurité, accès aux bases de données, gestion des transactions, injection de ressources, etc.). Les conteneurs cachent les aspects techniques et améliorent la portabilité. Selon le type d application que vous voudrez construire, vous devrez comprendre les possibilités et les contraintes de chaque conteneur. Si, par exemple, vous devez développer une couche de présentation web, vous écrirez une application JSF et la déploierez dans un conteneur web, non dans un conteneur EJB. Si, en revanche, vous voulez qu une application web appelle une couche métier, vous devrez sûrement utiliser à la fois un conteneur web et un conteneur EJB. La plupart des navigateurs web fournissent des conteneurs d applets pour exécuter les composants applets. Lorsque vous développez des applets, vous pouvez donc vous concentrer sur l aspect visuel de l application puisque le conteneur vous fournit un environnement sécurisé grâce à un modèle de protection appelé "bac à sable" : le code qui s exécute dans ce bac à sable n est pas autorisé à en sortir, ce qui signifie que le conteneur empêchera un code téléchargé sur votre machine locale d accéder aux ressources de votre système, comme les processus ou les fichiers. Le conteneur d applications client (ACC, application client container) contient un ensemble de classes et de bibliothèques Java ainsi que d autres fichiers afin d ajouter l injection, la gestion de la sécurité et le service de nommage aux applications Java SE (applications Swing, traitements non interactifs ou, simplement, une classe avec une méthode main()). ACC communique avec le conteneur EJB en utilisant le protocole RMI-IIOP et avec le conteneur web via le protocole HTTP (pour les services web, notamment).

8 12 Java EE 6 et GlassFish 3 Le conteneur web (ou conteneur de servlets) fournit les services sous-jacents permettant de gérer et d exécuter les composants web (servlets, JSP, filtres, écouteurs, pages JSF et services web). Il est responsable de l instanciation, de l initialisation et de l appel des servlets et du support des protocoles HTTP et HTTPS. C est lui qu on utilise pour servir les pages web aux navigateurs des clients. Le conteneur EJB est responsable de la gestion de l exécution des beans entreprise contenant la couche métier de votre application Java EE. Il crée de nouvelles instances des EJB, gère leur cycle de vie et fournit des services comme les transactions, la sécurité, la concurrence, la distribution, le nommage ou les appels asynchrones. Services Les conteneurs fournissent les services sous-jacents à leurs composants. En tant que développeur, vous pouvez donc vous concentrer sur l implémentation de la logique métier au lieu de résoudre les problèmes techniques auxquels sont exposées les applications d entreprise. La Figure 1.3 montre les services fournis par chaque conteneur. JSP Conteneur web JSF Servlet RMI/IIOP Conteneur EJB EJB JAX-WS JAX-RPC SAAJ JACC JASPIC JAXR JAX-RS Métadonnées WS Services web JMS Gestion Java SE JSF JPA JTA Connecteurs JavaMail JSTL JAX-WS JAX-RPC SAAJ JACC JASPIC JAXR JAX-RS Métadonnées WS Services web Java SE JavaMail JPA JTA Connecteurs JMS Gestion HTTP SSL Conteneur Applets Applet Java SE HTTP SSL Conteneur d'applications client Application cliente JAXR JAX-WS JAX-RPC SAAJ JPA Gestion Métadonnées WS Services web JMS Java SE RMI/IIOP JDBC JDBC Base de données Figure 1.3 Services fournis par les conteneurs.