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 Architecture 4
1.1 Comprendre les architectures multi-tiers . . . . . . . . . . . . . . . . 4
1.1.1 Les trois niveaux d’abstraction d’une application . . . . . . . 4
1.1.2 Architecture n-tiers ou architecture distribuée . . . . . . . . . 5
1.1.3 LetierClient .......................... 5
1.1.4 LetiersWeb .......................... 6
1.1.5 Le « Middleware » ou Tiers du milieu . . . . . . . . . . . . . 8
1.2 Architectures multi-tiers dans un contexte Java . . . . . . . . . . . . 8
1.3 Architecture globale actuelle de l’application . . . . . . . . . . . . . 10
1.3.1 Cotéclient ........................... 10
1.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 12
2.1 JCo - Java connector for SAP . . . . . . . . . . . . . . . . . . . . . . 12
2.1.1 Remote Function Call (RFC) . . . . . . . . . . . . . . . . . . 12
2.1.2 RFCLibrary .......................... 13
2.1.3 Appel de fonctions Java depuis SAP R/3 . . . . . . . . . . . . 14
2.1.4 Architecture Jco . . . . . . . . . . . . . . . . . . . . . . . . 14
2.2 WebServices ABAP sur serveur SAP WAS 6.4 . . . . . . . . . . . . . 15
2.2.1 Principe de fonctionnement . . . . . . . . . . . . . . . . . . 15
2.3 BEAWeblogic8.1 ........................... 15
2.3.1 Plate-forme J2EE . . . . . . . . . . . . . . . . . . . . . . . . 15
2.3.2 Architecture du serveur d’application Weblogic . . . . . . . . 16
2.3.3 Composant logiciel d’une architecture multi-tiers . . . . . . . 16
2.3.4 Structuration des couches applicatives . . . . . . . . . . . . . 18
2.3.5 Accèsaudonnées........................ 19
2.4 Struts .................................. 20
2.4.1 Qu’est ce que Struts ? . . . . . . . . . . . . . . . . . . . . . . 20
2.4.2 Viabilité de Struts sur le plan architectural . . . . . . . . . . . 22
2.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 24
3.1 La modélisation, facteur de réussite ? . . . . . . . . . . . . . . . . . . 24
3.1.1 Pourquoi modéliser . . . . . . . . . . . . . . . . . . . . . . . 24
3.1.2 Quemodéliser?......................... 25
3.1.3 Les niveaux d’abstraction, jusqu’ou aller ? . . . . . . . . . . . 26
3.2 Difficultés inhérentes à une modélisation web . . . . . . . . . . . . . 27
3.2.1 Comment modéliser les flux . . . . . . . . . . . . . . . . . . 27
3.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 . . . . . . . . . . 28
3.3.1 Le couplage des couches, vrai ou faux problème ? . . . . . . . 28
3.3.2 Les couches aplicatives, à chacune sa résponsabilité . . . . . 29
3.3.3 Les « Design Pattern » pour découpler les couches . . . . . . 30
3.4 Architecture de l’application . . . . . . . . . . . . . . . . . . . . . . 33
4 Démarche de transformation 35
4.1 Analyse ................................. 35
4.1.1 Examens des modèles existants . . . . . . . . . . . . . . . . 35
4.1.2 Compréhension et intégration dans l’architecture cible . . . . 36
4.1.3 Quels modèles utiliser ? . . . . . . . . . . . . . . . . . . . . 36
4.1.4 Design et architecture . . . . . . . . . . . . . . . . . . . . . 37
4.2 Etudedefaisabilité ........................... 38
4.2.1 Enjeu de cette réarchitecture . . . . . . . . . . . . . . . . . . 38
4.2.2 Environnement de développement BEA . . . . . . . . . . . . 38
4.2.3 Contraintes architecturales . . . . . . . . . . . . . . . . . . . 39
4.2.4 Contraintes au niveau de l’IHM . . . . . . . . . . . . . . . . 39
4.2.5 Contraintes liées à l’utilisation des Web services . . . . . . . 40
4.2.6 Respect de la séparation des couches applicatives . . . . . . . 41
4.3 Conceptionettests ........................... 42
4.3.1 Tenir compte des modèles . . . . . . . . . . . . . . . . . . . 42
4.3.2 Comment tester une application Web . . . . . . . . . . . . . 42
Conclusion 44
Bibliographie 46
Glossaire 47
Annexes 48
.1 Diagramme d’états-transition . . . . . . . . . . . . . . . . . . . . . . 48
.2 Diagrammedeclasse .......................... 49
.3 Diagramme des packages . . . . . . . . . . . . . . . . . . . . . . . . 50

Table des figures
1.1 Architecture - Tiers client . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2 Architecture - Tiers web . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3 Architecture - Détails du tiers web . . . . . . . . . . . . . . . . . . . 7
1.4 Architecture - Partie « Middleware » . . . . . . . . . . . . . . . . . . 8
2.1 Scénario d’utilisation et de création d’une RFC . . . . . . . . . . . . 13
2.2 ArchitectureduJCO .......................... 14
2.3 Intégration BEA - SAP . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.4 Architecturen-tiers ........................... 17
2.5 Architecture de Struts . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.6 Exemple d’une Action avec annotations . . . . . . . . . . . . . . . . 22
3.1 Analyse opérationnelle . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.2 Architecture déorganisée à base de composants . . . . . . . . . . . . 29
3.3 Architecture « Delegate » . . . . . . . . . . . . . . . . . . . . . . . . 31
3.4 Architecture « Facade » . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.5 Architecture«DAO».......................... 33
3.6 Architecturefinale ........................... 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éparte-
ment 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.