Introduction Java EE

Chapitres traits
Que veut dire Java EE ?

Les derniers chapitres taient consacrs la programmation rseau. Ils nous ont permis de matriser un certain nombre de concept, avec :

1. En premier lieu la mise en place d'un service et la communication entre deux machines distantes. 2. Ensuite, la mise en place d'une application Web l'aide de servlets. 3. La communication entre une applet et une servlet qui est un sujet trs intressant. 4. La communication avec une base de donnes grce JDBC, par l'intermdiaire du langage de requte SQL. 5. Et pour finir, un concept vraiment des plus intressant, la mise en oeuvre d'objets distants grce la technologie RMI.

Toute cette technologie que nous venons d'apprendre est vraiment primordiale pour le dveloppement rseau. Toutefois, un certain nombre de sujets n'ont pas encore t abord.
1. Tout d'abord, malgr deux chapitres sur les servlets, il nous manque encore de connatre la gestion des sessions afin de prvoir une communication plus long terme avec un client potentiel. Nous profiterons de Java EE pour parfaire nos connaissance dans ce domaine. 2. Dans le mme domaine, j'ai laiss en suspend le chapitre sur les pages JSP. J'ai prfr attendre Java EE pour cela. 3. Enfin, nous avons eu l'eau la bouche avec les objets distants grce RMI, Java EE est toutefois une technologie beaucoup plus aboutie dans ce domaine.

En fait, tout ce que nous avons appris dans l'tude de la programmation rseaux est un pralable Java EE. Java EE reprend tout ces concepts l, mais va encore plus loin, notamment dans la modularit et la scurit. Java EE est une architecture aboutie et performante, elle a t mise en oeuvre pour le monde des entreprises qui ont besoin d'un systme stable qui accepte facilement la monte en charge sans poser de problme de scurit. Pour terminer, Java EE exploite au maximum la technologie des objets distribus, ce qui permet d'avoir un systme simple utiliser ct clients.

Que veut dire Java EE ?

Java EE signifie Java Entreprise Edition et reprsente essentiellement des applications d'entreprise. Cela inclut le stockage scuris des informations, ainsi que leur manipulation et leur traitement : factures clients, calculs d'amortissement, rservation de vols, etc.
Ces applications peuvent avoir des interfaces utilisateurs multiples, par exemple une interface Web pour les clients, accessible sur Internet et une interface graphique fonctionnant sur les ordinateurs de l'entreprise sur le rseau priv de celle-ci.

Elles doivent grer les communications entre systmes distants, s'occuper automatiquement des diffrents protocoles de commmunication, synchroniser les sources avec ventuellement des technologies diffrentes, et s'assurer que le systme respecte en permanences les rgles de l'activit de l'entreprise, appels rgles "mtier". Pour finir, ces applications s'occupe galement automatiquement de la base de donnes sans que le dveloppeur est intervenir (bien entendu si le besoin s'en fait sentir).

Serveurs d'applications
Tout comme les bibliothques d'interfaces graphiques comme Swing fournissent les services ncessaires au dveloppement d'application graphiques, les serveurs d'applications mettent disposition les fonctionnalits permettant de raliser des applications d'entreprise : communication entre ordinateurs, mis en place de protocole adapts, gestion des connexions avec une base de donnes, prsentation de pages Web, gestion des transactions, etc.
Java EE propose justement un ensemble de bibliothques avec des objets de trs haut niveau pour mettre en oeuvre facilement ses serveurs d'applications. Chacun de ces objets est adapte la situation en correspondant parfaitement au canevas de l'ensemble du processus. Ainsi, les dveloppeurs n'ont pas partir d'une feuille blanche et surtout Java EE permet d'avoir une dmarche standardise.

Qu'est-ce que Java EE ?

Pour de nombreux dveloppeurs, Java EE est souvent synonyme de Entreprise JavaBeans. En fait, Java EE est beaucoup plus que cela. En simplifiant, nous pouvons dire que Java EE est une collection de composants, de conteneurs et de services permettant de crer et de dployer des applications distribues au sein d'une architecture standardise.
Java EE est logiquement destin aux gros systmes d'entreprise. Les logiciels employs ce niveau ne fonctionne pas sur un simple PC mais require une puissance beaucoup plus importante. Pour cette raison, les applications doivent tre constitues de plusieurs composants pouvant tre dploys sur des plateformes multiples afin de disposer de la puissance de calcul ncessaire. C'est la raison d'tre des applications distribues. Java EE fournit un ensemble de composants standardiss facilitant le dploiement des applications, des interfaces dfinissant la faon dont les modules logiciels peuvent tre interconnects, et les services standards, avec leur protocole associ, grce auxquels ces modules peuvent communiquer.

