2 Chapitre 1 Introduction

1 Introduction Ce livre présente les Enterprise JavaBeans 2.0 et 1.1 qui constituent la troisième et la deuxième version de la spécification des Enterprise JavaBeans. Tout comme la plate-forme Java a révolutionné la façon de voir le développement de logiciels, les Enterprise JavaBeans promettent de révolutionner la façon de développer les logiciels d entreprise critiques. Ils combinent les composants côté serveur aux technologies d objets distribués et aux messages asynchrones afin de simplifier le développement d applications. Ils prennent en compte automatiquement beaucoup des contraintes des systèmes d entreprise : sécurité, groupe de ressources, persistance, concurrence et intégrité transactionnelle. Ce livre montre comment utiliser les Enterprise JavaBeans pour développer des systèmes d entreprise portables et évolutifs. Mais avant de commencer à parler des EJB euxmêmes, nous avons besoin d une brève introduction aux technologies visées par les EJB, comme les modèles de composants, les objets distribués, les CTM (Component Transaction Monitors) et les messages asynchrones. Il est important de comprendre un minimum des CTM, la technologie sur laquelle repose les EJB. Aux chapitres 2 et 3, nous commencerons à examiner les EJB eux-mêmes et nous verrons comment les beans métier sont assemblés. Le reste du livre concerne le développement de beans métier pour une société fictive et une présentation des problèmes avancés. Nous supposons que vous êtes déjà familier de Java ; si ce n est pas le cas, Introduction à Java écrit par Patrick Niemeyer et Jonathan Knudsen (Éditions O Reilly) est une excellente introduction. Ce livre suppose aussi que vous connaissiez l API JDBC, ou au moins SQL. Si vous n êtes pas familier de JDBC, lisez JDBC et Java - Guide du programmeur, de George Reese (Éditions O Reilly). Une des fonctionnalités de Java les plus importantes est d être indépendant de la plateforme. Depuis sa première version, Java a été présenté sous le slogan «écrire une fois, exécuter partout». Bien que ce matraquage soit parfois devenu un peu maladroit, le code écrit en langage Java est remarquablement indépendant de la plate-forme. Les Enterprise JavaBeans ne sont pas simplement indépendants de la plate-forme, ils sont aussi indépendant de l implémentation. Si vous avez déjà travaillé avec JDBC, vous savez un peu ce que cela signifie. Non seulement l API JDBC peut s exécuter sur une machine

2 Chapitre 1 Introduction Windows ou une machine Unix, mais elle peut aussi accéder aux bases de données relationnelle des différents fournisseurs (DB2, Oracle, Sybase, SQLServer, etc.) à l aide des pilotes JDBC spécifiques. Vous n avez pas à programmer de façon spécifique à l implémentation de la base de données ; il suffit de changer de pilote pour changer de base de données. Il en va de même avec les EJB. Idéalement, un composant EJB, un bean métier, peut s exécuter sur n importe quel serveur d applications qui implémente la spécification des EJB 1. Cela signifie que vous pouvez développer et déployer votre système d entreprise EJB sur un serveur, comme Orion ou WebLogic de BEA, puis plus tard le déplacer sur un serveur d EJB différent, comme Pramati, EAServer de Sybase, Web- Sphere d IBM, ou un projet en open source, comme OpenEJB, JOnAS ou JBoss. L indépendance de l implémentation signifie que vos composants métier ne sont pas dépendants de la marque du serveur. Autrement dit, vous avez plus de choix avant, pendant et après le développement et le déploiement. Quelques concepts Avant de définir les Enterprise JavaBeans de façon plus précise, préparons le terrain en examinant un nombre important de concepts : les objets distribués, les objets métier, les CTM et les messages asynchrones. Objets distribués L informatique distribuée permet de rendre un système d entreprise plus accessible. Les différentes parties d un système distribué peuvent se trouver sur des ordinateurs séparés, en plusieurs endroits potentiellement éloignés où ils prennent tous leur sens. Autrement dit, l informatique distribuée permet d accéder à la logique et aux données métier à distance. Les clients, les partenaires et d autres intervenants distants peuvent utiliser un système d entreprise à tout moment où qu ils se trouvent. Le développement le plus récent dans l informatique distribuée sont les objets distribués. Les technologies d objets distribués, comme Java RMI, CORBA et.net de Microsoft, permettent aux applications client présentes sur des ordinateurs d accéder à des objets s exécutant sur une autre machine. Les objets distribués sont apparus sous forme d une architecture trois-tiers utilisées dans les systèmes à moniteur TP comme CICS d IBM et TUXEDO de BEA. Ces systèmes séparent la présentation, la logique métier et les bases de données en trois tiers distincts (ou couches). Par le passé, ces systèmes étaient habituellement composés d un «écran vert» ou de terminaux passifs pour le tiers présentation (le premier tiers), d applications en COBOL ou PL/1 sur le tiers intermédiaire (le deuxième tiers) et de bases de données, comme DB2, pour le backend (le troisième tiers). L introduction des objets distribués ces dernières années a donné naissance à une nouvelle forme d architecture trois-tiers. Les technologies d objets distribués ont permis le remplacement des applications en COBOL et PL/1 du tiers intermédiaire par des objets métier. Une architecture métier trois-tiers à base d objets distribués peut avoir comme premier tiers une interface 1. À condition que les beans et les serveurs d EJB soient conformes à la spécification et qu aucune fonctionnalité propriétaire ne soit utilisée pour le développement.

