Ré-architecture et migration d une application standalone vers un serveur applicatif multi-tiers dans un contexte JAVA-SAP

Transcription

1 Ré-architecture et migration d une application standalone vers un serveur applicatif multi-tiers dans un contexte JAVA-SAP Ionel Dembski Sous la direction de Peter Daehne, Professeur HES Département d informatique de gestion Laboratoire de technologies objet Hautes Ecoles Specialisées de Suisse Occidentale HES-SO Haute Ecole de Gestion de Genève 25 novembre 2005

2 Table des matières 1 Architecture Comprendre les architectures multi-tiers Les trois niveaux d abstraction d une application Architecture n-tiers ou architecture distribuée Le tier Client Le tiers Web Le «Middleware» ou Tiers du milieu Architectures multi-tiers dans un contexte Java Architecture globale actuelle de l application Coté client Coté serveur, gestion de la persistance Gestion de la persistance dans l environnement cible Technologies applicative cible spécialisée JCo - Java connector for SAP Remote Function Call (RFC) RFC Library Appel de fonctions Java depuis SAP R/ Architecture Jco WebServices ABAP sur serveur SAP WAS Principe de fonctionnement BEA Weblogic Plate-forme J2EE Architecture du serveur d application Weblogic Composant logiciel d une architecture multi-tiers Structuration des couches applicatives Accès au données Struts Qu est ce que Struts? Viabilité de Struts sur le plan architectural Liaison de Struts à J2EE?

3 TABLE DES MATIÈRES ii 3 Passage d un système objet a un système n-tiers La modélisation, facteur de réussite? Pourquoi modéliser Que modéliser? Les niveaux d abstraction, jusqu ou aller? Difficultés inhérentes à une modélisation web Comment modéliser les flux Les machines d états pour représenter et modéliser les pages Travailler avec les couches, division de l application Le couplage des couches, vrai ou faux problème? Les couches aplicatives, à chacune sa résponsabilité Les «Design Pattern» pour découpler les couches Architecture de l application Démarche de transformation Analyse Examens des modèles existants Compréhension et intégration dans l architecture cible Quels modèles utiliser? Design et architecture Etude de faisabilité Enjeu de cette réarchitecture Environnement de développement BEA Contraintes architecturales Contraintes au niveau de l IHM Contraintes liées à l utilisation des Web services Respect de la séparation des couches applicatives Conception et tests Tenir compte des modèles Comment tester une application Web Conclusion 44 Bibliographie 46 Glossaire 47 Annexes 48.1 Diagramme d états-transition Diagramme de classe Diagramme des packages

4 Table des figures 1.1 Architecture - Tiers client Architecture - Tiers web Architecture - Détails du tiers web Architecture - Partie «Middleware» Scénario d utilisation et de création d une RFC Architecture du JCO Intégration BEA - SAP Architecture n-tiers Architecture de Struts Exemple d une Action avec annotations Analyse opérationnelle Architecture déorganisée à base de composants Architecture «Delegate» Architecture «Facade» Architecture «DAO» Architecture finale

5 Avant-propos Je tiens tout particulièrement à remercier l entreprise Rolex SA qui m a permit de réaliser mon travail de diplôme dans de très bonnes conditions. J ai pu intégrer une équipe dynamique qui a su me conseiller et m apporter toute l aide sur la façon de mener a bien mon travail. Je souhaite remercier également M. Dominique Fazi, responsable du département développement, qui a bien voulu m accorder sa confiance en me permettant de faire parti de son équipe. Mes remerciements vous aussi à M. Damien Mimoun, consultant chez Serial Développement, qui m a aider sur le plan technique concernant l environnement Rolex sans quoi, mon travail aurait été grandement ralenti. Je souhaite également remercier M. Qin Pang, pour son aide, et M. Bombenger Jean pour sa joie et sa bonne humeur qu il nous a apportée régulièrement au cours de ce mémoire.

