Ré-architecture et migration d'une application...

Ré-architecture et migration d’une applicationstandalone 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 gestionLaboratoire de technologies objet

Hautes Ecoles Specialisées de Suisse Occidentale HES-SOHaute Ecole de Gestion de Genève

25 novembre 2005

Table des matières

1 Architecture 41.1 Comprendre les architectures multi-tiers . . . . . . . . . . . . . . . . 4

1.1.1 Les trois niveaux d’abstraction d’une application . . . . . . . 41.1.2 Architecture n-tiers ou architecture distribuée . . . . . . . . . 51.1.3 Le tier Client . . . . . . . . . . . . . . . . . . . . . . . . . . 51.1.4 Le tiers Web . . . . . . . . . . . . . . . . . . . . . . . . . . 61.1.5 Le « Middleware » ou Tiers du milieu . . . . . . . . . . . . . 8

1.2 Architectures multi-tiers dans un contexte Java . . . . . . . . . . . . 81.3 Architecture globale actuelle de l’application . . . . . . . . . . . . . 10

1.3.1 Coté client . . . . . . . . . . . . . . . . . . . . . . . . . . . 101.3.2 Coté serveur, gestion de la persistance . . . . . . . . . . . . . 10

1.4 Gestion de la persistance dans l’environnement cible . . . . . . . . . 10

2 Technologies applicative cible spécialisée 122.1 JCo - Java connector for SAP . . . . . . . . . . . . . . . . . . . . . . 12

2.1.1 Remote Function Call (RFC) . . . . . . . . . . . . . . . . . . 122.1.2 RFC Library . . . . . . . . . . . . . . . . . . . . . . . . . . 132.1.3 Appel de fonctions Java depuis SAP R/3 . . . . . . . . . . . . 142.1.4 Architecture Jco . . . . . . . . . . . . . . . . . . . . . . . . 14

2.2 WebServices ABAP sur serveur SAP WAS 6.4 . . . . . . . . . . . . . 152.2.1 Principe de fonctionnement . . . . . . . . . . . . . . . . . . 15

2.3 BEA Weblogic 8.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.3.1 Plate-forme J2EE . . . . . . . . . . . . . . . . . . . . . . . . 152.3.2 Architecture du serveur d’application Weblogic . . . . . . . . 162.3.3 Composant logiciel d’une architecture multi-tiers . . . . . . . 162.3.4 Structuration des couches applicatives . . . . . . . . . . . . . 182.3.5 Accès au données . . . . . . . . . . . . . . . . . . . . . . . . 19

2.4 Struts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202.4.1 Qu’est ce que Struts ? . . . . . . . . . . . . . . . . . . . . . . 202.4.2 Viabilité de Struts sur le plan architectural . . . . . . . . . . . 222.4.3 Liaison de Struts à J2EE ? . . . . . . . . . . . . . . . . . . . 23

TABLE DES MATIÈRES ii

3 Passage d’un système objet a un système n-tiers 243.1 La modélisation, facteur de réussite ? . . . . . . . . . . . . . . . . . . 24

3.1.1 Pourquoi modéliser . . . . . . . . . . . . . . . . . . . . . . . 243.1.2 Que modéliser ? . . . . . . . . . . . . . . . . . . . . . . . . . 253.1.3 Les niveaux d’abstraction, jusqu’ou aller ? . . . . . . . . . . . 26

3.2 Difficultés inhérentes à une modélisation web . . . . . . . . . . . . . 273.2.1 Comment modéliser les flux . . . . . . . . . . . . . . . . . . 273.2.2 Les machines d’états pour représenter et modéliser les pages . 28

3.3 Travailler avec les couches, division de l’application . . . . . . . . . . 283.3.1 Le couplage des couches, vrai ou faux problème ? . . . . . . . 283.3.2 Les couches aplicatives, à chacune sa résponsabilité . . . . . 293.3.3 Les « Design Pattern » pour découpler les couches . . . . . . 30

3.4 Architecture de l’application . . . . . . . . . . . . . . . . . . . . . . 33

4 Démarche de transformation 354.1 Analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

4.1.1 Examens des modèles existants . . . . . . . . . . . . . . . . 354.1.2 Compréhension et intégration dans l’architecture cible . . . . 364.1.3 Quels modèles utiliser ? . . . . . . . . . . . . . . . . . . . . 364.1.4 Design et architecture . . . . . . . . . . . . . . . . . . . . . 37

4.2 Etude de faisabilité . . . . . . . . . . . . . . . . . . . . . . . . . . . 384.2.1 Enjeu de cette réarchitecture . . . . . . . . . . . . . . . . . . 384.2.2 Environnement de développement BEA . . . . . . . . . . . . 384.2.3 Contraintes architecturales . . . . . . . . . . . . . . . . . . . 394.2.4 Contraintes au niveau de l’IHM . . . . . . . . . . . . . . . . 394.2.5 Contraintes liées à l’utilisation des Web services . . . . . . . 404.2.6 Respect de la séparation des couches applicatives . . . . . . . 41

4.3 Conception et tests . . . . . . . . . . . . . . . . . . . . . . . . . . . 424.3.1 Tenir compte des modèles . . . . . . . . . . . . . . . . . . . 424.3.2 Comment tester une application Web . . . . . . . . . . . . . 42

Conclusion 44

Bibliographie 46

Glossaire 47

Annexes 48.1 Diagramme d’états-transition . . . . . . . . . . . . . . . . . . . . . . 48.2 Diagramme de classe . . . . . . . . . . . . . . . . . . . . . . . . . . 49.3 Diagramme des packages . . . . . . . . . . . . . . . . . . . . . . . . 50

Table des figures

1.1 Architecture - Tiers client . . . . . . . . . . . . . . . . . . . . . . . . 51.2 Architecture - Tiers web . . . . . . . . . . . . . . . . . . . . . . . . 61.3 Architecture - Détails du tiers web . . . . . . . . . . . . . . . . . . . 71.4 Architecture - Partie « Middleware » . . . . . . . . . . . . . . . . . . 8

2.1 Scénario d’utilisation et de création d’une RFC . . . . . . . . . . . . 132.2 Architecture du JCO . . . . . . . . . . . . . . . . . . . . . . . . . . 142.3 Intégration BEA - SAP . . . . . . . . . . . . . . . . . . . . . . . . . 152.4 Architecture n-tiers . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.5 Architecture de Struts . . . . . . . . . . . . . . . . . . . . . . . . . . 212.6 Exemple d’une Action avec annotations . . . . . . . . . . . . . . . . 22

3.1 Analyse opérationnelle . . . . . . . . . . . . . . . . . . . . . . . . . 253.2 Architecture déorganisée à base de composants . . . . . . . . . . . . 293.3 Architecture « Delegate » . . . . . . . . . . . . . . . . . . . . . . . . 313.4 Architecture « Facade » . . . . . . . . . . . . . . . . . . . . . . . . . 323.5 Architecture « DAO » . . . . . . . . . . . . . . . . . . . . . . . . . . 333.6 Architecture finale . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

Avant-propos

Je tiens tout particulièrement à remercier l’entreprise Rolex SA qui m’a permit deré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’apportertoute l’aide sur la façon de mener a bien mon travail.

Je souhaite remercier également M. Dominique Fazi, responsable du départe-ment développement, qui a bien voulu m’accorder sa confiance en me permettant defaire parti de son équipe.

Mes remerciements vous aussi à M. Damien Mimoun, consultant chez SerialDéveloppement, qui m’a aider sur le plan technique concernant l’environnementRolex sans quoi, mon travail aurait été grandement ralenti.

Je souhaite également remercier M. Qin Pang, pour son aide, et M. BombengerJean pour sa joie et sa bonne humeur qu’il nous a apportée régulièrement au cours dece mémoire.

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 detechnologies 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’uneapplication mets en jeu différents système, il est difficile d’avoir une vue globale dece qui doit être fait par nos soin ou non.

Le cadre de ce mémoire est la réarchitecture et la migration d’une applicationstandalone développé en Java. L’hôte de la future application est un serveur Weblogic8. Contrairement à la première application, la gestion de la persistance ne va pas sefaire 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 lacomplexité des modèles, mais la multitude d’environnements qui entre en jeu qui fontde cette réarchitecture un problème très intéressant à traiter.

Je vais donc m’attarder sur l’études des environnements multi-tiers ainsi quesur 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 technologiesqui vont être mise en oeuvre lors de la phase de développement de l’application versle système cible. Etant données que les modèles vont jouer un grand rôle dans laconception, je vais proposer une solution quand à la modélisation des pages Web, etproposer ma démarche de réarchitecture.

Chapitre 1

Architecture

1.1 Comprendre les architectures multi-tiers

1.1.1 Les trois niveaux d’abstraction d’une applicationD’une manière générale, une application peut être découpée en trois niveaux d’abs-

traction 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. Cettecouche gère la souris, les saisies clavier. Elle doit être le plus ergonomique pos-sible.

– La logique applicative, les traitements décrivant les travaux à réaliser par l’ap-plication. Ils peuvent être découpés en deux familles :– Les traitements locaux, regroupant les contrôles effectués au niveau du dia-