Quelques concepts 3 graphique ou web sophistiquée, des objets métier dans le tiers intermédiaire et une base de données relationnelle ou d un autre type comme backend. Des architectures plus complexes dans lesquelles de nombreux tiers sont souvent utilisées : différents objets résident sur différents serveurs et interagissent afin de réaliser leur travail. La création de ces architectures n-tiers à l aide des Enterprise JavaBeans est particulièrement facile. Composants côté serveur Les langages orientés objet, comme Java, C++ et Smalltalk, permettent d écrire des logiciels souples, évolutifs et réutilisables les trois axiomes du développement orienté objet. Dans les systèmes d entreprise, les langages orientés objets sont utilisés pour améliorer le développement de l interface graphique, pour simplifier l accès aux données et pour encapsuler la logique métier. L encapsulation de la logique métier dans des objets métier est devenue le point de focalisation le plus récent dans l industrie informatique. Le métier est fluide, ce qui signifie que les produits, les processus et les objectifs de l entreprise évoluent au fil du temps. Si le logiciel qui modélise le métier peut être encapsulé dans des objets métier, il devient souple, évolutif et réutilisable, et il peut donc suivre l évolution du métier. Un modèle de composants côté serveur définit une architecture pour le développement d objets métier distribués qui combinent l accessibilité des systèmes à objets distribués avec la fluidité de la logique métier utilisant les objets. Les modèles de composants côté serveur sont utilisés sur les serveurs d applications dans le tiers intermédiaire qui gère l exécution des composants et les rendent disponibles aux clients distants. Ils fournissent les fonctionnalités facilitant le développement d objets métier distribués et les assemblent en solutions d entreprise. Les composants côté serveur peuvent aussi servir à modéliser d autres aspects du système d entreprise, comme la présentation et le routage. Par exemple, une servlet Java est un composant côté serveur qui peut générer des données HTML et XML pour la couche de présentation dans une architecture trois tier. De même, les beans orientés message des EJB 2.0, présentés plus loin dans ce livre, sont des composants côté serveur utilisés pour consommer et produire des messages asynchrones. Les composants côté serveur, comme les autres composants, peuvent être achetés et vendus sous forme de morceaux de logiciel exécutables et indépendants. Ils se conforment à un modèle de composants standard et ils peuvent s exécuter sans modification directe sur un serveur qui supporte ce modèle de composants. Les modèles de composants côté serveur supportent souvent la programmation par attributs, qui autorise la modification du comportement du composant pendant son déploiement, sans avoir à changer son code. Selon le modèle de composants, l administrateur du serveur peut déclarer le comportement transactionnel, la sécurité et même la persistance du composant en donnant des valeurs spécifiques à ces attributs. Au fur et à mesure du développement de nouveaux produits et de la modification des procédures opératoires, les composants sur le serveur peuvent être réassemblés, modifiés et étendus afin que le système d entreprise reflète ces changements. Imaginez un système d entreprise comme une collection de composants côté serveur qui modélisent des concepts comme les clients, les produits, les réservations et les entrepôts. Chaque composant est comme une brique de Lego que vous pouvez combiner avec d autres