6 Introduction La migration et la réarchitecture d une application n est pas une chose aisée. Dans de nombreux cas, le portage d une application requiert la mise en oeuvre de technologies inconnues et qui peuvent poser des problèmes lors de l implantation. On dit souvent, et parfois on le fait (c est pire) que les modèles et par conséquent la modélisation n est pas importante. Cependant, lorsque la migration d une application mets en jeu différents système, il est difficile d avoir une vue globale de ce qui doit être fait par nos soin ou non. Le cadre de ce mémoire est la réarchitecture et la migration d une application standalone développé en Java. L hôte de la future application est un serveur Weblogic 8. Contrairement à la première application, la gestion de la persistance ne va pas se faire au travers d une base de donnée Oracle, mais à travers des Web services qui vont «attaquer» un système SAP 4.6. Dans ce cas, les modèles sont extrêmement nécessaires. Ce n est pas tant la complexité des modèles, mais la multitude d environnements qui entre en jeu qui font de cette réarchitecture un problème très intéressant à traiter. Je vais donc m attarder sur l études des environnements multi-tiers ainsi que sur le débroussaillage de l application existence pour comprendre comment celle-ci à été construite. Après quoi, je vais entrer en matière sur les différentes technologies qui vont être mise en oeuvre lors de la phase de développement de l application vers le système cible. Etant données que les modèles vont jouer un grand rôle dans la conception, je vais proposer une solution quand à la modélisation des pages Web, et proposer ma démarche de réarchitecture.

7 Chapitre 1 Architecture 1.1 Comprendre les architectures multi-tiers Les trois niveaux d abstraction d une application D une manière générale, une application peut être découpée en trois niveaux d abstraction clairement définis. La couche présentation, ou encore IHM (Interface homme machine), permet l interaction entre l utilisateur final de l application et le reste du système. Cette couche gère la souris, les saisies clavier. Elle doit être le plus ergonomique possible. La logique applicative, les traitements décrivant les travaux à réaliser par l application. Ils peuvent être découpés en deux familles : Les traitements locaux, regroupant les contrôles effectués au niveau du dialogue avec l IHM. Les traitements globaux, constituant l application elle-même. Cette couche, appelée Business Logic ou couche métier, contient les règles internes de l application. Les données, ou plus exactement l accès aux données, regroupant l ensemble des mécanismes permettant la gestion des informations stockées par l application. Ces trois niveaux peuvent être imbriqués ou repartis de différentes manières entre plusieurs machines physiques. Le noyau de l application est composé de la logique de présentation et de la logique des traitements. Le découpage et la répartition de ce noyau permettent de distinguer des architectures applicatives qui vont de l architecture 1-tiers à l architecture n-tiers.

8 1.1 Comprendre les architectures multi-tiers Architecture n-tiers ou architecture distribuée L architecture n-tiers est aussi appelée architecture distribuée où architecture multi tiers. Contrairement a ce que l on pourrait imaginer, l architecture n-tiers qualifie la distribution d application entre plusieurs services, et non la multiplication des couches, les trois niveaux d abstractions d une application sont toujours pris en compte. Séparer les couches métier peut être une opération fastidieuse dans le cas d une réarchitecture applicative. Cependant, celle-ci est facilitée par l utilisation de composants métier spécialisés et indépendants, introduits par les concepts orientés objets. Elle permet de tirer pleinement partie de la notion de composants métier réutilisables. Ces composants rendent un service standard voir même générique. Ils doivent être indépendant et totalement découplés de l application. Ils sont capables de communiquer entre eux et peuvent donc coopérer en étant implantés sur des machines physiques distinctes Le tier Client FIG. 1.1 Architecture - Tiers client Lorsque l on parle de client, nous pensons souvent à un programme externe. Par exemple la relation qu il y a entre une base de donnée Oracle et son outil d administration. L outil d administration peut être qualifié dans ce cas, de client de la base de donnée.

