Chapitre 15 Les serveurs applicatifs et les architectures Java

179
Chapitre 15 Les serveurs applicatifs
et les architectures Java
Nous avons vu jusqu’ici, dans les chapitres précédents, que les utilisateurs
accèdent au système d’information à travers le réseau sans couture avec leur
station de travail munie d’un navigateur, et qu’ils ont accès aux fonctions de
la bureautique. Maintenant, il convient de regarder d’un peu plus près les
applications faisant partie du système d’information. Comment sont-elles
structurées et comment, grâce aux middlewares, s’articulent-elles avec la
station de travail et le réseau?
Figure 15.1. Rappel de l’architecture à trois niveaux logiques à client léger.
03 Lucas Part 02 Page 179 Lundi, 20. août 2001 2:58 14

Deuxième partie • L’infrastructure technique, sa construction, son fonctionnement
180
Dans l’architecture standard à trois niveaux logiques adoptée chez France
Télécom, le navigateur et le serveur Web représentent le niveau 1, le niveau
de la présentation. Ce niveau est en prise directe avec le niveau 2, les
serveurs applicatifs, qui est en relation avec le niveau 3, les applications
patrimoniales et les données de l’entreprise. Ainsi, l’accès aux données de
l’entreprise se fait grâce aux services fonctionnels offerts par des serveurs de
niveau 3 qui sont les seuls pouvant accéder aux systèmes de gestion des
bases de données par des interfaces standard.
Le serveur applicatif : un élément logique, un objet
à forte granularité
Rappelons qu’une caractéristique importante d’un serveur applicatif est qu’il
ne comprend pas de données pérennes. Les données de l’entreprise, se trou-
vent tout naturellement au troisième niveau logique. Un serveur applicatif
peut gérer ses propres données locales et dans ce cas, elles ne sont pas
accessibles aux autres serveurs. Ces données locales sont volatiles et il n’y a
pas de sauvegarde sur bande magnétique.
Un serveur applicatif est un serveur logique, c’est-à-dire, un ensemble logi-
ciel pouvant être installé sur une machine physique, seul ou avec d’autres
serveurs applicatifs.
Il est conçu et réalisé avec la technologie objet. Un serveur applicatif peut
être considéré comme un « objet » à forte granularité : il offre des services,
mais il occulte leur construction.
Le serveur applicatif déroule la cinématique de l’application, assurant l’inter-
face entre la station de travail et les données de l’entreprise et les applica-
tions patrimoniales du système d’information.
Il ne faut pas confondre « client » et « station de travail ». Trop souvent
les termes « client » et « serveur » sont utilisés de manière restrictive :
client comme station de travail et serveur comme système de base de
données. Or, le client et le serveur sont tous les deux des processus
informatiques. Cette précision est d’autant plus importante dans une
architecture à trois niveaux, que le niveau 2, celui des serveurs applica-
tifs, met en œuvre des relations de type client-serveur entre les diffé-
rents serveurs applicatifs. De même, ces relations se trouvent entre les
serveurs applicatifs de niveau 2 et les serveurs de niveau 3.
03 Lucas Part 02 Page 180 Lundi, 20. août 2001 2:58 14

Chapitre 15 • Les serveurs applicatifs et les architectures Java
181
Des instances d’un même serveur applicatif peuvent exister sur différentes
machines physiques. La plate-forme matérielle et logicielle qui accueille les
serveurs applicatifs fait partie de l’infrastructure technique et nous avons
défini des plates-formes standard d’exécution (voir Chapitre 17)
Les applications patrimoniales et les serveurs
de données de l’entreprise : la réutilisation et
la capitalisation des ressources
Le système d’information actuel comprend un ensemble d’applications qu’il
convient de conserver, tout en les adaptant aux exigences de la nouvelle
architecture (fonctionnelle et technique). Ces applications comprennent des
traitements et des données. Aujourd’hui, les applications ne sont utilisées
que par une seule application cliente. Les données sont alors la propriété
d’une application et ne sont pas à disposition du reste de l’entreprise. S’agis-
sant du patrimoine de l’entreprise, il convient de rendre ces données acces-
sibles sous forme de services à toute application habilitée, sans exiger ni leur
réplication ni une connaissance profonde des modalités de leur construction
(voir figure 15.3).
Dans l’architecture à trois niveaux logiques, les éléments réutilisables se
trouvent tout naturellement au niveau 3, le niveau 2 comprenant en général
les spécificités métier de l’application (dont certaines peuvent être sous forme
d’éléments réutilisables). Ainsi, l’encapsulation d’une application patrimoniale
Figure 15.2. La constitution des serveurs applicatifs.
03 Lucas Part 02 Page 181 Lundi, 20. août 2001 2:58 14

Deuxième partie • L’infrastructure technique, sa construction, son fonctionnement
182
permet d'offrir une interface de type service (éventuellement objet) pour accé-
der aux données et pour effectuer des opérations sur celle-ci selon les règles
de gestion de l’entreprise. Cette interface masque la complexité et les tech-
niques utilisées pour l’application utilisatrice des nouveaux services.
Figure 15.3. L’encapsulation et les services.
Figure 15.4. La transformation d’une application pour offrir des services.
03 Lucas Part 02 Page 182 Lundi, 20. août 2001 2:58 14

Chapitre 15 • Les serveurs applicatifs et les architectures Java
183
Pour fournir les services, il est essentiel d’isoler les données et les traitements
responsables de leur gestion (on parle ici de l’application responsable de la
gestion de certaines données et non plus de l'application propriétaire). Les
données et leurs règles de gestion sont séparées des applications de type
« métier » (organisation des processus de l’entreprise) et mises à disposition
sous forme d’un serveur de données accessible par des interfaces publiques. La
partie métier de l’application initiale est reconstruite pour accéder aux données
à travers ces mêmes interfaces. Elle peut également offrir des services à valeur
ajoutée aux autres applications impliquant un accès ou non aux données.
Par extension, dans le cas de France Télécom, un équipement de télé-
communications peut être considéré comme un serveur patrimonial, offrant
des services d’activation.
Le langage de développement privilégié pour
les nouvelles applications : Java
Nous avons vu dans les chapitres précédents que l’utilisation de Java pour le
développement des nouvelles applications est un choix du programme
@rchimède. Ce choix a été dicté par l’orientation objet que nous avons
donnée à la conception mais aussi parce que ce langage permet de répondre
à la majorité des besoins de l’entreprise. Il permet ainsi d’uniformiser les
outils, les formations et de capitaliser en introduisant la réutilisation des
objets développés.
Il convient de conserver la séparation des niveaux logiques, même si le
serveur Web, le serveur applicatif et le serveur de données se trouvent
sur la même machine physique : certains produits du marché ont
tendance à vouloir gommer cette séparation, ce qui entraîne par la suite
des difficultés d’évolution et de déploiement.
Le langage Java a été conçu par Sun et a réellement pris son essor avec
le réseau Internet et le World Wide Web. La diffusion rapide du langage
Java ne s'explique pas seulement par un phénomène de mode, mais
aussi par le fait que les concepts de Java répondent au bon moment à
de nouveaux besoins qui apparaissent dans le cadre de la réalisation
des logiciels. Ces nouveaux besoins, qui sont à l'origine du succès gran-
dissant de Java auprès des développeurs et des utilisateurs, ont un
point commun, celui de la création d'applications distribuées.
03 Lucas Part 02 Page 183 Lundi, 20. août 2001 2:58 14