Ré-architecture et migration d`une application standalone vers un

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
Table des matières
1
2
Architecture
1.1 Comprendre les architectures multi-tiers . . . . . . . . .
1.1.1 Les trois niveaux d’abstraction d’une application
1.1.2 Architecture n-tiers ou architecture distribuée . .
1.1.3 Le tier Client . . . . . . . . . . . . . . . . . . .
1.1.4 Le tiers Web . . . . . . . . . . . . . . . . . . .
1.1.5 Le « Middleware » ou Tiers du milieu . . . . . .
1.2 Architectures multi-tiers dans un contexte Java . . . . .
1.3 Architecture globale actuelle de l’application . . . . . .
1.3.1 Coté client . . . . . . . . . . . . . . . . . . . .
1.3.2 Coté serveur, gestion de la persistance . . . . . .
1.4 Gestion de la persistance dans l’environnement cible . .
Technologies applicative cible spécialisée
2.1 JCo - Java connector for SAP . . . . . . . . . . . . . . .
2.1.1 Remote Function Call (RFC) . . . . . . . . . . .
2.1.2 RFC Library . . . . . . . . . . . . . . . . . . .
2.1.3 Appel de fonctions Java depuis SAP R/3 . . . . .
2.1.4 Architecture Jco . . . . . . . . . . . . . . . . .
2.2 WebServices ABAP sur serveur SAP WAS 6.4 . . . . . .
2.2.1 Principe de fonctionnement . . . . . . . . . . .
2.3 BEA Weblogic 8.1 . . . . . . . . . . . . . . . . . . . .
2.3.1 Plate-forme J2EE . . . . . . . . . . . . . . . . .
2.3.2 Architecture du serveur d’application Weblogic .
2.3.3 Composant logiciel d’une architecture multi-tiers
2.3.4 Structuration des couches applicatives . . . . . .
2.3.5 Accès au données . . . . . . . . . . . . . . . . .
2.4 Struts . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.4.1 Qu’est ce que Struts ? . . . . . . . . . . . . . . .
2.4.2 Viabilité de Struts sur le plan architectural . . . .
2.4.3 Liaison de Struts à J2EE ? . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
4
4
4
5
5
6
8
8
10
10
10
10
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
12
12
12
13
14
14
15
15
15
15
16
16
18
19
20
20
22
23
TABLE DES MATIÈRES
3
4
ii
Passage d’un système objet a un système n-tiers
3.1 La modélisation, facteur de réussite ? . . . . . . . . . . . . . . . . .
3.1.1 Pourquoi modéliser . . . . . . . . . . . . . . . . . . . . . .
3.1.2 Que modéliser ? . . . . . . . . . . . . . . . . . . . . . . . .
3.1.3 Les niveaux d’abstraction, jusqu’ou aller ? . . . . . . . . . .
3.2 Difficultés inhérentes à une modélisation web . . . . . . . . . . . .
3.2.1 Comment modéliser les flux . . . . . . . . . . . . . . . . .
3.2.2 Les machines d’états pour représenter et modéliser les pages
3.3 Travailler avec les couches, division de l’application . . . . . . . . .
3.3.1 Le couplage des couches, vrai ou faux problème ? . . . . . .
3.3.2 Les couches aplicatives, à chacune sa résponsabilité . . . .
3.3.3 Les « Design Pattern » pour découpler les couches . . . . .
3.4 Architecture de l’application . . . . . . . . . . . . . . . . . . . . .
Démarche de transformation
4.1 Analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.1.1 Examens des modèles existants . . . . . . . . . . . .
4.1.2 Compréhension et intégration dans l’architecture cible
4.1.3 Quels modèles utiliser ? . . . . . . . . . . . . . . . .
4.1.4 Design et architecture . . . . . . . . . . . . . . . . .
4.2 Etude de faisabilité . . . . . . . . . . . . . . . . . . . . . . .
4.2.1 Enjeu de cette réarchitecture . . . . . . . . . . . . . .
4.2.2 Environnement de développement BEA . . . . . . . .
4.2.3 Contraintes architecturales . . . . . . . . . . . . . . .
4.2.4 Contraintes au niveau de l’IHM . . . . . . . . . . . .
4.2.5 Contraintes liées à l’utilisation des Web services . . .
4.2.6 Respect de la séparation des couches applicatives . . .
4.3 Conception et tests . . . . . . . . . . . . . . . . . . . . . . .
4.3.1 Tenir compte des modèles . . . . . . . . . . . . . . .
4.3.2 Comment tester une application Web . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
24
24
24
25
26
27
27
28
28
28
29
30
33
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
35
35
35
36
36
37
38
38
38
39
39
40
41
42
42
42
Conclusion
44
Bibliographie
46
Glossaire
47
Annexes
.1
Diagramme d’états-transition . . . . . . . . . . . . . . . . . . . . . .
.2
Diagramme de classe . . . . . . . . . . . . . . . . . . . . . . . . . .
.3
Diagramme des packages . . . . . . . . . . . . . . . . . . . . . . . .
48
48
49
50
Table des figures
1.1
1.2
1.3
1.4
Architecture - Tiers client . . . . . .
Architecture - Tiers web . . . . . .
Architecture - Détails du tiers web .
Architecture - Partie « Middleware »
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5
6
7
8
2.1
2.2
2.3
2.4
2.5
2.6
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 . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
13
14
15
17
21
22
3.1
3.2
3.3
3.4
3.5
3.6
Analyse opérationnelle . . . . . . . . . . . . .
Architecture déorganisée à base de composants
Architecture « Delegate » . . . . . . . . . . . .
Architecture « Facade » . . . . . . . . . . . . .
Architecture « DAO » . . . . . . . . . . . . . .
Architecture finale . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
25
29
31
32
33
34
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.
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.
Chapitre 1
Architecture
1.1
1.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.
1.1 Comprendre les architectures multi-tiers
1.1.2
5
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.
1.1.3
Le tier Client
F IG . 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.
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 ebXML1 .
1.1.4
Le tiers Web
F IG . 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
1.1 Comprendre les architectures multi-tiers
7
Architecture du Tiers web
F IG . 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.
1.2 Architectures multi-tiers dans un contexte Java
1.1.5
8
Le « Middleware » ou Tiers du milieu
F IG . 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
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.
1.3 Architecture globale actuelle de l’application
1.3
10
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.
1.3.1
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.
1.3.2
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.
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 WSDL2 par Web service est requis pour décrire les fonctions que celuici mets à notre disposition.
2
Web Services definition langage
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.
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’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.
2.1 JCo - Java connector for SAP
13
F IG . 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 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.
2.1.2
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.
2.1 JCo - Java connector for SAP
2.1.3
14
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).
2.1.4
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 WebServices coté SAP. Pour des applications qui ont un couplage plus important, cette
F IG . 2.2 – Architecture du JCO
technique n’est pas appropriée. Il faut alors utiliser couplage a l’aide de composant
J2EE et ABAP.
2.2 WebServices ABAP sur serveur SAP WAS 6.4
2.2
2.2.1
15
WebServices ABAP sur serveur SAP WAS 6.4
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.
F IG . 2.3 – Intégration BEA - SAP
2.3
2.3.1
BEA Weblogic 8.1
Plate-forme J2EE
Le 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’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
2.3 BEA Weblogic 8.1
2.3.2
16
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é.
2.3.3
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.
2.3 BEA Weblogic 8.1
17
F IG . 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.
2.3 BEA Weblogic 8.1
2.3.4
18
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 RMI3 / CORBA4 ou SOAP5
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
Common Object Request Broker
5
Simple Object Access Protocol
4
2.3 BEA Weblogic 8.1
19
EJB avec des services de « caching », de persistance et de gestion des transactions. On
peut distinguer trois types de JavaBeans :
1. Les « Entity Beans » : Un « Entity Bean » représente un objet contenu dans
un serveur J2EE. Il contient des données, ainsi que des méthodes qui permettent
d’avoir accès à ces données. Celle-ci peuvent être stockées ou non dans une base
de donnée en utilisant l’API JDBC. Ces « Entity Beans » peuvent participer a
des transactions qui elles-mêmes mettent en jeux des « Entity Beans ». Les «
Entity Beans » sont souvent les intermédiaires entre le monde relationnel, les
bases de données et le monde objet. Ce sont les « Entity Beans » qui font ce
mapping 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 « Session
Beans » ne sont pas permanent. En fait, leur durée de vie dépends de la durée
de vie de la session utilisateur du client qui utilise se « Beans ». Il n’implémente
plus 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é introduit avec la spécification 2.0 des EJB. Cette sorte d’EJB n’est pas directement accessible par un client. Néanmoins, une application peut instancier un «
Message-Driven Bean » en envoyant un message de type JMS au serveur BEA
qui lui retournera un pointer vers cet EJB.
Couche « Application »
Le serveur BEA fournit des services fondamentaux aux composants. Ceux-ci
peuvent donc se concentrer sur leur logique « Business » sans se préoccuper des
couches 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ées
Principe de pool de connexion
BEA fournit en interne, un système de gestion des connexions vers diverses bases
de donnée. Quels intérêts y a-t-il d’utiliser ce système plutôt que de créer une simple
connexion 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 nombre
d’applications qui sont en production. Dans une configuration qui n’utilise pas les
pool de connexion BEA pour ce connecter a une base de donnée, chaque application
va ouvrir sa propre route (connexion) vers la base de donnée désirée. Si la connexion
n’est pas fermée lorsque l’application n’est plus utilisée, alors il va y avoir une
multiplication des connexions inutilisée. Du coté du serveur de base de donnée, la
limite 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, nous
devrons 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 nous
retourner une instance de la connexion. En effet, le serveur va gérer automatiquement
la connexion et surtout la déconnexion à la base. Dès que la connexion n’est plus
utilisée, il va libérer les ressources. De ce fait, un autre application va pouvoir a son
tour l’utiliser. C’est le principe du « Pool de connexion ».
2.4
2.4.1
Struts
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 la
logique métier, au niveau de la programmation.
2.4 Struts
21
F IG . 2.5 – Architecture de Struts
Comme le montre le schéma ci-dessus, la partie présentation est clairement
séparée de la logique métier qui se trouve dans le contrôleur. La partie présentation est
essentiellement constituée de code HTML et de Javascrippt. Toutefois, les tags utilisés
avant que le serveur ne construise la page sont plus sophistiqués que de simples tags
HTML. En effet, le contrôleur est présents afin de rediriger ou de répondre a certaine
requête en provenance du client. Cependant, nous avons la possibilité d’invoquer
directement 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’invoquer les méthodes du contrôleur et de les lier à des pseudos variable situées dans le
code 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 une
mé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’une
puissance redoutable. Il y a une plus grande interaction entre la partie présentation et le
contrôleur. Cela permet entre autre de pouvoir faire des redirections en tenant compte
de 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
F IG . 2.6 – Exemple d’une Action avec annotations
Pour cela, « Struts » implemente plusieurs design pattern6 dont certain sont la combinaison d’autre.
– Service to worker.
– Dispatcher view.
– Front controller.
– View helper.
– Synchronize token.
2.4.2
Viabilité de Struts sur le plan architectural
L’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’utilisation
d’Actions. Ces Actions permettent d’adapter la couche présentation à la logique
métier. De ce fait, l’adoption de Struts dans un projet d’envergure peut être d’une aide
non négligeable.
Un autre point de taille est aussi à prendre en considération. BEA, le leader
mondial du serveur d’application J2EE a intégré le framework dans sont environnement de développement, a savoir BEA workshop 8.1.
Pour allez plus en profondeur avec Struts, il faut savoir qu’Apache fournit une
version standard de Struts qui peut être complété selon les besoins. Selon le type
de développement, il est possible d’ajouter des extensions au noyau de Struts, par
exemple le projet Apache Beehive. Cette extension permet entre autre, l’utilisation
d’annotations dans le code Java. Elle fournit aussi de nouveaux tags, qui sont utiles
au niveau de la couche présentation. Ces tags permettent une plus grande interaction
entre le contrôleur et les pages JSP. Ces tags, dont la librairie est NetUI autorisent des
développements rapides et sont d’une efficacité étonnante.
6
Les 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. Ce
framework repose sur des concepts éprouvés et sont adoption ne fera qu’augmenter
la performance et la maintenance des applications J2EE. Toutefois, Struts n’est
pas à la porté de tout le monde. Il reste néanmoins un framework qui nécessite un
apprentissage 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 de
Servlets. De ce fait, Struts hérite de l’environnement de ces standards et peut interagir
avec n’importe quelles JSP ou Servlets.
Les tags HTML et les tags propres à Struts peuvent cohabiter ensemble et Struts peut
interagir avec ces deux catégories de tags.
Struts recommande d’utiliser les FormBean pour remplir des formulaires et pour
passer des donner entre différentes Actions. Cependant si un développeur souhaite ne
pas utiliser les Beans pour transférer ces donner entre les actions et les formulaires, il
peut toujours utiliser la méthode traditionnelle a savoir request.getParameter() pour
accéder aux donner.
Cela est une caractéristique très importante de Struts ! En effet, si le framework est
déployé dans un environnement de production, il y a toujours la possibilité d’utiliser
la technologie de base des composants JSP/Servlets. De ce fait, cela réduit le risque
d’adopter le framework Struts.
Chapitre 3
Passage d’un système objet a un
système n-tiers
3.1
3.1.1
La modélisation, facteur de réussite ?
Pourquoi modéliser
C’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 directement
dè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’une
application 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éfinissons
la notion de modèle. Ce qu’il est réellement, à quoi il peut bien servir et quels services
il peut nous rendre dans une phase d’étude et de développement ou bien dans une
phase 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 importance
dans des domaines tel que l’informatique, les mathématiques, la biologie et bien
d’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élisation
permet 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 la
modélisation, il n’est pas facile de définir clairement ce que peut être un modèle. Cela
dé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 et
des formes géométriques précises qui met en équation ce que l’on a compris d’un
problème.
3.1.2
Que modéliser ?
La modélisation métier
Avant toute tentative de construction, que se soit dans le domaine informatique ou
dans 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’un
département d’une entreprise, du mode de travail d’un employé ou de l’enchaînement
des actions à effectuer en vue de concevoir, dans notre cas, une application qui
permettra 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 problé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 en
avoir compris l’essence même. A ce titre, il n’est pas rare de s’entendre dire que la réalisation informatique demandée fonctionne très bien, mais que le besoin réel n’est pas
comblé. En d’autres termes, l’application fonctionne parfaitement mais n’est d’aucune
utilité pour les utilisateurs finaux.
Lors de la conception d’un nouveau système, il ne faut pas oublier une étape fonda-
F IG . 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’ensemble
du problème à traiter. Cela va nous permettre d’élaborer la dynamique de la futur
application 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 sont
les responsables informatiques qui ne connaissent pas ou peu les procédures et les
langages 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ès
complexe 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 la
clé de voûte d’une conception et d’une implémentation réussie. Prenons donc le temps
de réfléchir et de conceptualiser ce que nous avons en tête afin de concevoir d’une
maniè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 manière générale, un problème peut se résumer à un ensemble de problèmes de plus petite
taille. Le découpage d’un système en sous-systèmes peut ne pas être facile. Néanmoins, l’analyse de ses sous-systèmes en profondeur va permettre de comprendre une
bonne partie du problème de base. Ce type de raisonnement est à la base même des
niveaux 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 niveaux d’abstraction suivants :
– Niveau fonctionel.
– Niveau analyse.
– Niveau conception.
Il faut donc bien comprendre la signification de ces niveaux ainsi que le faite que
l’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-à-vis
du 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, en
l’occurrence celui de l’analyste, le développeur qui va s’appuyer sur ce modèle pour
construire l’application peut rester sur sa fain.
Une modélisation UML comprend différents schémas tel que le diagramme de
classe et le diagramme de séquence. Le niveau d’abstraction que ces schémas auront du
point de vue de l’analyse va dépendre grandement de la compréhension du problème
par 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 les
messages que peut envoyer ou recevoir un modèle est inutile. Au contraire, cela va
masquer l’essentiel et peut-être induire le développeur en erreur.
3.2
3.2.1
Difficultés inhérentes à une modélisation web
Comment modéliser les flux
Lors 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éer
un 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 est
plus facile à modéliser qu’une application en PHP ou autre. Certes, les couches
métiers et d’accès aux données nous posent moins de problèmes. En effet, dans ces
couches nous modélisons des classes et des comportements qu’UML nous permet
de décrire. Néanmoins, toutes nous posent le problème dès la conception de savoir
comment 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 le
serveur d’applications.
La couche présentation, que représentent les pages JSP doivent être modélisées
afin d’avoir une vue globale de l’application. Il n’est pas pratique de modéliser ces
pages 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 des
actions. Ces actions, après avoir récupéré ou non les informations que les utilisateurs
ont pu entrer, redirigent ou construisent de nouvelles pages qui a leur tour pourront
rendre compte et diffuser de l’information directement à l’utilisateur. Peu a peu, nous
voyons émerger dans ce schéma le principe des machines d’états. Voyons comment
les machines d’états peuvent nous aider à modéliser les flux d’une application web.
3.3 Travailler avec les couches, division de l’application
3.2.2
28
Les machines d’états pour représenter et modéliser les pages
Nous appelons diagramme d’états une représentation graphique associée à une machine d’états. Les diagrammes d’états sont utilisés pour modéliser le comportement
des objets, c’est-à-dire que, pour chaque type d’objet, chaque classe, on peut définir
une machine d’états correspondante. Nous venons de dire plus haut qu’il ne serait pas
convenable d’associer une page JSP à une classe. Lorsque nous parlons de diagramme
d’états, nous associons celui-ci à la modélisation du comportement des objets. N’est-ce
pas paradoxal ?
En fait, il nous faut savoir que la rigueur d’UML n’est pas forcement de mise dans
la modélisation des flux. Tout ce que l’on a besoin de savoir, c’est l’enchaînement des
actions qu’une page nous propose avec son éventuel résultat. De ce fait, le diagramme
d’états est recommandé dans notre cas.
L’utilisation des diagrammes d’états sont particulièrement efficace dans le cas d’un
développement avec le framework Struts. Celui-ci mets en oeuvre le principe d’actions
et de redirection en fonctions d’un état ou d’un comportement.
3.3
3.3.1
Travailler avec les couches, division de l’application
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 de
mauvaises bases. Là encore, il nous faut savoir où l’on veut aller. La rigueur est de
mise.
Dans une architecture multi-tier, les composant business peuvent et sont souvent
repartis en différents endroits sur un serveur. Etant donnée que l’insertion de codes
Java ou « scriplets » est possible dans une page de type JSP, il est possible de faire
appel à 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 se
poser. Il se peut très bien que cette architecture soit stable durant un certain temps. Il
se peut même qu’au fil du temps, des fonctionnalités viennent se rajouter à celles de
base !
Supposons maintenant que le composant « Accès aux données » serve à établir une
connexion à une base de donnée Oracle. Supposons également que le composant «
Accès aux LDAP » serve à établir une connexion à un annuaire NOVEL. Lors d’un
changement d’architecture de l’un de ces deux systèmes, l’application cessera de fonctionner, et c’est toute l’application, c’est-à-dire toutes les pages qui intègrent ces appels
qu’il faudra modifier ! Impensable !
Cet exemple nous montre l’importance qu’il y à a concevoir dès le début une architecture structurée. Le couplage des couches applicatives est donc un réel problème. Ce
3.3 Travailler avec les couches, division de l’application
29
F IG . 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 responsabilités de chacune des couches, citons-les dans l’ordre, de la plus haute à la plus
basse :
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 du
serveur 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 dynamique
des Use cases. C’est elle aussi qui va se charger de la validation des règles de gestion
afin que les données transmises aux couches inférieures soient correctes. Cette couche
met en oeuvre le pattern « Delegate ».
La couche « Services » va encapsuler les processus métier ainsi que la gestion des
transactions. Cette couche met en oeuvre le pattern « Facade ».
La couche « Model » va contenir tous les éléments, c’est-à-dire le diagramme de
classe avec ou non l’implémentation de certains patterns. C’est en effet le coeur de
l’application.
3.3 Travailler avec les couches, division de l’application
30
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 jusqu’aux éléments du modèle afin qu’elle puisse être exploitable par l’application. Cette
couche implémente le pattern « DAO ».
3.3.3
Les « Design Pattern » pour découpler les couches
Pattern « Delegate »
Dans un contexte multi-tier, le système distribué a besoin d’invoquer des méthodes
qui se trouvent parfois sur différentes machines. De ce fait, les clients sont exposés à la
complexité des appels à ces méthodes et cela crée un fort couplage entre l’application
et l’architecture sous-jacente.
En effet, le problème est que les composants qui font partie du tier présentation
doivent 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ême
des changements d’implémentation au niveau du code surviennent. Si l’implémentation de la partie business change, alors l’implémentation de la partie présentation
devra é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 composants
business.
– Il faut minimiser le couplage entre ces couches.
La solution envisagée est de mettre en place le pattern « Delegate » au sein de
l’architecture de l’application. En effet, celui-ci va permettre de réduire le couplage
entre le tier présentation et les composants « Business ». Ce Design pattern masque
l’implémentation du composant. Il fournit un service à la partie appelante. Cela
permet de pouvoir faire des changements d’implantation dans tous les composants
business 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 se
produire dans les couches inférieures.
Quand ce pattern est utilisé avec le pattern Session Facade, il y a une relation
1-1 entre les deux. Ce rapport 1-1 existe parce que la logique applicative qui pourrait
avoir été encapsulée dans un « Business Delegate » concernant son interaction avec
de multiples services sera souvent factorisée de nouveau dans une « Session Facade »,
ce que nous allons voir par la suite.
3.3 Travailler avec les couches, division de l’application
31
F IG . 3.3 – Architecture « Delegate »
Pattern « Facade »
Le design Pattern Facade est sans doute le plus utilisé des Pattern J2EE. Ce
pattern porte bien son nom. Le but est de créer un mur entre le client, et le reste de
l’application. En effet, les composant business exposent leurs interfaces au monde
entier. Ce « monde entier » est, entre autres, le serveur d’application et tout autre
serveur qui participe a la logique business de l’entreprise.
Ici aussi, la question du couplage entre les couches se pose. Il serait tout à fait
possible 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 avoir
accès occasionnent parfois des surcharges au niveau du serveur d’application, du
trafic réseau important et peut ralentir l’exécution de l’application et congestionner les
points d’entrée du serveur !
Quand il y a une exposition des objets « Business » au client, celui-ci doit
comprendre et être responsable des relations qu’il pourrait y avoir entre ces différents
objets. Or, ce n’est pas son rôle. La mise en place d’une architecture de ce type serait
une grave erreur de conception.
Le but du pattern « Facade » est donc de mettre à disposition de l’application
au moyen d’interfaces, les méthodes dont elle a réellement besoin afin que son flot
d’exécution se déroule correctement.
3.3 Travailler avec les couches, division de l’application
32
F IG . 3.4 – Architecture « Facade »
Pattern « DAO »
Les accès aux données varient selon la source des données. Cette source peut être
une base de relationnelle ou objet, ou bien un ERP comme SAP.
Dans une application d’entreprise de type J2EE, à un moment donné, la gestion de
la persistance et la persistance en elle-même est obligatoire et nécessaire. Pour ces
applications, les mécanismes d’accès aux sources de données sont implémentés de
différentes manières. Certaines applications peuvent nécessiter l’accès à des données
qui se trouvent sur des systèmes distants, citons par exemple l’accès à un annuaire
LDAP, SAP ou encore des bases Oracle.
Afin d’accéder à ces sources de données, les applications J2EE doivent utiliser
l’API JDBC. Cette API fournit des méthodes standard d’accès et de manipulation
des données. Toutefois, bien que ces API soient standards, il se peut que la façon
d’y accéder, notamment au niveau de la syntaxe, soit différente en fonction du type
de base de donnée avec laquelle on veut communiquer. Par exemple, la manière de
communiquer est différente entre une base de donnée Oracle et MySQL ou encore
SQL Serveur. En ce qui concerne SAP, une application ne peut pas directement
interroger la base qui se trouve derrière. C’est le système SAP qui s’en charge. La
maniè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 du
marché ainsi que les pilotes propriétaires qui sont utilisés peuvent introduire un
fort niveau de dépendance entre l’application et l’interface de persistance. Ces
dépendances peuvent être la cause de problèmes futurs dans le cas d’un changement
SGBD. En effet, quand les sources de données changent, les composants d’accès à ces
données doivent être modifiés eux aussi !
De ce problème, ressortent quatre points importants pour lesquels nous devons
trouver une solution.
– Les servlets, les pages JSP, le pageFlow peuvent a tout moment avoir besoin
d’accéder à une source de donnée.
– Les API de gestion de bases de données ainsi que leurs possibilités varient selon
le 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 vue
de l’application.
La solution est l’implantation du Pattern DAO au niveau de la couche d’accès aux
données de l’application.
F IG . 3.5 – Architecture « DAO »
3.4
Architecture de l’application
Nous 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 nous
montre l’architecture d’une partie de l’application avec la mise en oeuvre des pattern
mentionnés plus haut.
3.4 Architecture de l’application
F IG . 3.6 – Architecture finale
34
Chapitre 4
Démarche de transformation
4.1
4.1.1
Analyse
Examens des modèles existants
La base de départ de cette réarchitecture est évidemment les modèles de conception de l’application d’origine. Celle-ci a été conçue à partir d’un besoin. Dans la
phase d’analyse et après avoir évalué les besoins futurs, il s’est avéré que ces besoins
ont pris une orientation différente que ceux de départ.
De toute évidence, un delta est apparu entre les besoins identifiés de l’application future et celle actuellement utilisée. C’est pourquoi, l’analyse des modèles
existants de l’application a fait ressortir que la migration de l’application ne pourrait
se 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’utilisation et de la création d’une application Web, même si celles-ci sont construites
dans le même langage de programmation. Les facilités d’utilisation de la première
deviennent 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 client
riche. Dans le second cas, à savoir l’application migrée sur le serveur BEA, nous
avons affaire à une application qui doit pouvoir simuler un client riche, être connectée
a un ERP, à savoir SAP. De plus l’interaction entre le client et le serveur s’appuie sur
le protocole HTTP qui n’est pas orienté connexion. De ce fait, nous avons à gérer le
problè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çon
efficace cette application, une réflexion a dû être entreprise sur la manière de résoudre
ces 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 cible
Pour 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 communes. Le fait d’intégrer l’application au sein de ce portail va faciliter grandement
le développement de certaines de ses parties. En effet, le concept de « portlet », qui
est une entité autonome, une sorte de brique dont le développeur dispose, permet la
réutilisation de code et de logique applicative. Par exemple, certains utilisateurs ont
besoin de s’authentifier pour pouvoir avoir accès à certaines applications. Typiquement, la partie authentification va être dévolue à une « portlet » spécialisée. Un simple
glisser/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’un
certain design, au sens graphique du terme, doit être respecté. Le fait de respecter un
lay-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é mais
plutôt la chartre graphique de l’entreprise ainsi que les règles communément définies
par les responsables du développement.
La connaissance des différentes règles qu’il faut appliquer afin que l’application
respecte les standards de l’entreprise va permettre de concevoir des modèles qui
respectent 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. Voyons
les 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 représentation du processus tel qu’il a été élaboré lors du travail qui a préparé la
modélisation. Il montre l’enchaînement des activités qui concourrent au processus.
2. Diagramme de cas d’utilisation
Le diagramme de cas d’utilisation décrit la succession des opérations réalisées
par 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 que
le système met en oeuvre.
3. Diagramme de classes
Le diagramme de classe représente l’architecture conceptuelle du système : il
décrit les classes que le système utilise, ainsi que leurs associations, que ceux-ci
représentent un emboîtage conceptuel (héritage, marqué par une flèche terminée
par un triangle) ou une relation organique (agrégation, marquée par une flèche
terminée par un diamant).
4. Diagramme de séquences
Le diagramme de séquence représente la succession chronologique des opérations réalisées par un acteur : saisir une donnée, consulter une donnée, lancer
un traitement ; il indique les objets que l’acteur va manipuler, et les opérations
qui font passer d’un objet à l’autre. On peut représenter les mêmes opérations
par un diagramme de collaboration, graphe dont les noeuds sont des objets et les
arcs (numérotés selon la chronologie) les interactions entre objets : diagramme
de séquence et diagramme de collaboration sont deux vues différentes, mais logiquement équivalentes (on peut construire l’une automatiquement à partir de
l’autre), d’une même chronologie.
5. Diagramme d’états
Le diagramme d’état représente la façon dont évoluent ("cycle de vie") durant
le processus les objets appartenant à une même classe. La modélisation du
cycle de vie est essentielle pour représenter et mettre en forme la dynamique du
systè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 que
système.
Dans le cas de cette réarchitecture, l’accent a été mis principalement sur la modélisation système et moins sur la modélisation métier. C’est pourquoi, les modèles
suivants ont été utilisés :
1. Diagramme de cas d’utilisation
2. Diagramme de classes
3. Diagramme d’états
4.1.4
Design et architecture
Le 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 permet
d’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. Etant
donné la multiplicité des Web services utilisé, celle-ci a permi de vraiment partitionner
l’application en couches afin de respecter les différents patterns et de contrôler les
accès aux ressources.
4.2
4.2.1
Etude de faisabilité
Enjeu de cette réarchitecture
Jusqu’à 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 est
simple, puisque la version de BEA était la 7. Un des buts de ce développement est
de 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 sein
de la version 8 du Workshop est assez délicate à mettre en oeuvre du point de vue
architectural. En effet, l’architecture nous impose la mise en oeuvre de différentes
couches en utilisant des design patterns afin de séparer les différentes logiques
applicative, ce que nous avons mentionné haut.
4.2.2
Environnement de développement BEA
L’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 applications
d’entreprise dans ce contexte. Bien que nous connaissons l’environnement BEA, il y
a une différence fondamentale entre connaître un produit et utiliser les fonctionnalités
qu’il nous met à disposition. Il nous a donc été nécessaire de prendre en main
complètement le produit afin d’être opérationnel une semaine après avoir débuté son
apprentissage.
Avec le nombre impressionnant de fonctionnalité et de possibilités qu’offre cet
IDE, nous avons appris les principale fonctionnalité du logiciel en faisant l’impasse
sur d’autres. Comme nous allons le voir plus bas, des choix architecturaux importants
ont du être fait en ce qui concerne la méthode d’implantation des Web services. En
effet, le Workshop propose l’utilisation de composant tel que les « Java control » ou
des « custom control » qui permettent d’encapsuler des appels a des Web service ou
a des bases de données. Lorsque ces contrôle sont crées, nous avons la possibilité
4.2 Etude de faisabilité
39
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 en
oeuvre une architecture particulière afin de respecter certain standards, typiquement
ceux de l’entreprise.
4.2.3
Contraintes architecturales
Lors 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 étroite
entre l’équipe de développement SAP et l’équipe de développement Java. Comme
mentionné précédemment, en ce qui concerne la gestion de la persistance, celle-ci
doit se faire au niveau du DAO. Cela permet d’avoir une plus grande liberté en cas
de changement de la base de donnée ou tout autre système. Etant donné que dans
notre 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 écrits
spé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 de
vérifier que les Web services répondaient bien à ce pourquoi ils ont été conçus. Ces
tests nous ont été fort utiles. En effet, ils ont pu mettre en lumière des incohérences
ainsi 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 puissent
communiquer. Ne négligeons donc pas les tests d’intégration, car ils peuvent mettre
en lumière des problèmes insoupçonnés.
4.2.4
Contraintes au niveau de l’IHM
Là 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 grande
possibilité d’interaction entre l’utilisateur et le système. Cela est loin d’être le cas lors
de l’utilisation d’un client Web.
Pour résoudre ce problème, nous avons dû introduire énormément de JavaScript
dans le code HTML des pages JSP. En effet, étant donné que le code JavaScript
s’exécute du coté client, cela nous a permi de simuler des opérations qui d’habitude se
retrouvent plus généralement sur des clients lourds.
Dans la conception d’une application Web qui est destiné à l’Internet, nous
avons à faire face à des clients sur lesquels peuvent s’exécuter différentes versions de
navigateur. Il y a aussi le problème non seulement des différences de version entre
4.2 Etude de faisabilité
40
les navigateurs mais aussi les différents navigateurs eux-mêmes. Citons par exemple
Netscape ou Internet explorer. Plus récemment Mozilla et bien d’autres encore. Ces
navigateurs 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 sur
le 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 les
pages HTML.
4.2.5
Contraintes liées à l’utilisation des Web services
Pour 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 permettre de construire les classes d’appel vers ces Web services. Ces outils sont puissant 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é de
cré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écanique
d’appel a des Web services. Ce dont nous avons besoin, est la localisation sous forme
d’une URL du fichier WSDL qui contient la définition du Web services ainsi qu’un
login et un mot de passe pour la connexion. Une fois ces données renseignés, BEA
va 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 fichiers sources. De ce fait, nous n’avons pas la possibilité de modifier le code. Un autre
inconvénient majeur, est que BEA n’autorise pas l’instanciation du Web service au
dehors du « Page Flow ». Cela pose un problème d’architecture, car dans ce cas, la
couche DAO n’est plus du tout indépendante de la gestion de la persistance. Dans une
architecture normalement constituée, c’est dans le DAO que cette instanciation aurait
dû se faire. Un élément de réponse à ce problème est que BEA utilise les annotations
Java 1.5 pour gérer ces « Java control » dévolus à la gestion des Web services. De
ce fait, il faudrait insérer des annotations Java dans le code du DAO afin que celui-ci
puisse pouvoir gérer de façon efficace le Web services qui lui sont attribués.
4.2 Etude de faisabilité
41
Génération automatique avec « clientgen »
Un autre moyen de générer la mécanique d’accès aux Web services est d’utiliser
l’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é dans
l’application est fourni en annexe. Contrairement à la méthode interne de BEA, cet
utilitaire est plus souple et il permet de conserver les sources générés afin de les
modifier si besoin. Un autre point intéressant est que cet utilitaire nous permet de
créer des packages au sens Java. C’est une bonne approche, car cela va nous permettre
de 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 effet, 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 avons
découvert qu’il y avait un problème de mapping entre les différentes classes. Problème
qui 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 pas
complètement résolu, nous devons utiliser la mécanique interne de BEA pour générer
les Web services.
4.2.6
Respect de la séparation des couches applicatives
Comme nous venons de le voir ci-dessus, l’utilisation de « clientgen » pose problè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 fort
couplage 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 services
dans le « Page Flow » qui n’est autre le contrôleur Java au sens UML. D’où la
question : comment rendre disponible l’instance créée dans le « Page Flow » au niveau
du 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, à savoir
de la « Façade » au « Delegate » puis du « Delegate » au « DAO ». Vous serez
d’accord avec moi d’admettre que cette façon de faire est ridicule car l’utilisation de
ces patterns a pour but de découpler les couches applicatives afin de rendre l’application évolutive et maintenable. Or, c’est tout le contraire qui ce passe ici. Au lieu
de 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ésoudre
ce problème.
4.3
4.3.1
Conception et tests
Tenir compte des modèles
Lors 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 avons
créés au cours de l’analyse. En effet, nous avons bâti cette application en partant
d’un besoin. Le besoin nous a conduit à l’élaboration de modèles pertinents qui nous
ont permis d’obtenir une abstraction de la réalité. Cette abstraction de la réalité est
nécessaire et inévitable. Si nous ne respectons pas les lignes directrices que sont
les modèles, nous allons partir dans la conception d’une application qui n’est pas
conforme à la réalité que nous avons modélisée.
Selon différentes études1 qui ont été menées depuis l’avènement de la conception de logiciels, la majorité des applications qui ne sont pas utilisées le sont à cause
du fait qu’elles ne répondent pas du tout au besoin qui a été exprimé. Quoi de plus
triste que de savoir que notre application n’est pas utilisée simplement car nous
n’avons pas répondu aux besoins des utilisateurs ?
Soyons donc prompt à utiliser les modèles que nous avons conçu à partir d’un
réel besoin afin que les applications qui en résulteront puissent correspondre aux
attentes des utilisateurs.
4.3.2
Comment tester une application Web
Les 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-ci
va être déployée successivement dans trois environnements. En effet, à la fin de la
conception, l’application va être déployée dans un environnement de développement
puis, dans un environnement dit de qualité puis, à la fin du processus, dans l’environnement de production.
Ces trois étapes successives permettent de tester l’application dans sa globalité et
de déceler des bugs ou des incohérences vis-à-vis des besoins exprimés pendant la
phase d’analyse.
Hormis ces trois environnements, le test d’une application web n’est pas une chose
aisée. Etant donné qu’une application se construit avec des briques ou composants logiciels, le plus sûr est d’effectuer des tests unitaires sur ces composants fin de s’assurer
1
http : //www.standishgroup.com/sample_research/chaos_1994_1.php
4.3 Conception et tests
43
de leurs fiabilité. Après quoi des tests globaux peuvent être effectués par un utilisateur
afin 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. Les
différentes technologies qui existent aujourd’hui renforcent cette idée. Afin que les
produits que nous créons soient fiables, robuste et de qualité, nous devons respecter
certaines 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, nous
avons la possibilité d’entreprendre des constructions logicielles très rapidement avec
des outils aussi performants que sont XDE de Rational ou bien WinDev et encore
BEA 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 vu
de la maintenance ou alors du point de vu de la modification d’une ou plusieurs
fonctionnalités.
L’utilisation de modèles cohérant peut nous aider grandement. Prendre du temps au
début de chaque phase de conception nous épargnera bien des difficultés a nous même
ou alors a la personne qui reprendra notre travail. Dans un projet de grande envergure
ou non, il peut être facile de se perdre, surtout si nous avons a prendre en charge
plusieurs projets en même temps.
Nous nous sommes plus particulièrement intéressé à la conception d’applications 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 et
pertinente afin de construire un squelette précis de notre application.
Comme dans tous développement, des contraintes du a l’environnement ou aux
utilisateurs sont inévitable. Dans ce cas, notre force va résider dans la manière de les
contourner et de les surmonter tout en respectant les besoins des utilisateurs.
4.3 Conception et tests
45
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 complexes ».
3. De tenir compte de la limite des technologies mises en oeuvre ainsi que de leurs
complexité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 aurons fait correctement notre métier d’informaticien.
Bibliographie
[1] Chuck Cavaness. Programming Jakarta Struts. O’REILLY, 18 rue Séguier 75006
PARIS, 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, Elements of Reusable Object-Oriented Software. Addison Wesley Longman, Inc,
1994.
[4] Chuk Musciano et Bill Kennedy. HTML, The Definitive Guide. O’REILLY, third
edition, 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
.2
Diagramme de classe
49
.3 Diagramme des packages
.3
Diagramme des packages
50