9 1.1 Comprendre les architectures multi-tiers 6 Les clients peuvent se repartir en trois grandes catégories : 1. Les navigateurs web avec les protocoles HTTP et HTTPS, basés essentiellement sur les langages HTML et XML. 2. Les clients lourds, applets basés sur les protocoles IIOP / RMI, CORBA. 3. Les Web-services sur le principe de SOAP, WSDL et ebxml Le tiers Web FIG. 1.2 Architecture - Tiers web Le tiers web est essentiel au fonctionnement futur de l application qui va subir la ré-architecture. Il en est en quelque sorte le coeur. En effet, ses attributions et ses responsabilités sont aussi nombreuses que variées. 1. Il reçoit les requêtes http des clients et renvoie les réponses correspondantes. 2. Il sépare la couche présentation qui est spécifique au client, de la couche métier. 3. Il génère du contenu dynamiquement. 4. Il transforme des requêtes http dans un format compris par l application. 5. Il contient la logique du flot de présentation. 6. Il identifie la session de l utilisateur. 7. Il supporte plusieurs types de clients. Bien que ses responsabilités soient nombreuses, le serveur web ne peut pas tout gérer lui-même. Pour effectuer certaine tâches, il doit en déléguer la responsabilité à une ou plusieurs entités applicatives qui pourront traiter la demande, et lui renvoyer le résultat. 1 Elect. Business Exchange Specification

10 1.1 Comprendre les architectures multi-tiers 7 Architecture du Tiers web FIG. 1.3 Architecture - Détails du tiers web Comme mentionné plus haut, le serveur web ne peut à lui seul assumer toutes ces responsabilités. C est pourquoi, des extensions serveurs peuvent lui êtres ajoutées afin de combler ses lacunes. Il existe différentes possibilités d étendre les fonctions premières d un serveur web. Notamment : 1. CGI / FastCGI (Common Gateway Interface). 2. ASP (Active Server Pages). 3. Java Servlets, nécessite un conteneur Java. 4. JSP (Java Server Pages). 5. PHP, Python. Etant donnée que le serveur web connaît ses possibilités ainsi que ses extensions, il pourra déléguer les requêtes qui lui sont attribuées aux extensions appropriées.

11 1.2 Architectures multi-tiers dans un contexte Java Le «Middleware» ou Tiers du milieu FIG. 1.4 Architecture - Partie «Middleware» Le middleware est une partie importante d une architecture n-tiers. On appelle ici middleware, littéralement «élément du milieu», l ensemble des couches réseau et services logiciel qui permettent le dialogue entre les différents composants d une application répartie. Ce dialogue se base sur un protocole applicatif commun, défini par l API du middleware. Le Gartner Group définit le middleware comme une interface de communication universelle entre processus. Il représente véritablement la clef de voûte de toute application client-serveur. L objectif principal du middleware est d unifier, pour les applications, l accès et la manipulation de l ensemble des services disponibles sur le réseau, afin de rendre l utilisation de ces derniers presque transparente. En effet, celui-ci a, entre autre la responsabilité de gérer les composants logiciel mis à disposition pour d autres applications. Le middleware offre des services aux composants, tel que le moyen de connexion à un SGBD (persistance), la gestion des transactions ainsi que l authentification. 1.2 Architectures multi-tiers dans un contexte Java Dans le cadre de cette étude, le middleware est contenu dans un serveur BEA Weblogic 8.1. Toutefois, ce serveur ne joue pas seulement le rôle d un middleware. En effet, il intègre aussi un serveur Web complet. Un des avantages majeurs de J2EE est de faire abstraction de l infrastructure d exécution. En effet, J2EE spécifie les rôles et les interfaces pour les applications, ainsi que l environnement d exécution dans lequel les applications sont déployées. Ceci permet