4 Chapitre 1 Introduction composants pour construire une solution d entreprise. Les produits peuvent être stockés dans l entrepôt ou livrés à un client ; un client peut faire une réservation ou acheter un produit. Vous pouvez assembler les composants, les séparer, les utiliser dans différentes combinaisons et changer leurs définitions. Un système d entreprise basé sur des composants côté serveur est fluide car il s est transformé en objets, et il est accessible car les composants peuvent être distribués. Component Transaction Monitors (CTM) Une nouvelle sorte de logiciels appelés des serveurs d applications est récemment apparue afin de gérer la complexité associée au développement de systèmes d entreprise dans le monde internet actuel. Un serveur d applications est souvent constitué de différentes technologies, y compris des serveurs web, des ORB (object request brokers), des MOM (message-oriented middleware), des bases de données et ainsi de suite. Un serveur d applications peut aussi se concentrer sur une technologie, comme les objets distribués. La sophistication des serveurs d applications basés sur les objets distribués est variable. Les plus simples sont les ORB. Ils facilitent la connectivité entre les applications client et les objets distribués. Les ORB permettent aux applications client de localiser et d utiliser facilement des objets distribués. Cependant, les ORB ont souvent montré qu ils n étaient pas adaptés aux environnements à fort volume transactionnel. Ils fournissent une dorsale de communication pour les objets distribués, mais ils ne parviennent pas à fournir le type d infrastructure robuste nécessaire à la prise en charge d un grand nombre d utilisateurs et des tâches critiques. De plus, les ORB offrent un modèle de composants côté serveur plutôt grossier qui fait reposer sur les épaules du développeur toute la charge de la gestion des transactions, de la concurrence, de la persistance et d autres aspects de niveau système. Ces services ne sont pas supportés automatiquement dans un ORB. Les développeurs d applications doivent accéder explicitement à ces services (s ils sont disponibles) ou, dans certains cas, les mettre en œuvre à partir de rien. Début 1999, Anne Manes 2 a inventé le terme component transaction monitor (CTM) pour décrire des serveurs d applications à base d objets distribués plus sophistiqués. Les CTM ont évolué pour devenir un hybride composé des moniteurs TP traditionnels et des technologie ORB. Ils implémentent des modèles de composants côté serveur robustes qui facilitent la création, l utilisation et le déploiement de systèmes d entreprise. Les CTM fournissent une infrastructure qui prend en charge automatiquement les transactions, la distribution des objets, la concurrence, la sécurité, la persistance et la gestion des ressources. Non seulement ils sont capables de gérer un grand nombre d utilisateurs et des tâches critiques, mais leur facilité d utilisation fait qu ils sont aussi adaptés aux petits systèmes. Les CTM représentent l idéal des serveurs d applications. Cette sorte de technologie se nomme aussi OTM (Object Transaction Monitor), serveur transactionnel de composants, serveur de composants distribués et COMware. Ce livre emploie le terme CTM car il inclut les trois caractéristiques clés de cette technologie : l utilisation d un modèle de composants, le ciblage sur une gestion transactionnelle et les ressources et la gestion de service généralement associées aux moniteurs. 2. À l époque où madame Manes a inventé ce terme, elle travaillait pour Patricia Seybold Group sous le nom de Anne Thomas. Madame Manes est maintenant directrice de la stratégie industrielle chez Sun Microsystems dans la division Sun Software.