logue 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’ap-plication.

– Les données, ou plus exactement l’accès aux données, regroupant l’ensembledes mécanismes permettant la gestion des informations stockées par l’applica-tion.

Ces trois niveaux peuvent être imbriqués ou repartis de différentes manières entre plu-sieurs machines physiques. Le noyau de l’application est composé de la logique deprésentation et de la logique des traitements. Le découpage et la répartition de ce noyaupermettent de distinguer des architectures applicatives qui vont de l’architecture 1-tiersà l’architecture n-tiers.

1.1 Comprendre les architectures multi-tiers 5

1.1.2 Architecture n-tiers ou architecture distribuéeL’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 dis-tribution 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éar-chitecture applicative. Cependant, celle-ci est facilitée par l’utilisation de composantsmétier spécialisés et indépendants, introduits par les concepts orientés objets. Elle per-met de tirer pleinement partie de la notion de composants métier réutilisables. Cescomposants 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 communiquerentre eux et peuvent donc coopérer en étant implantés sur des machines physiquesdistinctes.

1.1.3 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 outild’administration. L’outil d’administration peut être qualifié dans ce cas, de client de labase de donnée.


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 ebXML1.

1.1.4 Le tiers Web

FIG. 1.2 – Architecture - Tiers web

Le tiers web est essentiel au fonctionnement futur de l’application qui va subirla ré-architecture. Il en est en quelque sorte le coeur. En effet, ses attributions et sesresponsabilité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érerlui-même. Pour effectuer certaine tâches, il doit en déléguer la responsabilité à une ouplusieurs entités applicatives qui pourront traiter la demande, et lui renvoyer le résultat.

1Elect. Business Exchange Specification


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 toutesces responsabilités. C’est pourquoi, des extensions serveurs peuvent lui êtres ajoutéesafin de combler ses lacunes. Il existe différentes possibilités d’étendre les fonctionspremiè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, ilpourra déléguer les requêtes qui lui sont attribuées aux extensions appropriées.

1.2 Architectures multi-tiers dans un contexte Java 8

1.1.5 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 icimiddleware, littéralement « élément du milieu », l’ensemble des couches réseau et ser-vices logiciel qui permettent le dialogue entre les différents composants d’une applica-tion répartie. Ce dialogue se base sur un protocole applicatif commun, défini par l’APIdu middleware. Le Gartner Group définit le middleware comme une interface de com-munication universelle entre processus. Il représente véritablement la clef de voûte detoute application client-serveur. L’objectif principal du middleware est d’unifier, pourles applications, l’accès et la manipulation de l’ensemble des services disponibles surle 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 logicielmis à disposition pour d’autres applications. Le middleware offre des services auxcomposants, tel que le moyen de connexion à un SGBD (persistance), la gestion destransactions ainsi que l’authentification.

1.2 Architectures multi-tiers dans un contexte JavaDans le cadre de cette étude, le middleware est contenu dans un serveur BEA We-

blogic 8.1. Toutefois, ce serveur ne joue pas seulement le rôle d’un middleware. Eneffet, 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 quel’environnement d’exécution dans lequel les applications sont déployées. Ceci permet

1.2 Architectures multi-tiers dans un contexte Java 9

aux développeurs d’application de ne pas avoir a reprogrammer les services d’infra-structure.

Le serveur J2EE fournit aux applications un ensemble de services comme lesconnexions aux bases de données, la messagerie, les transactions... L’architectureJ2EE 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 stan-dard que chaque plate-forme J2EE doit prendre en charge :

– JNDI : JNDI est une extension JAVA standard qui fournit une API uniformepermettant d’accéder à divers services de noms et de répertoires. Derrière unnom 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 surles concepts d’utilisateur, de domaines et de groupes.

– JDBC : Java Database Connectivity est une API qui permet aux programmesJava 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 estde fournir une trame générale pour l’implémentation de paradigmes " requête-réponse ". Ils remplacent les scripts CGI tout en apportant des performances biensupérieures.

– JSP : La technologie JSP (JavaServer Pages) est une extension de la notion deservlet permettant de simplifier la génération de pages web dynamiques. Elle sesert de balises semblables au XML ainsi que de scriplets Java afin d’incorporerla logique de fabrication directement dans le code HTML. JSP est un concurentdirect de l’ASP et du PHP.

– JMS : Java Messaging Service est à la fois une ossature et une API permettantaux développeurs de construire des applications professionnelles qui se serventde messages pour transmettre des données.

– JTA : La spécification JTA (Java Transaction API) définit des interfaces stan-dards entre un gestionnaire de transactions et les éléments impliqués dans celles-ci : L’application, le gestionnaire de ressources et le serveur.

– EJB : Chaque instance d’un EJB se construit dans conteneur EJB, un environ-nement d’exécution fournissant des services (Sécurité, Communications, Cyclede vie...). Un client n’accède JAMAIS directement à un composant. Il doit pourcela passer par une l’appel à une « Factory méthode » qui va lui retourner uneréférence vers une instance de l’EJB concerné. L’interface locale décrit le cycled’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 cecomposant présente au monde extérieur.

1.3 Architecture globale actuelle de l’application 10

1.3 Architecture globale actuelle de l’applicationL’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érationou client-serveur de données, le poste client se contente de déléguer la gestion des don-nées à un service spécialisé. Ce type d’application permet de tirer partie de la puissancedes ordinateurs déployés en réseau pour fournir à l’utilisateur une interface riche, touten garantissant la cohérence des données, qui restent gérées de façon centralisée.

1.3.1 Coté clientLe 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’unecommunication entre les deux parties. Comme vu précédemment, cette communicationest é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éeen tenant compte des techniques de Génie logiciel. Aucune couche applicative ressortclairement. Néanmoins, une séparation a été faite du point de vue logique en ce quiconcerne 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 sys-tème.

3. Un package « common » qui regroupe les différentes classes communes auxdeux applications, notamment l’accès aux données.

1.3.2 Coté serveur, gestion de la persistanceLa 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 derequête qui est SQL.

1.4 Gestion de la persistance dans l’environnementcible

La gestion future de la persistance va être tout autre. En effet, cette gestion vatoujours se faire sur la base d’un serveur Oracle, mais sa gestion, tant au niveau destransaction, des exceptions et des contrôles d’erreurs va être dévolue au système SAP.

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 modifica-tions 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 stan-dards à 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 entrele Web Application Server de SAP et SAP R/3.

Un fichier WSDL2 par Web service est requis pour décrire les fonctions que celui-ci mets à notre disposition.

2Web Services definition langage

Chapitre 2

Technologies applicative ciblespécialisée

2.1 JCo - Java connector for SAPSAP 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èmeSAP. Cette API est bidirectionnelle. Elle supporte une communication du monde Javavers SAP et du monde SAP vers Java. De ce fait, grâce a une grande interaction entreces deux système, cela permets une interopérabilité accru.

JCO est essentiel entre le moteur J2EE de SAP et le serveur d’application deSAP. Il agit en tant que Java-Wrapper pour avoir accès au librairie RFC.

2.1.1 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’appelerdes fonctions prédéfinis situées sur un système distant. Ces même RFC encapsule toutle processus de communication, les paramètres de transfert de l’information aussi quela 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éespour connecter des requêtes J2EE au monde ABAP.

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.1

4. Le « Gateway » renvoie l’appel vers le moteur RFC.

5. Le moteur RFC cherche dans le JNDI un EJB correspondant a la fonction de-mandé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.

2.1.2 RFC LibraryLes 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 unsystème SAP depuis une application externe. De plus, les librairies RFC permettentde concevoir des programmes RFC qui serons stocker sur le serveur SAP. Ces pro-grammes personnalisés seront accessible a partir de n’importe quelle serveur SAP R/3ou une application externe.

1Attention, la fonction doit être definie dans l’annuaire avant l’appel.

2.1 JCo - Java connector for SAP 14

2.1.3 Appel de fonctions Java depuis SAP R/3Dans 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 dedéfinir l’adresse TCP/IP de déstination. De ce fait, du coté applicatif Java, lorsqueSAP appelera une fonction Java, celle-ci sera du type

– handleRequest(JCO.Function function).

2.1.4 Architecture JcoLa 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 composantJ2EE et ABAP.

2.2 WebServices ABAP sur serveur SAP WAS 6.4 15

2.2 WebServices ABAP sur serveur SAP WAS 6.4

2.2.1 Principe de fonctionnementABAP 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 laréarchitecture de l’application et comme nous l’avons vu précédemment, la gestion dela 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 setrouve sur le serveur R/3. Tout ces Web services sont codés en ABAP. Comment doncfaire la liaison entre le serveur BEA, l’hôte de l’application et SAP ? Le principe estsimple. 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 WASqui lui sert d’intermédiaire. Pour cela, SAP fournit les définitions de ces Web servicessous forme de WSDL.

FIG. 2.3 – Intégration BEA - SAP

2.3 BEA Weblogic 8.1

2.3.1 Plate-forme J2EELe serveur Weblogic 8.1 implantante la technologie Java 2, Enterprise Edition