12 1.2 Architectures multi-tiers dans un contexte Java 9 aux développeurs d application de ne pas avoir a reprogrammer les services d infrastructure. Le serveur J2EE fournit aux applications un ensemble de services comme les connexions aux bases de données, la messagerie, les transactions... L architecture J2EE permet d unifier l accès à ces services au sein du serveur d application. La spécification de la plateforme J2EE prévoit un ensemble d extensions Java standard que chaque plate-forme J2EE doit prendre en charge : JNDI : JNDI est une extension JAVA standard qui fournit une API uniforme permettant d accéder à divers services de noms et de répertoires. Derrière un nom JNDI, il peut y avoir un appel à des services CORBA, DNS, NIS, LDAP... En fait, JNDI permet de localiser et d utiliser des ressources. Authentification : J2EE fournit des services d authentification en se basant sur les concepts d utilisateur, de domaines et de groupes. JDBC : Java Database Connectivity est une API qui permet aux programmes Java d interagir avec toutes les bases de données SQL. Servlet : Un servlet est un composant coté serveur, écrit en Java, dont le rôle est de fournir une trame générale pour l implémentation de paradigmes " requêteréponse ". Ils remplacent les scripts CGI tout en apportant des performances bien supérieures. JSP : La technologie JSP (JavaServer Pages) est une extension de la notion de servlet permettant de simplifier la génération de pages web dynamiques. Elle se sert de balises semblables au XML ainsi que de scriplets Java afin d incorporer la logique de fabrication directement dans le code HTML. JSP est un concurent direct de l ASP et du PHP. JMS : Java Messaging Service est à la fois une ossature et une API permettant aux développeurs de construire des applications professionnelles qui se servent de messages pour transmettre des données. JTA : La spécification JTA (Java Transaction API) définit des interfaces standards entre un gestionnaire de transactions et les éléments impliqués dans cellesci : L application, le gestionnaire de ressources et le serveur. EJB : Chaque instance d un EJB se construit dans conteneur EJB, un environnement d exécution fournissant des services (Sécurité, Communications, Cycle de vie...). Un client n accède JAMAIS directement à un composant. Il doit pour cela passer par une l appel à une «Factory méthode» qui va lui retourner une référence vers une instance de l EJB concerné. L interface locale décrit le cycle d existence du composant en définissant des méthodes permettant de le trouver, de le créer, de le détruire. Et L interface distante spécifie les méthodes que ce composant présente au monde extérieur.

13 1.3 Architecture globale actuelle de l application Architecture globale actuelle de l application L application existante est très clairement construite sur un modèle d architecture deux tiers. Dans une architecture deux tiers, encore appelée client-serveur de première génération ou client-serveur de données, le poste client se contente de déléguer la gestion des données à un service spécialisé. Ce type d application permet de tirer partie de la puissance des ordinateurs déployés en réseau pour fournir à l utilisateur une interface riche, tout en garantissant la cohérence des données, qui restent gérées de façon centralisée Coté client Le dialogue entre le client et le serveur se résume à l envoi de requêtes et au retour des données correspondantes aux requêtes. Ce dialogue nécessite l instauration d une communication entre les deux parties. Comme vu précédemment, cette communication est établie via Jdbc dans le but de : 1. Authentifier l utilisateur. 2. Effectuer les différentes requêtes nécessaires à l exécution de l application. Bien que l application suive le principe du client-serveur, elle n a pas été développée en tenant compte des techniques de Génie logiciel. Aucune couche applicative ressort clairement. Néanmoins, une séparation a été faite du point de vue logique en ce qui concerne les packages qui la composent. Trois packages distincts ont été définis : 1. Un package «ghc» qui contient l application cliente. 2. Un package «gha» qui contient l application cliente d administration du système. 3. Un package «common» qui regroupe les différentes classes communes aux deux applications, notamment l accès aux données Coté serveur, gestion de la persistance La gestion des données est prise en charge par un SGBD Oracle8i s exécutant sur un serveur dédié de type HP-UNIX. Ce dernier est interrogé en utilisant un langage de requête qui est SQL. 1.4 Gestion de la persistance dans l environnement cible La gestion future de la persistance va être tout autre. En effet, cette gestion va toujours se faire sur la base d un serveur Oracle, mais sa gestion, tant au niveau des transaction, des exceptions et des contrôles d erreurs va être dévolue au système SAP.