Architecture multitiers
Un des thmes rcurrent du dveloppement d'applications Java EE est la dcomposition de celles-ci en plusieurs niveaux, ou tiers. Gnralement, une application d'entreprise est compose de trois couches fondamentales (d'o le terme dcomposition en trois tiers) : 1. La premire a pour rle d'afficher les donnes pour l'utilisateur et de collecter les informations qu'il saisit. Cette interface est souvent appele couche de prsentation car sa fonction consiste prsenter les donnes l'utilisateur et lui permettre de fournir des informations au systme. La couche prsentation est la partie de l'application responsable de la cration et du contrle de l'interface prsente l'utilisateur et de la validation de ses actions. 2. Sous cette couche de prsentation, on trouve la logique mtier qui permet l'application de fonctionner et de traiter les donnes. Dans une application de paye, par exemple, la logique mtier multiplie les heures travailles par le salaire horaire pour dterminer combien chaque employ doit toucher. La logique mtier est mise en oeuvre partir des rgles mtier. Cette partie de l'application constitue l'essentiel du tiers mdian. 3. Toutes les applications d'entreprise ont besoin d'crire et de lire des donnes. Cette fonctionnalit est assure par la couche d'accs de donnes, galement appele couche de persistance, qui assure la lecture, l'criture partir des diffrentes sources.

Architecture simple tiers

Les applications bureautiques sont conues pour fonctionner sur un ordinateur unique. Toutes les services fournis par l'application - interface utilisateur, persistance des donnes (sauvegarde dans des fichiers propritaires) et logique de traitement de ces donnes - rsident sur la mme machine et sont inclus dans l'application. Cette architecture monolitique est appele simple tiers car toutes les fonctionnalits sont comprises dans une seule couche logicielle.

Architecture client-serveur
Les applications plus complexes peuvent tirer parti d'une base de donnes et accder aux informations qu'elle contient en envoyant des commandes SQL un serveur pour lire et crire les donnes. Dans ce cas, la base de donnes fonctionne dans un processus indpendant de celui de l'application, et parfois sur une machine diffrente. Les composants permettant l'accs aux donnes sont spars du reste de l'application.

La raison de cette approche est de centraliser les donnes afin de permettre plusieurs utilisateurs d'y accder simultanment. Les donnes peuvent ainsi tre partages entre plusieurs utilisateurs de l'application. Cette architecture est communment appele client-serveur, qui dans notre approche peut tre reprsente en deux tiers.

Un des inconvnient de l'architecture deux-tiers est que la logique charge de la manipulation des donnes et de l'application des rgles mtiers affrentes est incluse dans l'application elle-mme. Cela pose problme lorsque plusieurs applications doivent partager l'accs une base de donnes. Il peut y avoir, par exemple, une rgle stipulant qu'un client affichant un retard de paiement de plus de 90 jours verra son compte suspendu. Il n'est pas compliqu d'implmenter cette rgle dans chaque application accdant aux donnes client. Toutefois, si la rgle change et qu'un dlai de 60 jours est appliqu, il faudra mettre jour toutes les applications, ce qui peut tre contraignant.

Architecture trois-tiers
Pour viter cette pagaille, la solution consiste sparer physiquement les rgles mtier en les plaant sur un serveur o elles n'auront tre remise jour qu'une seule fois, et non autant de fois qu'il y a d'applications qui y accde. Cette solution ajoute un troisime tiers l'architecture client-serveur.

Selon ce modle, toute la logique mtier est extraite de l'application cliente. Celle-ci n'est plus responsable que de la prsentation de l'interface l'utilisateur et de la communication avec le tiers mdian. Elle n'est plus responsable de l'application des rgles. Son rle est rduit la couche prsentation.

Un des avantages essentiel de cette architecture est qu'elle rend possible la cration d'applications dans lesquelles les classes dfinies au niveau de la logique mtier sont directement tires du domaine de l'application. Le code de cette couche peut utiliser des classes modlisant les objets du monde rel (par exemple des clients) au lieu de manipuler des requtes SQL complexes.
En plaant les dtails de l'implmentation dans les couches appropries et en concervant des applications fonctionnant avec des classes modlisant les objets du monde rel, les applications sont plus faciles maintenir et faire voluer.

Concepts et spcificits de J2EE

Les termes "client" et "serveur" recouvrent des concepts spcifiques dans le contexte J2EE

Ct client
Un client Java EE peut tre une application console (texte seulement) crite en Java, ou une application dote d'une interface graphique dveloppe en Swing. Ce type de client est appel client lourd, en raison de la quantit importante de code qu'il met en oeuvre. Un client Java EE peut galement tre conu pour tre utilis partir du Web. Ce type de client fonctionne l'intrieur d'un navigateur Web. La plus grande partie du travail est reporte sur le serveur et le client ne comporte que trs peu de code. Pour cette raison, on parle de client lger. Un client lger peut tre une simple interface HTML, une page contenant des scripts JavaScript, ou encore une applet Java si une interface un peu plus riche est ncessaire.

Ct serveur
Les composants dploys sur le serveur peuvent tre classs en deux groupes. Les composants Web sont raliss l'aide de servlets ou de JavaServer Pages (JSP) . Les composants mtiers, dans le contexte Java EE, sont des Entreprise JavaBeans (EJB).

Les conteneurs

Les conteneurs sont les lments fondamentaux de l'architecture Java EE. Les conteneurs fournis par Java EE sont de mme type. Ils fournissent une interface parfaitement dfinie ainsi qu'un ensemble de services permettant aux dveloppeurs d'applications de se concentrer sur la logique mtier mettre en oeuvre pour rsoudre le problme qu'ils ont traiter, sans qu'ils aient se procuper de toute l'infrastructure interne.
Les conteneurs s'occupent de toutes les tches fastidieuses lies au dmarrage des services sur le serveur, l'activation de la logique applicative, la gestion des protocoles de communication intrinsque ainsi qu' la libration des ressources utilises.

Java EE et la plate-forme Java disposent de conteneurs pour les composants Web et les composants mtiers. Ces conteneurs possdent des interfaces leur permettant de communiquer avec les composants qu'ils hbergent. Les principaux conteneurs Java EE sont notamment ceux ddies aux EJB, aux JSP, aux servlets et aux clients Java EE.

Les servlets Java

Nous avons dj trait les servlets dans deux cours prcdents. Rappelons de quoi il s'agit :
Vous avez sans doute l'habitude d'accder des pages HTML statiques l'aide d'un navigateur envoyant une requte un serveur Web, celui-ci renvoyant alors une page stocke sur son disque dur. Dans cette configuration, le serveur joue le rle d'un bibliothcaire virtuel qui renvoie le document demand. Ce modle ne permet pas d'accder des pages dynamiques, dont le contenu serait cr la demande. Supposons par exemple que le client souhaite obtenir une liste des documents HTML correspondant certains critres. Dans ce cas, il est ncessaire de crer une page HTML diffrente en fonction des critres spcifis par le client.

Une servlet Java est un composant implmentant l'interface javax.servlet.Servlet. Son invocation est la consquence de la requte du client, dirig vers cette servlet. Bien que cela ne soit pas obligatoire, gnralement les servlets sont associes l'environnement Web et aux requtes HTTP. Le serveur Web reoit une demande adresse une servlet sous la forme d'une requte HTTP. Il transmet la requte la servlet concerne, puis renvoie la rponse fournie par celle du client . La servlet reoit galement les paramtres de la requte envoye par le client. Elle peut alors effectuer toutes les oprations ncessaires pour construire la rponse avant de renvoyer celle-ci sous forme de code HTML.

Le conteneur de servlets permet une gestion facile des sessions qui autorise l'criture d'applications Web complexes. Les servlets peuvent galement utiliser les composants JavaBeans (qui n'ont rien en commun avec les Entreprise JavaBeans, en dehors de leur nom). Les JavaBeans sont tout simplement des classes connexe la servlet et qui permettent d'augmenter de manire significative la modularit des applications. Dans ce cas l, nous avons la mme dmarche que pour la fabrication d'une application classique constitue de plusieurs classes qui forment les briques de l'ensemble.

Exemple de servlet
package formulairepersonne; import import import import javax.servlet.*; javax.servlet.http.*; java.io.*; java.util.*;

public class Formulaire extends HttpServlet { //Traiter la requte HTTP Get public void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { response.setContentType("text/html"); // type MIME pour l'en-tte http --> Page HTML PrintWriter out = response.getWriter(); out.println("<html>"); out.println("<head><title>Enregistrement coordonnes</title></head>"); out.println("<body bgcolor=orange text=yellow>"); out.println("<h2>Enregistrement de vos coordonnes effectu</h2>"); out.println("<hr width=75%>"); out.print("<p><b>Bonjour "+ request.getParameter("civilite")+" "); out.print(request.getParameter("prenom")+" "); out.println(request.getParameter("nom")+"."); int ge = Integer.parseInt(request.getParameter("age")); String message = "Vous tes un"; if (ge>0 && ge<12) message += " enfant."; if (ge>=12 && ge<18) message += " adolescent."; if (ge>=18 && ge<60) message += " adulte."; if (ge>=60) message += "e personne du troisime ge."; out.println("<p>"+ message +"</b></body></html>"); } //Traiter la requte HTTP post public void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { doGet(request, response); } }

Les JavaServer Pages

Les JavaServer Pages, ou JSP, servent, comme les servlets, crer du contenu Web de manire dynamique. Ces deux types de composants reprsentent eux seuls un trs fort pourcentage du contenu des applications Web. Crer des servlets consiste construire des composants Java capables de produire du code HTML. Dans de nombreux cas, cela fonctionne sans problme. Toutefois, il n'est pas facile, pour les personnes charges de concevoir l'aspect visuel des pages Web, de manipuler du code Java, auquel elles n'ont probablement

pas t formes. C'est la raison d'tre des JavaServer Pages. Les JSP sont des documents de type texte, contenant du code HTML ainsi que des scriptlets (et/ou des expressions), c'est--dire des morceaux de code Java.
Les dveloppeur des pages JSP peuvent mlanger du contenu statique et du contenu dynamique. Ces pages tant bases sur du code HTML ou XML, elles peuvent tre cres et manipules par du personnel non technique. Un dveloppeur Java peut tre en charge de la cration des scriptlets (et/ou des expressions) qui s'interfaceront avec les sources de donnes ou effectueront des calculs permettant la gnration de code dynamique.

Les pages JSP s'excutent, en fait, sous la forme de servlets. Elle sont donc compiles comme les servlets et sont donc plus rapides dans leur traitement. Elles disposent du mme support pour la gestion des sessions. Elles peuvent galement charger des JavaBeans et appeler leurs mthodes, accder des sources de donnes se trouvant sur des serveurs distants, ou effectuer des calculs complexes.

Les Entreprise JavaBeans

Gnralement, lorsque parlons de Java EE, nous pensons immdiatement au EJB. Les EJB reprsentent un niveau beaucoup plus sophistiqu, aux objets distants que nous avons dj mis en oeuvre lors de l'tudes des RMI. Faisons un petit retour sur les RMI.

RMI
RMI (Remote Method Invocation) correspond au modle d'invocation distance mis en oeuvre par Java. Grce RMI, Java permet l'accs via un rseau aux objets se trouvant sur un ordinateur distant. Pour crer un objet avec RMI :

1. Il faut d'abord concevoir une interface tendant l'interface java.rmi.Remote. Cette interface dfinit les oprations que doit exposer l'objet accessible distance. 2. L'tape suivante consiste concevoir l'objet comme une classe implmentant l'interface pralablement dfinie. Cette classe doit tendre la classe java.rmi.UnicastRemoteObject qui fournit les moyens ncessaires la communication entre l'objet et ses clients. 3. Enfin, il reste dfinir l'application qui crera une instance de cet objet et l'enregistrera dans le registre RMI. Ce registre est un simple service de localisation permettant aux ordinateurs distants de trouver l'objet l'aide du nom qui lui est attribu. 4. Ce service est mis contribution par l'application cliente, qui demande au registre l'objet nomm et effectue un casting vers l'interface cre lors de la premire tape.

Ce que fournie les bases de l'implmentation d'une architecture client / serveur :

1. Un registre pour la localisation des composants, 2. Les moyens de communication ncessaires pour l'invocation des oprations et le passage des paramtres et des valeurs de retour, 3. Ainsi qu'un mcanisme simple pour la gestion des accs aux ressources systmes afin d'offrir une protection contre une attaque de scurit de la part d'un programme distant (Dans le chapitre sur RMI, nous n'avons pas implment cette partie).

Toutefois, RMI est une technologie lgre, insuffisante pour satisfaire les besoins des applications d'entreprises distribues. Il lui manque les lments essentiels que sont une gestion avance de la scurit, le contrle des transactions ou la facult de rpondre efficacement une monte en charge. Bien qu'elle fournisse les classes fondamentales, elles ne constitue pas une infracstructure pour un serveur d'applications devant recevoir les composants mtier et s'adapter l'volution du systme et de sa charge. Il reste notamment ncessaire d'crire les applications serveur et client.

Les Entreprises JavaBeans

C'est l qu'intervient les Entreprise JavaBeans. Les EJB sont des composants Java qui implmentent la logique mtier de l'application, ce qui permet cette logique d'tre dcompose en lments indpendants de la partie de l'application qui les utilise. L'architecture Java EE comporte un serveur qui sert de conteneur pour les EJB. Ce conteneur charge tous les composants la demande et invoque les oprations qu'ils exposent, en appliquant les rgles de scurit et en contrlant les transactions. Cette architecture est trs complexe mais heureusement totalement transparente au dveloppeur. Le conteneur d'EJB fournit automatiquement toutes la plomberie et le cblage ncessaire pour la ralisation d'applications d'entreprise. La cration des EJB ressemble beaucoup celle des objets RMI. Cependant, le conteneur fournissant des fonctionnalits supplmentaires, vous pouvez passer plus de temps crer l'application au lieu d'avoir grer des problmes d'intendance tels que la scurit ou les transactions. Il existe plusieurs types d'EJB :

1. Les beans sessions : Les beans sessions comme leur nom l'indique, ont une dure de vie correspondant celle de la "conversation" ou "session" entre l'application cliente et le composant. Ces beans servent fournir l'application cliente divers services conus par le dveloppeur. Selon le choix de celui-ci, un bean session peut maintenir un tat pendant toute la dure de la session (c'est--dire concerver l'tat des attributs internes aux objets de faon maintenir la conversation avec le client) ou au contraire sans tat (stateless), ce qui signifie qu'il fournit un accs des mthodes implmentant la logique applicative (comme RMI), mais ne concerve aucun rsultat auquel le client pourrait faire rfrence ultrieurement. 2. Les beans entits : Les beans entits reprsentent des objets mtier du domaine de l'application tels que clients, factures, produits, etc. Ces objets persistent de faon pouvoir tre rutiliss. Le conteneur de l'architecture J2EE s'occupe de tous les dtails de cette tche de persistance. Rappelons que la persistance correspond l'utilisation d'une base de donnes qui stocke la valeur des attributs de chacun de ces beans entits. Avec les beans entits, il n'est pas du tout ncessaire de matriser le langage SQL ainsi que la connectivit JDBC. De fait, la base de donnes de type relationnelle devient une base de donnes de type objet. Ce type de bean est vraiment intressant puisque sans cette technologie, le dveloppeur passe gnralement beaucoup de temps la gestion de la base de donnes. Avec un bean entit, le dveloppeur ne voit pas du tout la base de donnes et donc ne s'en occupe pas ; il peut alors passer tout son temps sur l'application elle-mme. 3. Les beans contrls par messages : Le troisime type d'EJB, le bean contrl par message, fournit un modle de composant permettant d'couter un service de messages. La plateforme J2EE dfinit une queue de message, qui est une sorte de file d'attente dans laquelle les applications peuvent placer des messages. Elles peuvent galement s'abonner une queue de messages. L'avantage de cette architecture est que les composants qui utilisent les messages n'ont pas besoin de savoir qui les a envoys. Il leur suffit d'identifier la queue contenant les messages. C'est une sorte de flot d'informations que les composants ont en commun sans que ces dernires soient ddies un composant en particulier. Un systme de gestion de portefeuilles d'actions est un exemple d'utilisation d'une telle queue. Les cours des actions sont envoys une queue sous forme de message, qui sont consomms par les composants qui ont besoin de connatre ces cours. Avec les beans contrls par messages, il est possible de crer des composants rpondant aux messages concernant les cours en prenant automatiquement certaines dcisions en fonction de leurs variations.

L'architecture MVC

Dans les exemples que nous avons mis en oeuvre dans tout le chapitre sur la programmation rseau notamment au niveau des servlets, le modle architectural utilis tait le modle 1. Dans ce type d'architecture, les requtes HTTP sont gres par des composants Web, qui reoivent ces requtes, crent les rponses et les retournent aux clients. Un seul composant (la servlet) est donc responsable de la logique d'affichage, de la logique mtier et de la manipulation des requtes. Il existe une autre architecture, appele Modle 2, qui partage les responsabilits. Ce modle est appel Modle - Vue - Contrleur ou MVC. Dans cette architecture, trois composants permettent de sparer clairement les trois activits.

Modle 1
Dans l'architecture Modle 1, la logique mtier, la logique d'affichage et la manipulation des requtes sont mlangs dans un mme composant. Cette architecture conduit placer du code Java dans des JSP ou du code HTML dans les servlets. Lorsqu'il s'agit d'une petite application, cela ne pose pas de problme, et le sujet est correctement trait. Mais imaginez une application relle avec des pages Web trs sophistiques et un traitement complexe des donnes. Une telle application est d'une maintenance trs dlicate.

Modle MVC
Dans le Modle 2 ou Modle MVC, un composant est charg de recevoir les requtes, un autre de traiter les donnes et un troisime de prparer l'affichage. Si les interfaces entre ces trois composants sont clairement dfinies, il devient facile d'en modifier un sans toucher aux deux autres. Dans ce contexte, il est d'ailleurs possible de prvoir plusieurs affichages, un pour un PC par exemple, et un autre pour un PDA.

Les composants d'une application MVC sont donc rparti en trois catgories : le modle, la vue, le contrleur.

1. Modle : Le modle englobe la fois la logique mtier et les donnes sur lesquelles il opre. Toute classe Java peut jouer le rle du modle et de nombreuses applications Web utilisent uniquement des servlets ou des JSP et des classes ordinaires implmentant cette logique. Toutefois, les EJB sont des composants parfaits pour ce rle. 2. Vue : Une fois la requte traite, le contrleur dtermine quel composant doit tre employ pour afficher les donnes. Dans les applications les plus simples, le composant contrleur peut aussi jouer le rle de vue. Dans les systmes plus complexes, la vue et le contrleur sont des composants distincts. Les pages JSP sont parfaitement adaptes la vue puisque ces dernires accueillent de faon naturelle le balisage HTML. 3. Contrleur : Les composants de cette catgorie reoivent les requtes des clients, les traitent et les transmettent aux composants chargs de traiter les donnes. Ils les dirigent ensuite vers les composants responsables de la vue. Tous les composants Web, tel un EJB, une servlet, ou une JSP peut jouer ce rle. Toutefois, les servlets sont des composants dont la structure est la plus adapte. Une servlet est conue pour recevoir les requtes des clients et leur retourner une rponse, ce qui est prcisment le rle du contrleur.

Les services Web

Le Web est de plus en plus le support privilgi des applications d'entreprise. Les services Web constituent le dveloppement ultime dans ce domaine. Un service Web est un systme logiciel identifi par une URI, dont l'interface publique et les liens sont dfinis l'aide d'XML. Ce systme peut tre dcouvert ou localis par d'autres systmes logiciels. Ces systmes peuvent interagir avec le service d'une manire prescrite par sa dfinition, en utilisant des messages XML transmis l'aide des protocoles d'Internet.
La norme impose les contraintes suivantes :

1. XML est utilis pour publier les descriptions des services. 2. Ces descriptions peuvent tre dcouvertes grce des registres. 3. Des messages XML sont employs pour invoquer ces services et retourner les rsultats aux clients.
Le W3C a tabli WSDL (Web Service Description Language - Langage de description des services Web) comme le format utilis pour la description des services et la faon d'y accder. Pour appeler un service, un client doit tre capable d'obtenir sa description. Les registres XML fournissent le moyen de publier les descriptions des services, d'effectuer les recherches et d'obtenir les informations WSDL les concernant. Il existe plusieurs services de registre XML dont UDDI (Universal Description, Discovery and Integration - Description, dcouverte et intgration universelle). JARX fourni une API permettant d'accder ces registres de manire indpendante de leur implmentation. SOAP (Simple Object Access Protocol - Protocole simple d'accs aux objets) est l'esperando des services Web et de leurs clients, utiliss pour l'invocation et le passage des paramtres et des valeurs de retour. SOAP dfinit les messages XML standards et le mode de conversion des donnes permettant un client d'appeler un service et de lui passer des paramtres. Grce l'API JAX-RPC, il est possible de dvelopper une interface simple sans se proccuper de la technique sousjacente. Bien entendu, Java EE fournit un conteneur pour les services Web et un modle de composants permettant de les dployer facilement.