(J2EE) version 1.32. J2EE est la plate-forme standard pour le développement d’ap-plication multi-tiers basé sur le langage Java. La technologie J2EE à été conjointementdéveloppé par Sun Microsystems ainsi que d’autre Entreprise, entre autre, BEA Sys-tems, le concepteur de Weblogic.Les applications J2EE sont basées sur des composants modulaires standardisés. Le ser-veur WebLogic fournit un jeu de services complets pour gérer, maintenir et développerces composants.

2http : //java.sun.com/j2ee/sdk_1.3/index.html

2.3 BEA Weblogic 8.1 16

2.3.2 Architecture du serveur d’application WeblogicWebLogic 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 enoeuvre le principe de cache d’objets et de pool de connections afin d’augmenter ladisponibilités des ressources ainsi que les performances.

Le serveur Weblogic opère dans le tiers milieu d’une une architecture n-tiers. Unearchitecture n-tiers détermine ou les composants logiciels doivent être exécutés entenant compte des autres composants, du hardware, du réseau et des utilisateurs. Lefait de choisir le meilleur emplacement pour un composant permet de développer desapplications plus rapidement et de contrôler les performances, la sécurité, la faisabilitéet l’évolutivité.

2.3.3 Composant logiciel d’une architecture multi-tiersLes 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 lan-gage.

– Le tiers intermédiaire ou middle tiers contient le serveur WebLogic ou tout autreserveur qui est sollicité par les clients, comme des serveurs Web ou des proxy.

– Le tiers « Bachend » contient les ressources d’entreprises comme les bases dedonnées et par exemple les ERP tel que SAP.

Composants client

Les clients du serveur utilisent les interfaces standard pour accéder au serveur We-bLogic étant donné que ce serveur est un serveur Web a part entière. De ce fait, unnavigateur 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’emploide JSP et de servlets, cela permet d’avoir des pages personnalisées en fonction desactions 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 égalementavoir accès aux composant du serveur, aux EJB par exemple qui se trouvent dans lacouche « 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 desperformances 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’entreprisetant sur le plan économique que stratégique.


FIG. 2.4 – Architecture n-tiers

BEA permet d’organiser le tiers du milieu en cluster. Cela est une fonctionna-lité à part entier de WebLogic. En effet, le fait d’organiser le tiers du milieu en clusterest totalement transparent pour l’utilisateur final. De plus, cela permet d’équilibrerla 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 dedestination n’est pas atteignable ou est en panne, alors un autre serveur WebLogic ducluster prendra la relève et permettra de répondre au client.

Composants « BackEnd »

Le « Backend » contient tous des services qui sont atteignable uniquement viale serveur WebLogic. WebLogic protège les applications « Backend » notamment lesbases de données en proposant par exemple le principe de pool de connexion. Dece fait, les connexions aux différentes bases de données de l’entreprise sont géréesdirectement depuis le serveur. Cela permet de détecter les connexions inactives, de leslibérer afin de les attribués à d’autre demandeur. Il n’y a pas que les bases de donnéesqui font partie du « Backend ». Les ERP, dans le cas de mon travail SAP.


2.3.4 Structuration des couches applicativesCouche « 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 na-vigateur 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 multitudede poste dans une entreprise. Dans ce cas, en utilisant un navigateur web, la logique deprésentation est dévolue au serveur Weblogic qui va la préparer, la mettre en forme etensuite l’envoyer au client qui se chargera de l’afficher.

1. Les clients du type navigateur web : Les applications basées sur le web sontfacile 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 avecdes pages JSP reposant sur des Servlet.Les pages JSP sont faciles à écrire, car elles contiennent une grande partie decode HTML. Néanmoins, elles peuvent contenir du code Java sous forme descriplet. Il est important de noter que les pages JSP sont compilées et convertieen Servlet avant d’être exécuté et envoyé au client.