14 1.4 Gestion de la persistance dans l environnement cible 11 Afin de pouvoir enregistrer les données, des interfaces au sens propre du terme vont être mis à notre disposition. De ce fait, les insertions, les récupérations et les modifications de données ne vont plus être effectues au moyen de traitements SQL standards, mais par l intermédiaire de Web services. Ces Web services sont, pour la plupart standards à SAP, et pour d autres crées spécifiquement pour l application. Ces Web services sont de type ABAP. Une connexion Jco est donc nécessaire entre le Web Application Server de SAP et SAP R/3. Un fichier WSDL 2 par Web service est requis pour décrire les fonctions que celuici mets à notre disposition. 2 Web Services definition langage

15 Chapitre 2 Technologies applicative cible spécialisée 2.1 JCo - Java connector for SAP SAP Java Connector est un outils basé sur le concept de pakage Java qui permet a une application standalone ou Web-based de pouvoir communiquer avec un système SAP. Cette API est bidirectionnelle. Elle supporte une communication du monde Java vers SAP et du monde SAP vers Java. De ce fait, grâce a une grande interaction entre ces deux système, cela permets une interopérabilité accru. JCO est essentiel entre le moteur J2EE de SAP et le serveur d application de SAP. Il agit en tant que Java-Wrapper pour avoir accès au librairie RFC Remote Function Call (RFC) RFC est un protocole SAP qui simplifie la programmation des processus de communication entre les systèmes. Ces RFC permettent au programmeur d appeler des fonctions prédéfinis situées sur un système distant. Ces même RFC encapsule tout le processus de communication, les paramètres de transfert de l information aussi que la gestion des exceptions levées durant le processus de communication. Dans le moteur J2EE du serveur d application SAP 6.20, les RFC sont utilisées pour connecter des requêtes J2EE au monde ABAP.

16 2.1 JCo - Java connector for SAP 13 FIG. 2.1 Scénario d utilisation et de création d une RFC 1. Au demarrage du moteur RFC, une connection est établit avec l annuaire SAP. 2. Après quoi, le moteur RFC s enregistre auprès du «Gateway». 3. Un appel RFC s effectue vers SAP Le «Gateway» renvoie l appel vers le moteur RFC. 5. Le moteur RFC cherche dans le JNDI un EJB correspondant a la fonction demandée. 6. Le moteur RFC appel «processfunction(jco.function)» contenu dans l EJB. 7. Le resultat de l appel est passé au «Gateway» 8. Le «Gateway» transfert le resultat a SAP RFC Library Les librairies RFC offre une interface a un système SAP. Grâce a ces librairies, les développeurs ont la possibilité d appeler n importe quelles fonctions contenu dans un système SAP depuis une application externe. De plus, les librairies RFC permettent de concevoir des programmes RFC qui serons stocker sur le serveur SAP. Ces programmes personnalisés seront accessible a partir de n importe quelle serveur SAP R/3 ou une application externe. 1 Attention, la fonction doit être definie dans l annuaire avant l appel.

17 2.1 JCo - Java connector for SAP Appel de fonctions Java depuis SAP R/3 Dans l environnement JCO, la classe JCO.Server peut être utilisé afin de créer une RFC coté serveur. Après avoir été créee, la RFC est enregistrée dans le «Gateway» SAP et mappé avec un ID. Dans SAP, le couple ID et «Gateway» permettent de définir l adresse TCP/IP de déstination. De ce fait, du coté applicatif Java, lorsque SAP appelera une fonction Java, celle-ci sera du type handlerequest(jco.function function) Architecture Jco La connéctivité entre le moteur J2EE de SAP et le serveur d application Web SAP est disponible via différents protocole de communication tel que JCO via RFC, SOAP, RMI etc. Ce type de connéctivité est suffisante pour des applications qui ont un degré de couplage moyennement faible avec SAP. Ce couplage est réalisé à l aide de Web- Services coté SAP. Pour des applications qui ont un couplage plus important, cette FIG. 2.2 Architecture du JCO technique n est pas appropriée. Il faut alors utiliser couplage a l aide de composant J2EE et ABAP.