Définition des Enterprise JavaBeans 5 Définition des Enterprise JavaBeans Voici la définition des Enterprise JavaBeans donnée par Sun Microsystems : L architecture des Enterprise JavaBeans est une architecture de composants pour le développement et le déploiement d applications d entreprise distribuées basées sur des composants. Les applications écrites en utilisant l architecture des Enterprise JavaBeans sont évolutives, transactionnelles et sûres. Ces applications peuvent être écrites une fois, puis déployées sur toute plate-forme serveur qui supporte la spécification des Enterprise JavaBeans. 3 Oh là là! C est ainsi que Sun a l habitude de définir ses technologies Java. Avez-vous déjà lu la définition du langage Java lui-même? Elle est à peu près deux fois plus longue. Voici notre définition, plus courte, des EJB : Les Enterprise JavaBeans sont un modèle de composants côté serveur standard pour les CTM. Nous avons déjà brièvement préparé le terrain pour cette définition en définissant les termes «objets distribués», «composants côté serveur» et «CTM». Afin de vous donner les bases solides et complètes pour étudier les Enterprise JavaBeans, ce chapitre va maintenant s étendre sur ces définitions. Si vous comprenez déjà parfaitement les objets distribués, les moniteurs transactionnels, les CTM et les messages asynchrones, n hésitez pas à sauter le reste de ce chapitre pour aller directement au chapitre 2. Architectures à objets distribués Les EJB sont un modèle de composants pour les CTM basés sur les technologies à objets distribués. C est pourquoi, pour comprendre les EJB, vous devez comprendre comment fonctionnent les objets distribués. Les systèmes à objets distribués constituent les bases des architectures trois-tiers modernes. Dans ces architectures, comme le montre la figure 1-1, la logique de présentation réside sur le client (le premier tiers), la logique métier dans le tiers intermédiaire (le deuxième tiers), et les autres ressources, comme la base de données, résident sur le backend (le troisième tiers). Tous les protocoles d objets distribués sont construits sur la même architecture de base conçue de telle sorte qu un objet présent sur un ordinateur soit vu comme résidant sur un ordinateur différent. Les architectures à objets distribués sont basées sur une couche de communication réseau relativement simple. Il y a principalement trois parties dans cette architecture : l objet métier, le squelette et le stub. L objet métier réside dans le tiers intermédiaire. Il s agit d une instance d un objet qui modélise l état et la logique métier d un concept du monde réel, comme une personne, une commande ou un compte. Chaque classe d objet métier possède ses classes stub et squelette correspondantes, construites spécialement pour ce type d objet métier. Par exemple, un objet métier distribué appelé Personne aura les classes correspondantes 3. Enterprise JavaBeans Specification, v1.1, de Sun Microsystems, Copyright 1999 par Sun Microsystems, Inc.

6 Chapitre 1 Introduction Figure 1-1. Architecture trois-tiers Personne_Stub et Personne_Skeleton. Comme le montre la figure 1-2, l objet métier et le squelette résident dans le tiers intermédiaire, alors que le stub se trouve sur le client. Le stub et le squelette ont pour charge de montrer l objet métier, qui vit dans le tiers intermédiaire, comme s il s exécutait localement sur la machine cliente. Cela se fait au travers d une forme de protocole d invocation de méthode distante (RMI remote method invocation). Un protocole RMI est utilisé pour communiquer les invocations de méthode sur un réseau. CORBA, Java RMI et Microsoft.NET utilisent tous leur propre protocole RMI. 4 Chaque instance de l objet métier dans le tiers intermédiaire est enveloppé par une instance de sa classe squelette. Le squelette est lié à un port et une adresse IP, il attend des requêtes venant du stub. Le stub réside sur la machine cliente et il est connecté au squelette via le réseau. Le stub agit comme un représentant de l objet métier pour le client et il a en charge la communication des requêtes à l objet métier au travers du squelette. La figure 1-2 illustre le processus de communication d une invocation de méthode allant du client à l objet serveur, puis revenant au client. Le stub cache au client les détails de communication spécifiques au protocole RMI, et le squelette les cache à la classe d implémentation. L objet métier implémente une interface publique déclarant ses méthodes métier. Le stub implémente la même interface que l objet, mais les méthodes du stub ne contiennent pas la logique métier. À la place, elles implémentent les opérations réseau nécessaires à la redirection des requêtes vers l objet métier et elles reçoivent les résultats. Quand un client invoque une méthode métier sur le stub, la requête est envoyée sur le réseau en convertissant en un flot de données le nom de la méthode invoquée et les va- 4. L acronyme RMI n est pas spécifique à Java RMI. Cette section emploie le terme RMI pour décrire les protocoles d objets distribués de façon générale. Java RMI est la version pour le langage Java du protocole d objets distribués.