2. Les autres clients : Les clients qui ne font pas partie des navigateurs web ontleur propre logique de présentation incluse dans le code. Ils ont besoin du serveurBEA uniquement dans le but d’utiliser la couche « Business » et pour avoiraccès aux services « Backend », dans le cas bien sur ou le serveur Weblogic estl’unique point d’entré pour avoir accès aux autres services d’entreprise (Base dedonné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 avoiraccès aux différents services du « Backend » et de la couche « Business » ilsdoivent implanter les connexions au serveur via RMI3 / CORBA4 ou SOAP5

3. Les clients de web services : Les clients qui invoquent des Web services contenudans WebLogic peuvent être écrit dans n’importe quel langage. Il doit toutefoisrespecter certaines règles d’appel du Web services. En effet il doit pouvoir créerun message SOAP qui décrit le Web service qu’il veut atteindre et inclure dansle corps du message toutes les données qu’il veut lui transmettre. Un envoi esteffectué via HTTP / HTTPS. Le serveur traite la demande et renvoi une réponsesous forme de message SOAP.

Couche « Business »

Pour les applications J2EE, les Enterprise JavaBeans sont les briques qui com-posent la couche « Busines ». Le serveur WebLogic contient un conteneur pour les

3Remote Method Invocation4Common Object Request Broker5Simple Object Access Protocol


EJB avec des services de « caching », de persistance et de gestion des transactions. Onpeut distinguer trois types de JavaBeans :

1. Les « Entity Beans » : Un « Entity Bean » représente un objet contenu dansun serveur J2EE. Il contient des données, ainsi que des méthodes qui permettentd’avoir accès à ces données. Celle-ci peuvent être stockées ou non dans une basede donnée en utilisant l’API JDBC. Ces « Entity Beans » peuvent participer ades transactions qui elles-mêmes mettent en jeux des « Entity Beans ». Les «Entity Beans » sont souvent les intermédiaires entre le monde relationnel, lesbases de données et le monde objet. Ce sont les « Entity Beans » qui font cemapping entre ces deux mondes. Pour retrouver l’information, ces « Beans »peuvent employer deux méthodes :– Le code qui permet d’accéder, de sauvegarder et de retrouver l’information se

trouve dans le « Bean ».– Le container EJB se charge de faire ce travail au nom du « Bean ».Les « Entity Beans » peuvent être partagé par un nombre illimité de clients.

2. Les « Session Beans » : Contrairement aux « Entity Beans », les « SessionBeans » ne sont pas permanent. En fait, leur durée de vie dépends de la duréede vie de la session utilisateur du client qui utilise se « Beans ». Il n’implémenteplus des données, mais de la logique procédurale. Les « Session Beans » peuventêtre orienté connexion ou non.

3. Les « Message-Driven Beans » : Les « Message-Driven Beans » ont été in-troduit avec la spécification 2.0 des EJB. Cette sorte d’EJB n’est pas directe-ment accessible par un client. Néanmoins, une application peut instancier un «Message-Driven Bean » en envoyant un message de type JMS au serveur BEAqui lui retournera un pointer vers cet EJB.

Couche « Application »

Le serveur BEA fournit des services fondamentaux aux composants. Ceux-cipeuvent donc se concentrer sur leur logique « Business » sans se préoccuper descouches supérieures. Ces services sont par exemples la gestion des transmissions ré-seau, l’authentification, la gestion de la persistance grâce aux pools de connexion,l’accès à des objets distants pour les EJB et les servlets.

2.3.5 Accès au donnéesPrincipe de pool de connexion

BEA fournit en interne, un système de gestion des connexions vers diverses basesde donnée. Quels intérêts y a-t-il d’utiliser ce système plutôt que de créer une simpleconnexion JDBC dans notre code et de l’utiliser ?

Le fait est que dans un environnement qui est très sollicité, tant au niveau du

2.4 Struts 20

serveur J2EE que du point de vue des bases de données, la saturation du système,surtout celui du SGBD peut être atteinte très rapidement. Cela dépends du nombred’applications qui sont en production. Dans une configuration qui n’utilise pas lespool de connexion BEA pour ce connecter a une base de donnée, chaque applicationva ouvrir sa propre route (connexion) vers la base de donnée désirée. Si la connexionn’est pas fermée lorsque l’application n’est plus utilisée, alors il va y avoir unemultiplication des connexions inutilisée. Du coté du serveur de base de donnée, lalimite des ouvertures de connexion va être atteinte et là, c’est le drame !

BEA propose de gérer ces connexions à notre place. Avant toute chose, nousdevrons configurer une connexion. Un nom va lui être attribué et elle va être ajoutédans un annuaire. Lorsque, dans notre code, nous voudrons utiliser cette connexion,un simple appel du nom de la connexion dans l’annuaire BEA via JNDI va nousretourner une instance de la connexion. En effet, le serveur va gérer automatiquementla connexion et surtout la déconnexion à la base. Dès que la connexion n’est plusutilisée, il va libérer les ressources. De ce fait, un autre application va pouvoir a sontour l’utiliser. C’est le principe du « Pool de connexion ».

2.4 Struts

2.4.1 Qu’est ce que Struts ?Struts est un framework open source basé sur le design pattern MVC (Model -

Vue - Contrôleur). Le but principal de MVC est de séparer la partie présentation de lalogique métier, au niveau de la programmation.

2.4 Struts 21

FIG. 2.5 – Architecture de Struts

Comme le montre le schéma ci-dessus, la partie présentation est clairementséparée de la logique métier qui se trouve dans le contrôleur. La partie présentation estessentiellement constituée de code HTML et de Javascrippt. Toutefois, les tags utilisésavant que le serveur ne construise la page sont plus sophistiqués que de simples tagsHTML. En effet, le contrôleur est présents afin de rediriger ou de répondre a certainerequête en provenance du client. Cependant, nous avons la possibilité d’invoquerdirectement des méthodes se trouvant dans le contrôleur depuis une page JSP/HTML.

Pour utiliser ces fonctionnalités, des tags spécialisés sont utilisés afin d’invo-quer les méthodes du contrôleur et de les lier à des pseudos variable situées dans lecode de la page. De ce fait, le résultat de l’appel peut être utilisé dans la page.Le grand intérêt de Struts est de pouvoir utiliser des Actions. Une action est uneméthode particulière situé dans le contrôleur. Elle utilise les annotations Java.

Le couplage des annotations et de l’utilisation des Actions du contrôleur est d’unepuissance redoutable. Il y a une plus grande interaction entre la partie présentation et lecontrôleur. Cela permet entre autre de pouvoir faire des redirections en tenant comptede la dynamique d’exécution de l’application. L’utilisation du framwork « Struts »dans la conception d’un système d’information permet de

– Remforcer la modularité et le partitionnement de l’application.– Augmenter la séparation des fonctionnalitées de l’application.– Augmenter la maintenabilité du code.– Augmenter la facilité d’entendre l’application avec d’autre fonctionnalités.

2.4 Struts 22

FIG. 2.6 – Exemple d’une Action avec annotations

Pour cela, « Struts » implemente plusieurs design pattern6 dont certain sont la combi-naison d’autre.

– Service to worker.– Dispatcher view.– Front controller.– View helper.– Synchronize token.

2.4.2 Viabilité de Struts sur le plan architecturalL’architecture et même le coeur de Struts repose principalement sur les servlets.

Comme nous l’avons mentionné plus haut, le principal atout de Struts est l’utilisationd’Actions. Ces Actions permettent d’adapter la couche présentation à la logiquemétier. De ce fait, l’adoption de Struts dans un projet d’envergure peut être d’une aidenon négligeable.

Un autre point de taille est aussi à prendre en considération. BEA, le leadermondial du serveur d’application J2EE a intégré le framework dans sont environne-ment de développement, a savoir BEA workshop 8.1.

Pour allez plus en profondeur avec Struts, il faut savoir qu’Apache fournit uneversion standard de Struts qui peut être complété selon les besoins. Selon le typede développement, il est possible d’ajouter des extensions au noyau de Struts, parexemple le projet Apache Beehive. Cette extension permet entre autre, l’utilisationd’annotations dans le code Java. Elle fournit aussi de nouveaux tags, qui sont utilesau niveau de la couche présentation. Ces tags permettent une plus grande interactionentre le contrôleur et les pages JSP. Ces tags, dont la librairie est NetUI autorisent desdéveloppements rapides et sont d’une efficacité étonnante.

6Les termes Anglais ont été concervé pour plus de compréhension

2.4 Struts 23

Nous pouvons dire que Struts est bien avancé au niveau de sa conception. Ceframework repose sur des concepts éprouvés et sont adoption ne fera qu’augmenterla performance et la maintenance des applications J2EE. Toutefois, Struts n’estpas à la porté de tout le monde. Il reste néanmoins un framework qui nécessite unapprentissage avancé pour être maîtrisé et utilisé au mieux.

2.4.3 Liaison de Struts à J2EE ?Struts ne fourni pas de services spécifiques afin de s’interconnecter avec d’autres

technologies de type J2EE. Cependant, Struts est basé sur le concept de JSP et deServlets. De ce fait, Struts hérite de l’environnement de ces standards et peut interagiravec n’importe quelles JSP ou Servlets.

Les tags HTML et les tags propres à Struts peuvent cohabiter ensemble et Struts peutinteragir avec ces deux catégories de tags.Struts recommande d’utiliser les FormBean pour remplir des formulaires et pourpasser des donner entre différentes Actions. Cependant si un développeur souhaite nepas utiliser les Beans pour transférer ces donner entre les actions et les formulaires, ilpeut toujours utiliser la méthode traditionnelle a savoir request.getParameter() pouraccéder aux donner.Cela est une caractéristique très importante de Struts ! En effet, si le framework estdéployé dans un environnement de production, il y a toujours la possibilité d’utiliserla technologie de base des composants JSP/Servlets. De ce fait, cela réduit le risqued’adopter le framework Struts.

Chapitre 3

Passage d’un système objet a unsystème n-tiers

3.1 La modélisation, facteur de réussite ?

3.1.1 Pourquoi modéliserC’est une très bonne question. Il est vrai qu’il est plus facile de premier abord,

pour un développeur de se mettre immédiatement à l’ouvrage et de coder directementdès qu’il a reçu l’aval de son supérieur sur un projet.

Il peut être compréhensible de penser que le fait de construire un modèle d’uneapplication peut nous faire perdre du temps. Nous avons tous à un moment donné,été confrontés à la lecture d’un modèle UML ou Merise que nous n’avons pas conçu.D’un premier coup d’oeil, nous avons pensé que le modèle était faux ou erroné, oùalors, que l’application n’implantais pas le modèle. Pourquoi ? Avant tout, définissonsla notion de modèle. Ce qu’il est réellement, à quoi il peut bien servir et quels servicesil peut nous rendre dans une phase d’étude et de développement ou bien dans unephase de réarchitecture d’une application.

Qu’est qu’un modèle ?

Depuis de longues années, la modélisation n’a cessé d’accroître son importancedans des domaines tel que l’informatique, les mathématiques, la biologie et biend’autres encore. Dans tous les cas, la modélisation a pour but de réduire la complexitéd’un problème donné. De ce fait, la modélisation réduit la réalité d’un problème àcertains paramètres afin d’en étudier le comportement. Après quoi, cette modélisationpermet de valider ou non la réalité afin de permettre de faire des simulations.En raison de la multiplicité et de la différence des objectifs que pose le problème de lamodélisation, il n’est pas facile de définir clairement ce que peut être un modèle. Celadépend avant tout du contexte et de la finalité de celui-ci.

3.1 La modélisation, facteur de réussite ? 25

Avant tout, un modèle est une réalisation picturale faites avec une syntaxe etdes formes géométriques précises qui met en équation ce que l’on a compris d’unproblème.

3.1.2 Que modéliser ?La modélisation métier

Avant toute tentative de construction, que se soit dans le domaine informatique oudans le domaine du bâtiment, la phrase clé est :

Savoir quoi faire avant de savoir comment le faire

La modélisation métier permet de comprendre réellement le fonctionnement d’undépartement d’une entreprise, du mode de travail d’un employé ou de l’enchaînementdes actions à effectuer en vue de concevoir, dans notre cas, une application quipermettra de prendre en charge tout ou une partie de l’existant.

La modélisation métier nous permet de représenter les deux parties de la pro-blématique de la conception des systèmes d’information :

– L’expression des besoins, formalisés grâce aux « use cases ».– La définition du domaine et des objets métier.

Trop nombreux sont ceux qui se lancent dans la conception à proprement dit sans enavoir compris l’essence même. A ce titre, il n’est pas rare de s’entendre dire que la réa-lisation informatique demandée fonctionne très bien, mais que le besoin réel n’est pascomblé. En d’autres termes, l’application fonctionne parfaitement mais n’est d’aucuneutilité pour les utilisateurs finaux.Lors de la conception d’un nouveau système, il ne faut pas oublier une étape fonda-

FIG. 3.1 – Analyse opérationnelle

mentale, a savoir l’analyse opérationnelle afin d’éviter de mauvaises surprises.

3.1 La modélisation, facteur de réussite ? 26

La modélisation système

Une fois la modélisation métier effectué, nous avons alors une vue d’ensembledu problème à traiter. Cela va nous permettre d’élaborer la dynamique de la futurapplication grâce à différents modèles que sont :

– Le diagramme de classes.– Le diagramme de séquence.– Les machines d’états.

Là aussi, de nombreux développeurs ne s’engagent pas dans une telle modélisation.Pour certain, le formalisme UML ne leur est guère familier et pour d’autres, ce sontles responsables informatiques qui ne connaissent pas ou peu les procédures et leslangages de modélisation. Néanmoins, la modélisation système est un élément cléde la réussite d’un projet informatique. En effet, cela permet une grande traçabilitéet permet de se repérer dans les méandres d’une application qui peut devenir trèscomplexe surtout dans le cas d’un développement J2EE.

Retenons donc que les modèles, qu’ils soient métier ou système représentent laclé de voûte d’une conception et d’une implémentation réussie. Prenons donc le tempsde réfléchir et de conceptualiser ce que nous avons en tête afin de concevoir d’unemanière efficace la future architecture de n’importe quelle système d’information.

3.1.3 Les niveaux d’abstraction, jusqu’ou aller ?Lorsqu’on traite des problèmes complexes, il est difficile d’avoir une vue globale

et conceptuellement impossible de les appréhender d’un premier coup d’oeil. De ma-nière générale, un problème peut se résumer à un ensemble de problèmes de plus petitetaille. Le découpage d’un système en sous-systèmes peut ne pas être facile. Néan-moins, l’analyse de ses sous-systèmes en profondeur va permettre de comprendre unebonne partie du problème de base. Ce type de raisonnement est à la base même desniveaux d’abstraction que l’on peut rencontrer lorsque l’on utilise la méthode Merise :

– Niveau conceptuel.– Niveau logique.– Niveau physique.

Lorsque l’on utilise la méthode RUP (Rational Unified Process), on rencontre les ni-veaux d’abstraction suivants :

– Niveau fonctionel.– Niveau analyse.– Niveau conception.

Il faut donc bien comprendre la signification de ces niveaux ainsi que le faite quel’enrichissement d’un modèle de niveau N se fait par l’analyse du niveau N+1. Il est à

3.2 Difficultés inhérentes à une modélisation web 27

noter que les modèles peuvent être discutable du point de vue de l’exactitude vis-à-visdu monde réel. Il est normal qu’un modèle d’analyse ne dise pas tout.

Etant donné que le modèle n’est qu’une vision de la réalité d’une personne, enl’occurrence celui de l’analyste, le développeur qui va s’appuyer sur ce modèle pourconstruire l’application peut rester sur sa fain.

Une modélisation UML comprend différents schémas tel que le diagramme declasse et le diagramme de séquence. Le niveau d’abstraction que ces schémas auront dupoint de vue de l’analyse va dépendre grandement de la compréhension du problèmepar l’analyste.

En règle générale, une modélisation trop précise et trop détaillée ne sert à rien.Le fait de vouloir montrer impérativement tous les enchaînements ainsi que tous lesmessages que peut envoyer ou recevoir un modèle est inutile. Au contraire, cela vamasquer l’essentiel et peut-être induire le développeur en erreur.

3.2 Difficultés inhérentes à une modélisation web

3.2.1 Comment modéliser les fluxLors de la conception d’une application Web, la modélisation des flux entre les

pages et les interactions entre celle-ci est très difficile. Il est tout aussi difficile de créerun diagramme de classe qu’un diagramme de séquence. Pourquoi est-ce si difficile ?

Il est vrai que le développement d’une application web en Java ou en .Net estplus facile à modéliser qu’une application en PHP ou autre. Certes, les couchesmétiers et d’accès aux données nous posent moins de problèmes. En effet, dans cescouches nous modélisons des classes et des comportements qu’UML nous permetde décrire. Néanmoins, toutes nous posent le problème dès la conception de savoircomment décrire dans un formalisme compréhensible par tous, UML par exemple,les interactions entre les pages dynamiques générées automatiquement ou non par leserveur d’applications.

La couche présentation, que représentent les pages JSP doivent être modéliséesafin d’avoir une vue globale de l’application. Il n’est pas pratique de modéliser cespages en utilisant la signalétique des classes et en plus, ce serait un abus de langage,car ces pages ne sont pas des classes au sens propre du terme.Pour généraliser, nous pouvons dire que ces pages sont des aiguillages vers desactions. Ces actions, après avoir récupéré ou non les informations que les utilisateursont pu entrer, redirigent ou construisent de nouvelles pages qui a leur tour pourrontrendre compte et diffuser de l’information directement à l’utilisateur. Peu a peu, nousvoyons émerger dans ce schéma le principe des machines d’états. Voyons commentles machines d’états peuvent nous aider à modéliser les flux d’une application web.

3.3 Travailler avec les couches, division de l’application 28

3.2.2 Les machines d’états pour représenter et modéliser les pagesNous appelons diagramme d’états une représentation graphique associée à une ma-

chine d’états. Les diagrammes d’états sont utilisés pour modéliser le comportementdes objets, c’est-à-dire que, pour chaque type d’objet, chaque classe, on peut définirune machine d’états correspondante. Nous venons de dire plus haut qu’il ne serait pasconvenable d’associer une page JSP à une classe. Lorsque nous parlons de diagrammed’états, nous associons celui-ci à la modélisation du comportement des objets. N’est-cepas paradoxal ?

En fait, il nous faut savoir que la rigueur d’UML n’est pas forcement de mise dansla modélisation des flux. Tout ce que l’on a besoin de savoir, c’est l’enchaînement desactions qu’une page nous propose avec son éventuel résultat. De ce fait, le diagrammed’états est recommandé dans notre cas.

L’utilisation des diagrammes d’états sont particulièrement efficace dans le cas d’undéveloppement avec le framework Struts. Celui-ci mets en oeuvre le principe d’actionset de redirection en fonctions d’un état ou d’un comportement.

3.3 Travailler avec les couches, division de l’applica-tion

3.3.1 Le couplage des couches, vrai ou faux problème ?Le développement d’application J2EE est complexe. Toutefois, il est très facile

de commencer à développer une application Web basée sur J2EE en partant sur demauvaises bases. Là encore, il nous faut savoir où l’on veut aller. La rigueur est demise.

Dans une architecture multi-tier, les composant business peuvent et sont souventrepartis en différents endroits sur un serveur. Etant donnée que l’insertion de codesJava ou « scriplets » est possible dans une page de type JSP, il est possible de faireappel à des composants depuis cette même page. L’architecture ressemblera alors àla figure suivante : Dans cette manière de développer, un problème va rapidement seposer. Il se peut très bien que cette architecture soit stable durant un certain temps. Ilse peut même qu’au fil du temps, des fonctionnalités viennent se rajouter à celles debase !Supposons maintenant que le composant « Accès aux données » serve à établir uneconnexion à une base de donnée Oracle. Supposons également que le composant «Accès aux LDAP » serve à établir une connexion à un annuaire NOVEL. Lors d’unchangement d’architecture de l’un de ces deux systèmes, l’application cessera de fonc-tionner, et c’est toute l’application, c’est-à-dire toutes les pages qui intègrent ces appelsqu’il faudra modifier ! Impensable !Cet exemple nous montre l’importance qu’il y à a concevoir dès le début une archi-tecture structurée. Le couplage des couches applicatives est donc un réel problème. Ce


FIG. 3.2 – Architecture déorganisée à base de composants

problème peut être évité si les règles de conception logicielle sont respectées.

3.3.2 Les couches aplicatives, à chacune sa résponsabilitéDans le cadre de notre réarchitecture, l’application va être découpé en cinq couches

distinctes avec chacune une responsabilité qui lui est propre. Avant d’énoncer les res-ponsabilités de chacune des couches, citons-les dans l’ordre, de la plus haute à la plusbasse :

1. Présentation.

2. Application.

3. Services.

4. Modèle.

5. Persistance.

La couche « Présentation » est responsable de l’affichage des données provenant duserveur d’application. C’est ce que l’on appelle l’interface homme machine ou IHM.

La couche « Application » va contenir et implémenter la logique et la dynamiquedes Use cases. C’est elle aussi qui va se charger de la validation des règles de gestionafin que les données transmises aux couches inférieures soient correctes. Cette couchemet en oeuvre le pattern « Delegate ».

La couche « Services » va encapsuler les processus métier ainsi que la gestion destransactions. Cette couche met en oeuvre le pattern « Facade ».

La couche « Model » va contenir tous les éléments, c’est-à-dire le diagramme declasse avec ou non l’implémentation de certains patterns. C’est en effet le coeur del’application.


La couche « Persistance » encapsule tous les mécanismes d’accès aux données.C’est elle qui est responsable de retrouver l’information et de la faire remonter jus-qu’aux éléments du modèle afin qu’elle puisse être exploitable par l’application. Cettecouche implémente le pattern « DAO ».

3.3.3 Les « Design Pattern » pour découpler les couchesPattern « Delegate »

Dans un contexte multi-tier, le système distribué a besoin d’invoquer des méthodesqui se trouvent parfois sur différentes machines. De ce fait, les clients sont exposés à lacomplexité des appels à ces méthodes et cela crée un fort couplage entre l’applicationet l’architecture sous-jacente.

En effet, le problème est que les composants qui font partie du tier présentationdoivent interagir avec les services « Business ». Il en résulte une grande vulnérabilitédes composants du tier présentation si des changements de conception, voire mêmedes changements d’implémentation au niveau du code surviennent. Si l’implémen-tation de la partie business change, alors l’implémentation de la partie présentationdevra également être modifié.

Voila donc les besoins qu’il nous faut combler afin d’avoir une architecture pé-renne :

– Le tier présentation de la partie client doit pouvoir avoir accès à des composantsbusiness.

– Il faut minimiser le couplage entre ces couches.

La solution envisagée est de mettre en place le pattern « Delegate » au sein del’architecture de l’application. En effet, celui-ci va permettre de réduire le couplageentre le tier présentation et les composants « Business ». Ce Design pattern masquel’implémentation du composant. Il fournit un service à la partie appelante. Celapermet de pouvoir faire des changements d’implantation dans tous les composantsbusiness sans devoir toucher à l’implémentation des couches directement supérieures.

L’intérêt de ce pattern est aussi de capter toutes les exceptions pourraient seproduire dans les couches inférieures.

Quand ce pattern est utilisé avec le pattern Session Facade, il y a une relation1-1 entre les deux. Ce rapport 1-1 existe parce que la logique applicative qui pourraitavoir été encapsulée dans un « Business Delegate » concernant son interaction avecde multiples services sera souvent factorisée de nouveau dans une « Session Facade »,ce que nous allons voir par la suite.


FIG. 3.3 – Architecture « Delegate »

Pattern « Facade »

Le design Pattern Facade est sans doute le plus utilisé des Pattern J2EE. Cepattern porte bien son nom. Le but est de créer un mur entre le client, et le reste del’application. En effet, les composant business exposent leurs interfaces au mondeentier. Ce « monde entier » est, entre autres, le serveur d’application et tout autreserveur qui participe a la logique business de l’entreprise.

Ici aussi, la question du couplage entre les couches se pose. Il serait tout à faitpossible de déposer où on en a besoin, toutes sorte de composants. Cependant,l’interaction directe du client avec des composants auxquels il ne devrait pas avoiraccès occasionnent parfois des surcharges au niveau du serveur d’application, dutrafic réseau important et peut ralentir l’exécution de l’application et congestionner lespoints d’entrée du serveur !

Quand il y a une exposition des objets « Business » au client, celui-ci doitcomprendre et être responsable des relations qu’il pourrait y avoir entre ces différentsobjets. Or, ce n’est pas son rôle. La mise en place d’une architecture de ce type seraitune grave erreur de conception.

Le but du pattern « Facade » est donc de mettre à disposition de l’applicationau moyen d’interfaces, les méthodes dont elle a réellement besoin afin que son flotd’exécution se déroule correctement.


FIG. 3.4 – Architecture « Facade »

Pattern « DAO »

Les accès aux données varient selon la source des données. Cette source peut êtreune base de relationnelle ou objet, ou bien un ERP comme SAP.Dans une application d’entreprise de type J2EE, à un moment donné, la gestion dela persistance et la persistance en elle-même est obligatoire et nécessaire. Pour cesapplications, les mécanismes d’accès aux sources de données sont implémentés dedifférentes manières. Certaines applications peuvent nécessiter l’accès à des donnéesqui se trouvent sur des systèmes distants, citons par exemple l’accès à un annuaireLDAP, SAP ou encore des bases Oracle.

Afin d’accéder à ces sources de données, les applications J2EE doivent utiliserl’API JDBC. Cette API fournit des méthodes standard d’accès et de manipulationdes données. Toutefois, bien que ces API soient standards, il se peut que la façond’y accéder, notamment au niveau de la syntaxe, soit différente en fonction du typede base de donnée avec laquelle on veut communiquer. Par exemple, la manière decommuniquer est différente entre une base de donnée Oracle et MySQL ou encoreSQL Serveur. En ce qui concerne SAP, une application ne peut pas directementinterroger la base qui se trouve derrière. C’est le système SAP qui s’en charge. Lamanière d’y accéder est encore différente des autres.

Les différences au niveau de l’interrogation SQL entre les bases de données dumarché ainsi que les pilotes propriétaires qui sont utilisés peuvent introduire unfort niveau de dépendance entre l’application et l’interface de persistance. Cesdépendances peuvent être la cause de problèmes futurs dans le cas d’un changementSGBD. En effet, quand les sources de données changent, les composants d’accès à cesdonnées doivent être modifiés eux aussi !

De ce problème, ressortent quatre points importants pour lesquels nous devonstrouver une solution.

– Les servlets, les pages JSP, le pageFlow peuvent a tout moment avoir besoind’accéder à une source de donnée.

– Les API de gestion de bases de données ainsi que leurs possibilités varient selonle constructeur (Oracle, IBM, Microsoft).

3.4 Architecture de l’application 33

– La portabilité de l’application est grandement affectée lorsque des API proprié-taires sont utilisés.

– Les composants d’accès aux données doivent être transparents du point de vuede l’application.

La solution est l’implantation du Pattern DAO au niveau de la couche d’accès auxdonnées de l’application.

FIG. 3.5 – Architecture « DAO »

3.4 Architecture de l’applicationNous pouvons maintenant proposer une architecture viable et structurée qui dé-

couple les couches applicalives et optimise le flot d’exécution. La figure suivante nousmontre l’architecture d’une partie de l’application avec la mise en oeuvre des patternmentionnés plus haut.

3.4 Architecture de l’application 34

FIG. 3.6 – Architecture finale

Chapitre 4

Démarche de transformation

4.1 Analyse

4.1.1 Examens des modèles existantsLa base de départ de cette réarchitecture est évidemment les modèles de concep-

tion de l’application d’origine. Celle-ci a été conçue à partir d’un besoin. Dans laphase d’analyse et après avoir évalué les besoins futurs, il s’est avéré que ces besoinsont pris une orientation différente que ceux de départ.

De toute évidence, un delta est apparu entre les besoins identifiés de l’applica-tion future et celle actuellement utilisée. C’est pourquoi, l’analyse des modèlesexistants de l’application a fait ressortir que la migration de l’application ne pourraitse faire sans la modification profonde du modèle objet. Qu’est ce qui explique cela ?

L’utilisation et la conception d’une application standalone diffèrent de l’utilisa-tion et de la création d’une application Web, même si celles-ci sont construitesdans le même langage de programmation. Les facilités d’utilisation de la premièredeviennent les contraintes de la deuxième. Dans le premier cas, nous avons affaireà une application client d’une base de donnée. Cette même application est un clientriche. Dans le second cas, à savoir l’application migrée sur le serveur BEA, nousavons affaire à une application qui doit pouvoir simuler un client riche, être connectéea un ERP, à savoir SAP. De plus l’interaction entre le client et le serveur s’appuie surle protocole HTTP qui n’est pas orienté connexion. De ce fait, nous avons à gérer leproblème de la persistance des données au niveau de la session utilisateur.

Voilà ce qui a pu ressortir de la phase d’analyse. Pour pouvoir migrer de façonefficace cette application, une réflexion a dû être entreprise sur la manière de résoudreces problèmes.

La suite de ce chapitre va exposer comment ces problèmes ont pu être maîtrisés

4.1 Analyse 36

et comment l’application à été conçue afin de pouvoir répondre au besoin qui à étéexprimé.

4.1.2 Compréhension et intégration dans l’architecture ciblePour bien situer le problème, il faut comprendre que, une fois migrée, cette

application va être déployée au sein d’un portail au sens BEA.

Un portail est un ensemble d’applications ayant accès à des ressources com-munes. Le fait d’intégrer l’application au sein de ce portail va faciliter grandementle développement de certaines de ses parties. En effet, le concept de « portlet », quiest une entité autonome, une sorte de brique dont le développeur dispose, permet laréutilisation de code et de logique applicative. Par exemple, certains utilisateurs ontbesoin de s’authentifier pour pouvoir avoir accès à certaines applications. Typique-ment, la partie authentification va être dévolue à une « portlet » spécialisée. Un simpleglisser/déposer va nous permettre d’utiliser cette brique dans l’application.

Un autre point essentiel qu’il nous faut aborder dans cette partie est le fait qu’uncertain design, au sens graphique du terme, doit être respecté. Le fait de respecter unlay-out particulier va influencer la manière d’intégrer l’application au sein du portail.En effet, certains comportements, ou alors certains effets visuels ne sont pas autorisés.Comprenons bien que ce n’est pas le serveur BEA qui nous refuse cette liberté maisplutôt la chartre graphique de l’entreprise ainsi que les règles communément définiespar les responsables du développement.

La connaissance des différentes règles qu’il faut appliquer afin que l’applicationrespecte les standards de l’entreprise va permettre de concevoir des modèles quirespectent ces contraintes.

4.1.3 Quels modèles utiliser ?Cette question se pose souvent. En effet, UML proposes différents modèles qui

permettent de comprendre un problème donné, vu sous des angles différents. Voyonsles différents modèles que propose UML :

1. Diagramme d’activitéLe diagramme d’activité n’est autre que la transcription dans UML de la re-présentation du processus tel qu’il a été élaboré lors du travail qui a préparé lamodélisation. Il montre l’enchaînement des activités qui concourrent au proces-sus.

2. Diagramme de cas d’utilisationLe diagramme de cas d’utilisation décrit la succession des opérations réaliséespar un acteur (entité qui interagit avec le système). C’est le diagramme principal

4.1 Analyse 37

du modèle UML, celui où s’assure la relation entre l’utilisateur et les objets quele système met en oeuvre.

3. Diagramme de classesLe diagramme de classe représente l’architecture conceptuelle du système : ildécrit les classes que le système utilise, ainsi que leurs associations, que ceux-cireprésentent un emboîtage conceptuel (héritage, marqué par une flèche terminéepar un triangle) ou une relation organique (agrégation, marquée par une flècheterminée par un diamant).

4. Diagramme de séquencesLe diagramme de séquence représente la succession chronologique des opéra-tions réalisées par un acteur : saisir une donnée, consulter une donnée, lancerun traitement ; il indique les objets que l’acteur va manipuler, et les opérationsqui font passer d’un objet à l’autre. On peut représenter les mêmes opérationspar un diagramme de collaboration, graphe dont les noeuds sont des objets et lesarcs (numérotés selon la chronologie) les interactions entre objets : diagrammede séquence et diagramme de collaboration sont deux vues différentes, mais lo-giquement équivalentes (on peut construire l’une automatiquement à partir del’autre), d’une même chronologie.

5. Diagramme d’étatsLe diagramme d’état représente la façon dont évoluent ("cycle de vie") durantle processus les objets appartenant à une même classe. La modélisation ducycle de vie est essentielle pour représenter et mettre en forme la dynamique dusystème.

L’utilisation de ces différents modèles dépend de ce que l’on veut montrer. En effet,nous pouvons utiliser ces modèles tant du point de vue d’une modélisation métier quesystème.

Dans le cas de cette réarchitecture, l’accent a été mis principalement sur la mo-délisation système et moins sur la modélisation métier. C’est pourquoi, les modèlessuivants ont été utilisés :

1. Diagramme de cas d’utilisation

2. Diagramme de classes

3. Diagramme d’états

4.1.4 Design et architectureLe design et l’architecture ont été réalisés avec le logiciel de conception UNL

Borland Together. La modélisation de l’application n’a pas été la partie la plus ardue.En effet, celle-ci est composée principalement du diagramme d’état qui nous permetd’avoir une vue globale de flux ainsi que du diagramme de classe.

4.2 Etude de faisabilité 38

La partie architecture est importante dans le cas du portage de l’application. Etantdonné la multiplicité des Web services utilisé, celle-ci a permi de vraiment partitionnerl’application en couches afin de respecter les différents patterns et de contrôler lesaccès aux ressources.

4.2 Etude de faisabilité

4.2.1 Enjeu de cette réarchitectureJusqu’à maintenant dns l’entreprise, aucune application n’a été développée avec

l’IDE BEA Workshop 8.1 ni avec le concept de « Page flow ». La raison en estsimple, puisque la version de BEA était la 7. Un des buts de ce développement estde faire de cette application un modèle tant sur le plan architectural que conceptuel.Cette application sera un bon exemple car différentes technologies entrent en jeu,l’utilisation des Web services par exemple.

Comme nous allons le voir par la suite, l’utilisation des Web services au seinde la version 8 du Workshop est assez délicate à mettre en oeuvre du point de vuearchitectural. En effet, l’architecture nous impose la mise en oeuvre de différentescouches en utilisant des design patterns afin de séparer les différentes logiquesapplicative, ce que nous avons mentionné haut.

4.2.2 Environnement de développement BEAL’environnement de développement intégré de BEA fonctionne de la même

manière que tous les IDE du marché, qu’ils soient Open source (Eclipse) ou non(JBuilder).

Cependant, nous n’avons jamais eu à développer réellement des applicationsd’entreprise dans ce contexte. Bien que nous connaissons l’environnement BEA, il ya une différence fondamentale entre connaître un produit et utiliser les fonctionnalitésqu’il nous met à disposition. Il nous a donc été nécessaire de prendre en maincomplètement le produit afin d’être opérationnel une semaine après avoir débuté sonapprentissage.

Avec le nombre impressionnant de fonctionnalité et de possibilités qu’offre cetIDE, nous avons appris les principale fonctionnalité du logiciel en faisant l’impassesur d’autres. Comme nous allons le voir plus bas, des choix architecturaux importantsont du être fait en ce qui concerne la méthode d’implantation des Web services. Eneffet, le Workshop propose l’utilisation de composant tel que les « Java control » oudes « custom control » qui permettent d’encapsuler des appels a des Web service oua des bases de données. Lorsque ces contrôle sont crées, nous avons la possibilité


d’incorporer dans notre « Page Flow » ces briques afin de les instancier et de les utiliser.

Le fait de proceder ainsi pose de gros problèmes si on décide de mettre enoeuvre une architecture particulière afin de respecter certain standards, typiquementceux de l’entreprise.

4.2.3 Contraintes architecturalesLors de la phase de l’étude de faisabilité, l’intégration des Web services dans

l’architecture a pris une part importante. En effet, il y a eu une collaboration étroiteentre l’équipe de développement SAP et l’équipe de développement Java. Commementionné précédemment, en ce qui concerne la gestion de la persistance, celle-cidoit se faire au niveau du DAO. Cela permet d’avoir une plus grande liberté en casde changement de la base de donnée ou tout autre système. Etant donné que dansnotre cas, la gestion de la persistance a été gérée dans SAP, des Web services ont duêtre crées à cette fin. Au total, nous avons du gérer sept Web services, deux écritsspécifiquement pour l’application et cinq standards au système SAP.

Le défit a été d’orchestrer tout ces appels et de produire une architecture viable,évolutive et maintenable. Pour cela, une batterie de tests nous a été fournie afin devérifier que les Web services répondaient bien à ce pourquoi ils ont été conçus. Cestests nous ont été fort utiles. En effet, ils ont pu mettre en lumière des incohérencesainsi que différents problèmes causés par la dynamique d’exécution du programme.Etant donné qu’il y a un Web Application Server (WAS) entre le serveur BEA et SAP,il a fallu établir des connexions entre ces systèmes afin que les Web services puissentcommuniquer. Ne négligeons donc pas les tests d’intégration, car ils peuvent mettreen lumière des problèmes insoupçonnés.

4.2.4 Contraintes au niveau de l’IHMLà encore, des difficultés ont surgi. L’application de départ était un client lourd.

L’interface était entièrement construite en Java. De ce fait, il y avait une grandepossibilité d’interaction entre l’utilisateur et le système. Cela est loin d’être le cas lorsde l’utilisation d’un client Web.

Pour résoudre ce problème, nous avons dû introduire énormément de JavaScriptdans le code HTML des pages JSP. En effet, étant donné que le code JavaScripts’exécute du coté client, cela nous a permi de simuler des opérations qui d’habitude seretrouvent plus généralement sur des clients lourds.

Dans la conception d’une application Web qui est destiné à l’Internet, nousavons à faire face à des clients sur lesquels peuvent s’exécuter différentes versions denavigateur. Il y a aussi le problème non seulement des différences de version entre


les navigateurs mais aussi les différents navigateurs eux-mêmes. Citons par exempleNetscape ou Internet explorer. Plus récemment Mozilla et bien d’autres encore. Cesnavigateurs incorporent leur propre moteur de traduction des scripts Java. De ce fait,nous pouvons observer à des comportements différents entre ces plateformes.

Heureusement pour nous et pour l’entreprise, une standardisation a été faite surle type de navigateur qui est utilisé sur toutes les machines du parc informatique.Cela permet d’avoir le contrôle sur comportement des scripts Java incorporés dans lespages HTML.

4.2.5 Contraintes liées à l’utilisation des Web servicesPour l’utilisation et la création de Web services dans l’environnement BEA 8.1,

nous avons le choix des armes. En effet BEA propose deux outils qui vont nous per-mettre de construire les classes d’appel vers ces Web services. Ces outils sont puis-sant mais diffèrent grandement en ce qui concerne leur utilisation dans le Workshop.Voyons quels sont ces outils.

Génération automatique depuis l’IDE BEA

Dans l’environnement de développement de BEA, nous avons la possibilité decréer des « Java control ». Ces « Java control » peuvent encapsuler des appels àdes bases de données, des clients mail, des EJB ou encore de gérer la mécaniqued’appel a des Web services. Ce dont nous avons besoin, est la localisation sous formed’une URL du fichier WSDL qui contient la définition du Web services ainsi qu’unlogin et un mot de passe pour la connexion. Une fois ces données renseignés, BEAva automatiquement, sur la base du fichier de définition, générer les classes d’appel(RMI) qui vont permettre la connexion.

Le gros inconvénient de cette méthode, c’est que BEA ne fournit pas les fi-chiers sources. De ce fait, nous n’avons pas la possibilité de modifier le code. Un autreinconvénient majeur, est que BEA n’autorise pas l’instanciation du Web service audehors du « Page Flow ». Cela pose un problème d’architecture, car dans ce cas, lacouche DAO n’est plus du tout indépendante de la gestion de la persistance. Dans unearchitecture normalement constituée, c’est dans le DAO que cette instanciation auraitdû se faire. Un élément de réponse à ce problème est que BEA utilise les annotationsJava 1.5 pour gérer ces « Java control » dévolus à la gestion des Web services. Dece fait, il faudrait insérer des annotations Java dans le code du DAO afin que celui-cipuisse pouvoir gérer de façon efficace le Web services qui lui sont attribués.


Génération automatique avec « clientgen »

Un autre moyen de générer la mécanique d’accès aux Web services est d’utiliserl’utilitaire fourni par BEA qui est « clientgen ». Cet utilitaire se base sur des scripts« Ant » pour générer les classes d’appel. Un exemple de fichier « Ant » utilisé dansl’application est fourni en annexe. Contrairement à la méthode interne de BEA, cetutilitaire est plus souple et il permet de conserver les sources générés afin de lesmodifier si besoin. Un autre point intéressant est que cet utilitaire nous permet decréer des packages au sens Java. C’est une bonne approche, car cela va nous permettrede créer des package spécifiques pour chaque Web service.

Toutefois, un problème s’est glissé dans un des rouages de cet utilitaire. En ef-fet, celui-ci a été pleinement testé avec la version 7 du Workshop. Avec la version 8,des comportements erronés ont pu être constatés. Lors de la sérialisation des élémentsà envoyer, il s’est avéré que les classes générées soulevaient une exception qui faisait« crasher » l’application. Après un examen approfondi du problème, nous avonsdécouvert qu’il y avait un problème de mapping entre les différentes classes. Problèmequi ne se manifeste pas lors d’une utilisation séparée des ces packages.

Ce problème est fâcheux car il invalide tout le fonctionnement de l’application,la rendant parfaitement inutilisable. A cause de cela, tant que ce problème n’est pascomplètement résolu, nous devons utiliser la mécanique interne de BEA pour générerles Web services.

4.2.6 Respect de la séparation des couches applicativesComme nous venons de le voir ci-dessus, l’utilisation de « clientgen » pose pro-

blème. Mais d’un autre coté, c’est cette méthode que nous devons utiliser. Pourquoi ?La raison en est très simple. L’utilisation de la méthode interne de BEA génère un fortcouplage entre les différentes couches de l’application, ce qui n’est pas le cas de «clientgen ».

L’utilisation de la solution BEA nous contraint d’instancier le Web servicesdans le « Page Flow » qui n’est autre le contrôleur Java au sens UML. D’où laquestion : comment rendre disponible l’instance créée dans le « Page Flow » au niveaudu DAO ? La réponse est simple, mais complètement absurde sur le plan architectural.Il suffit de faire transiter l’instance dans toutes les couches de l’application, à savoirde la « Façade » au « Delegate » puis du « Delegate » au « DAO ». Vous serezd’accord avec moi d’admettre que cette façon de faire est ridicule car l’utilisation deces patterns a pour but de découpler les couches applicatives afin de rendre l’appli-cation évolutive et maintenable. Or, c’est tout le contraire qui ce passe ici. Au lieude rendre le couplage le plus faible possible, nous l’avons augmenté au plus haut point.

4.3 Conception et tests 42

Il nous faudra trouver une solution le plus rapidement possible afin de résoudrece problème.

4.3 Conception et tests

4.3.1 Tenir compte des modèlesLors de la conception, si nous n’utilisons pas la génération automatique de code,

il serait fâcheux de ne pas tenir compte des modèles de conception que nous avonscréés au cours de l’analyse. En effet, nous avons bâti cette application en partantd’un besoin. Le besoin nous a conduit à l’élaboration de modèles pertinents qui nousont permis d’obtenir une abstraction de la réalité. Cette abstraction de la réalité estnécessaire et inévitable. Si nous ne respectons pas les lignes directrices que sontles modèles, nous allons partir dans la conception d’une application qui n’est pasconforme à la réalité que nous avons modélisée.

Selon différentes études1 qui ont été menées depuis l’avènement de la concep-tion de logiciels, la majorité des applications qui ne sont pas utilisées le sont à causedu fait qu’elles ne répondent pas du tout au besoin qui a été exprimé. Quoi de plustriste que de savoir que notre application n’est pas utilisée simplement car nousn’avons pas répondu aux besoins des utilisateurs ?

Soyons donc prompt à utiliser les modèles que nous avons conçu à partir d’unréel besoin afin que les applications qui en résulteront puissent correspondre auxattentes des utilisateurs.

4.3.2 Comment tester une application WebLes tests ont une part importante dans l’achèvement de la partie conception d’une

application. Afin que l’application puisse répondre à un standard de qualité, celle-civa être déployée successivement dans trois environnements. En effet, à la fin de laconception, l’application va être déployée dans un environnement de développementpuis, dans un environnement dit de qualité puis, à la fin du processus, dans l’environ-nement de production.

Ces trois étapes successives permettent de tester l’application dans sa globalité etde déceler des bugs ou des incohérences vis-à-vis des besoins exprimés pendant laphase d’analyse.

Hormis ces trois environnements, le test d’une application web n’est pas une choseaisée. Etant donné qu’une application se construit avec des briques ou composants lo-giciels, le plus sûr est d’effectuer des tests unitaires sur ces composants fin de s’assurer

1http : //www.standishgroup.com/sample_research/chaos_1994_1.php


de leurs fiabilité. Après quoi des tests globaux peuvent être effectués par un utilisateurafin d’avoir un oeil neuf sur le programme.

Conclusion

La démarche de création d’un logiciel du début jusqu’à la fin est passionnante. Lesdifférentes technologies qui existent aujourd’hui renforcent cette idée. Afin que lesproduits que nous créons soient fiables, robuste et de qualité, nous devons respectercertaines règles.

Pour un pilote d’avion, il ne lui viendrait pas à l’idée de se poser ou il le veut,même s’il le peut physiquement. Dans le domaine informatique, bien souvent, nousavons la possibilité d’entreprendre des constructions logicielles très rapidement avecdes outils aussi performants que sont XDE de Rational ou bien WinDev et encoreBEA Weblogic WorkShop. Cependant, comme nous l’avons vu au cours de cetteétude, les technologies sur lesquelles nous travaillons sont complexes et puissantes.Mal maîtrisée ou mal pensée, elles peuvent vite devenir incontrôlable du point vude la maintenance ou alors du point de vu de la modification d’une ou plusieursfonctionnalités.

L’utilisation de modèles cohérant peut nous aider grandement. Prendre du temps audébut de chaque phase de conception nous épargnera bien des difficultés a nous mêmeou alors a la personne qui reprendra notre travail. Dans un projet de grande envergureou non, il peut être facile de se perdre, surtout si nous avons a prendre en chargeplusieurs projets en même temps.

Nous nous sommes plus particulièrement intéressé à la conception d’applica-tions Web. Nous avons mis en évidence la problématique de la modélisation des flux.Grâce aux diagrammes d’états transition, nous avons pu voir une approche simple etpertinente afin de construire un squelette précis de notre application.

Comme dans tous développement, des contraintes du a l’environnement ou auxutilisateurs sont inévitable. Dans ce cas, notre force va résider dans la manière de lescontourner et de les surmonter tout en respectant les besoins des utilisateurs.


De cette étude, retenons donc :

1. L’importance qu’il y de concevoir des models exploitable.

2. L’utilisation de « Design patterns afin d’implémenter des comportements com-plexes ».

3. De tenir compte de la limite des technologies mises en oeuvre ainsi que de leurscomplexités.

En respectant ces trois règles de bases qui sont, de surcroît, simple a mettre en oeuvre,nous pourront concevoir des applications fiables, pérennes et maintenable. Nous au-rons fait correctement notre métier d’informaticien.

Bibliographie

[1] Chuck Cavaness. Programming Jakarta Struts. O’REILLY, 18 rue Séguier 75006PARIS, first edition, 2002.

[2] Chip Dawes. Oracle 10g Administration I. SYBEX, première edition, 2005.

[3] Ralph Johnson John Vlissides Eric Gamma, Richard Helm. Design Paterns, Ele-ments of Reusable Object-Oriented Software. Addison Wesley Longman, Inc,1994.

[4] Chuk Musciano et Bill Kennedy. HTML, The Definitive Guide. O’REILLY, thirdedition, 1998.

[5] Jason Hunter et William Crawford. Servlet Java, Guide du programmeur.O’REILLY, 18 rue Séguier 75006 PARIS, deuxième edition, 2002.

[6] Daniel Flanagan. JavaScript, The Definitive Guide. O’REILLY, third edition,1998.

[7] Bertand Meyer. Object-Oriented, Software Construction. PRENTICE HALL,second edition, 1997.

Glossaire

– JCo : Java Connector for SAP– RFC : Remote Function Call– IHM : Interface Homme-Machine– HTTP : Hyper Text Transfert Protocol– XML : Extensible Markup Language– CORBA : Common Object Request Broker Architecture– RMI : Java Remote Method Invocation– SOAP : Simple Object Access Protocol– WSDL : Web Services Description Language– ebXML : Electronic Business using eXtensible Markup Language– EIS : Enterprise Information System– CGI : Common Gateway Interface– ASP : Active Server Pages– JSP : Java Server Pages– JNDI : Java Naming and Directory Interface– LDAP : Lightweight Directory Access Protocol– API : Application Programming Interface– DNS : Domain Name System– NIS : Network Information Service– JMS : Java Message Service– JTA : Java Transaction API– EJB : Enterprise JavaBeans– JDBC : Java Database Connectivity– SQL : Structured Query Language– WAS : Web Application Server for SAP– ERP : Enterprise resource planning– UML : Unified Modeling Language

Annexes

.1 Diagramme d’états-transition

.2 Diagramme de classe 49

.2 Diagramme de classe

.3 Diagramme des packages 50

.3 Diagramme des packages

Ré-architecture et migration d'une application...

Documents

Transcript of Ré-architecture et migration d'une application...