18 2.2 WebServices ABAP sur serveur SAP WAS WebServices ABAP sur serveur SAP WAS Principe de fonctionnement ABAP est un langage propriétaire de SAP. L architecture et le mode d accès a des Web services SAP diffères selon l utilisation que l on veut en faire. Dans le cas de la réarchitecture de l application et comme nous l avons vu précédemment, la gestion de la persistance va se faire par l intermédiaire de Web services SAP. La totalité des Web services que SAP mets à la disposition des développeurs se trouve sur le serveur R/3. Tout ces Web services sont codés en ABAP. Comment donc faire la liaison entre le serveur BEA, l hôte de l application et SAP? Le principe est simple. SAP mets à disposition un WAS, c est-à-dire un «Web Application Server». Ce WAS communique via des RFC avec le serveur SAP R/3. Le serveur BEA quand à lui ne communique pas directement avec le serveur R/3. Il communique avec le WAS qui lui sert d intermédiaire. Pour cela, SAP fournit les définitions de ces Web services sous forme de WSDL. FIG. 2.3 Intégration BEA - SAP 2.3 BEA Weblogic Plate-forme J2EE Le serveur Weblogic 8.1 implantante la technologie Java 2, Enterprise Edition (J2EE) version J2EE est la plate-forme standard pour le développement d application multi-tiers basé sur le langage Java. La technologie J2EE à été conjointement développé par Sun Microsystems ainsi que d autre Entreprise, entre autre, BEA Systems, le concepteur de Weblogic. Les applications J2EE sont basées sur des composants modulaires standardisés. Le serveur WebLogic fournit un jeu de services complets pour gérer, maintenir et développer ces composants. 2 http : //java.sun.com/j2ee/sdk_1.3/index.html

19 2.3 BEA Weblogic Architecture du serveur d application Weblogic WebLogic est un serveur d application, c est à dire une plate-forme destiné à développer et déployer des applications distribuées multi-tiers. Ce serveur mets en oeuvre le principe de cache d objets et de pool de connections afin d augmenter la disponibilités des ressources ainsi que les performances. Le serveur Weblogic opère dans le tiers milieu d une une architecture n-tiers. Une architecture n-tiers détermine ou les composants logiciels doivent être exécutés en tenant compte des autres composants, du hardware, du réseau et des utilisateurs. Le fait de choisir le meilleur emplacement pour un composant permet de développer des applications plus rapidement et de contrôler les performances, la sécurité, la faisabilité et l évolutivité Composant logiciel d une architecture multi-tiers Les composants logiciels d une architecture n-tiers consiste en fait en trois tiers : Le tiers client contient les programmes exécutés par les utilisateurs, ceci inclus les navigateurs Web. Ces programmes peuvent être écrit en n importe quel langage. Le tiers intermédiaire ou middle tiers contient le serveur WebLogic ou tout autre serveur qui est sollicité par les clients, comme des serveurs Web ou des proxy. Le tiers «Bachend» contient les ressources d entreprises comme les bases de données et par exemple les ERP tel que SAP. Composants client Les clients du serveur utilisent les interfaces standard pour accéder au serveur WebLogic étant donné que ce serveur est un serveur Web a part entière. De ce fait, un navigateur Web peut envoyer une requête en utilisant le protocole HTTP. Etant donné que le serveur produit du contenu dynamique grâce notamment a l emploi de JSP et de servlets, cela permet d avoir des pages personnalisées en fonction des actions de l utilisateur. Cela permet d avoir une plus grande interaction avec celui-ci. Bien entendu, les clients lourds, c est-à-dire ceux écrit en swing, peuvent également avoir accès aux composant du serveur, aux EJB par exemple qui se trouvent dans la couche «Business», ou aux web services. Composants intermédiaires ou «Middle Tiers» Les applications basées sur le principe d une architecture multi tiers requièrent des performances accrues du tiers du milieu. C est pourquoi, le serveur d application doit être choisi judicieusement afin qui celui-ci puisse répondre au besoin de l entreprise tant sur le plan économique que stratégique.