Architectures à objets distribués 7 leurs passées en paramètre, jusqu au squelette. Quand le squelette reçoit le flot entrant, il l analyse afin de déterminer la méthode invoquée, puis il invoque la méthode correspondante sur l objet métier. Toute valeur retournée par la méthode invoquée sur l objet métier est convertie en un flot renvoyé au stub par le squelette. Le stub retourne ensuite la valeur à l application client comme s il avait appliqué la logique métier localement. Écrire votre objet distribué Figure 1-2. Boucle RMI La meilleure façon d illustrer le fonctionnement des objets distribués est de vous montrer comment en implémenter un vous-même, avec votre propre protocole d objets distribués. Vous pourrez ainsi apprécier ce qu un véritable protocole d objets distribués comme CORBA réalise. Les systèmes d objets distribués comme DCOM, CORBA et Java RMI sont cependant bien plus complexes et robustes que le simple exemple que nous allons développer. Notre système d objets distribués ne sert que d illustration ; ce n est pas une véritable technologie, pas plus qu il ne fait partie des Enterprise JavaBeans. L objectif est de vous aider à comprendre le fonctionnement d un système d objets distribués plus sophistiqué. Voici un objet distribué très simple appelé PersonServer implémentant l interface Person. L interface Person offre deux méthodes adaptées au concept d un objet métier représentant une personne : getage() et getname(). Dans une application réelle, nous définirions certainement bien plus de comportements pour l objet métier Person, mais ces deux méthodes sont bien suffisantes pour notre exemple : public interface Person { public int getage() throws Throwable; public String getname() throws Throwable; L implémentation de cette interface, PersonServer, ne contient rien de surprenant. Elle définit la logique métier et l état d une Person : public class PersonServer implements Person { int age; String name;

8 Chapitre 1 Introduction public PersonServer(String name, int age){ this.age = age; this.name = name; public int getage(){ return age; public String getname(){ return name; Nous avons maintenant besoin de rendre PersonServer accessible par un client distant. C est le travail de Person_Skeleton et Person_Stub. L interface Person décrit le concept d une personne indépendamment de l implémentation. PersonServer et Person_Stub implémentent tous deux l interface de Person car ils sont supposés supporter le concept d une personne. PersonServer implémente l interface afin de fournir la logique métier et l état ; Person_Stub implémente l interface afin de ressembler à un objet métier Person du point de vue du client et relayer les requêtes au squelette, qui à son tour les enverra à l objet lui-même. Voici à quoi ressemble un stub : import java.io.objectoutputstream; import java.io.objectinputstream; import java.net.socket; public class Person_Stub implements Person { Socket socket; public Person_Stub() throws Throwable { /* Créer une connexion réseau au squelette. Utiliser "localhost" ou l adresse IP du squelette s il se trouve sur une machine différente. */ socket = new Socket("localhost",9000); public int getage() throws Throwable { // Quand cette méthode est invoquée, convertir en flot de données // le nom de la méthode pour le squelette. ObjectOutputStream outstream = new ObjectOutputStream(socket.getOutputStream()); outstream.writeobject("age"); outstream.flush(); ObjectInputStream instream = new ObjectInputStream(socket.getInputStream()); return instream.readint(); public String getname() throws Throwable { // Quand cette méthode est invoquée, convertir en flot de données // le nom de la méthode pour le squelette. ObjectOutputStream outstream = new ObjectOutputStream(socket.getOutputStream()); outstream.writeobject("name");

Architectures à objets distribués 9 outstream.flush(); ObjectInputStream instream = new ObjectInputStream(socket.getInputStream()); return (String)inStream.readObject(); Quand une méthode de Person_Stub est invoquée, un jeton String est créé et envoyé par flot au squelette. Ce jeton identifie la méthode invoquée sur le stub. Le squelette analyse le jeton d identification de méthode, invoque la méthode correspondante sur l objet métier et retourne le résultat dans un flot. Quand le stub lit la réponse du squelette, il analyse la valeur et la retourne au client. Du point de vue du client, le stub a traité la requête localement. Examinons maintenant le squelette : import java.io.objectoutputstream; import java.io.objectinputstream; import java.net.socket; import java.net.serversocket; public class Person_Skeleton extends Thread { PersonServer myserver; public Person_Skeleton(PersonServer server){ // Obtenir une référence à l objet métier enveloppé par ce // squelette. this.myserver = server; public void run(){ try { // Créer une socket serveur sur le port 9000. ServerSocket serversocket = new ServerSocket(9000); // Attendre et obtenir une connexion par socket du stub. Socket socket = serversocket.accept(); while (socket!= null){ // Créer un flot entrant afin de recevoir les requêtes du // stub. ObjectInputStream instream = new ObjectInputStream(socket.getInputStream()); // Lire la requête suivante du stub. Bloquer jusqu à ce // que la requête soit envoyée. String method = (String)inStream.readObject(); // Déterminer la méthode invoquée. if (method.equals("age")){ // Invoquer la méthode sur l objet serveur. int age = myserver.getage(); // Créer un flot de sortie pour retourner les valeurs // au stub. ObjectOutputStream outstream = new ObjectOutputStream(socket.getOutputStream()); // Retourner les résultats au stub. outstream.writeint(age); outstream.flush();