20 2.3 BEA Weblogic FIG. 2.4 Architecture n-tiers BEA permet d organiser le tiers du milieu en cluster. Cela est une fonctionnalité à part entier de WebLogic. En effet, le fait d organiser le tiers du milieu en cluster est totalement transparent pour l utilisateur final. De plus, cela permet d équilibrer la charge de chacun des serveurs et augmente la sécurité et la continuité de service. Si une requêtes, quelques qu elle soit (EJB, Servlet) est en erreur car le serveur de destination n est pas atteignable ou est en panne, alors un autre serveur WebLogic du cluster prendra la relève et permettra de répondre au client. Composants «BackEnd» Le «Backend» contient tous des services qui sont atteignable uniquement via le serveur WebLogic. WebLogic protège les applications «Backend» notamment les bases de données en proposant par exemple le principe de pool de connexion. De ce fait, les connexions aux différentes bases de données de l entreprise sont gérées directement depuis le serveur. Cela permet de détecter les connexions inactives, de les libérer afin de les attribués à d autre demandeur. Il n y a pas que les bases de données qui font partie du «Backend». Les ERP, dans le cas de mon travail SAP.

21 2.3 BEA Weblogic Structuration des couches applicatives Couche «Présentation» La couche présentation inclue la logique applicative et le moyen de l afficher à l écran via une interface utilisateur. La plupart des applications J2EE utilisent un navigateur web sur la machine cliente. Il est évident d en déduire les raisons. En effet, cela est plus facile que de devoir déployer un programme complet sur une multitude de poste dans une entreprise. Dans ce cas, en utilisant un navigateur web, la logique de présentation est dévolue au serveur Weblogic qui va la préparer, la mettre en forme et ensuite l envoyer au client qui se chargera de l afficher. 1. Les clients du type navigateur web : Les applications basées sur le web sont facile a maintenir du fait de leur centralisation et portable. Dans ce type de client, l interface utilisateur est généralement du type HTML, couplé dans mon cas avec des pages JSP reposant sur des Servlet. Les pages JSP sont faciles à écrire, car elles contiennent une grande partie de code HTML. Néanmoins, elles peuvent contenir du code Java sous forme de scriplet. Il est important de noter que les pages JSP sont compilées et convertie en Servlet avant d être exécuté et envoyé au client. 2. Les autres clients : Les clients qui ne font pas partie des navigateurs web ont leur propre logique de présentation incluse dans le code. Ils ont besoin du serveur BEA uniquement dans le but d utiliser la couche «Business» et pour avoir accès aux services «Backend», dans le cas bien sur ou le serveur Weblogic est l unique point d entré pour avoir accès aux autres services d entreprise (Base de données, ERP). Ces clients peuvent être écrits en Java en utilisant l API Swing, qui permet de gérer l interface graphique. Afin que ces clients puissent avoir accès aux différents services du «Backend» et de la couche «Business» ils doivent implanter les connexions au serveur via RMI 3 / CORBA 4 ou SOAP 5 3. Les clients de web services : Les clients qui invoquent des Web services contenu dans WebLogic peuvent être écrit dans n importe quel langage. Il doit toutefois respecter certaines règles d appel du Web services. En effet il doit pouvoir créer un message SOAP qui décrit le Web service qu il veut atteindre et inclure dans le corps du message toutes les données qu il veut lui transmettre. Un envoi est effectué via HTTP / HTTPS. Le serveur traite la demande et renvoi une réponse sous forme de message SOAP. Couche «Business» Pour les applications J2EE, les Enterprise JavaBeans sont les briques qui composent la couche «Busines». Le serveur WebLogic contient un conteneur pour les 3 Remote Method Invocation 4 Common Object Request Broker 5 Simple Object Access Protocol