Architecture des systèmes d'information

La décennie 70

Figure figures/bb/70-serveurs

  • Le service informatique gère des serveurs de traitements qui alimentent des terminaux.
  • Les traitements et les données sont centralisés sur des serveurs d'infrastructure.

Les données sont éventuellement centralisées sur des serveurs spécifiques (serveurs de fichiers).

Figure figures/bb/serveur-fichiers

Cette architecture permet

  • de sécuriser les données
  • d'éviter les redondances

Le modèle relationnel (les années 80)

  • 1970 : CODD « Relational model of data »
  • 1982 : Création d'Oracle

Figure figures/bb/80-SGBDR

Enrichissement du relationnel (les années 80/90)

  • L'interface d'accès aux données s'améliore :
    • Création des vues (simplification du modèle),
    • Création des triggers (introduction des traitements),
    • Création des procédures stockées (amélioration des traitements),
    • Définition des utilisateurs et des rôles (sécurisation),
  • La gestion des données est la partie la plus importante.
  • Mise en place des méthodes de conception orientées données:
    • Entités / Associations
    • Merise / Modèle Conceptuel des Données
  • Création du métier d'administrateur des données (DBA).

Système d'informations (les années 80/90)

  • Le centrage sur les données permet:
    • une approche globale (toutes les applications partagent et modifient les mêmes données),
    • l'activité de l'organisation est modélisée et représentée par les données (approche systémique).
  • Le service informatique est remplacée par le système d'informations (SI)
    Définition d'un SI : un ensemble structuré de ressources (matériels, logiciels et données) qui permet la collecte, le traitement et la distribution des informations de l'organisation.
  • L'architecture des SI est un problème complexe.

Le micro-ordinateur (fin des années 80)

  • Caractéristiques :
    • coût important
    • faible capacité de calcul et de stockage
  • Problèmes posés par le micro-ordinateur :
    • Coordination avec l'informatique d'entreprise (et le service informatique)
    • Luttes de pouvoir pour savoir où sont les données et les traitements
  • Conséquences :
    • Apparition d'applications autonomes
    • Duplication (avec erreurs) des données entre le SI et les PC

Le client/serveur (les années 90)

Figure figures/bb/arch-clt-serveur

Avantages :

  • Serveur de taille moyenne (baisse du cout),
  • Intégration des PC (hétérogènes) dans le SI.

Inconvénients :

  • Le poste de travail est qualifié de client lourd,
  • Le coût d'exploitation est très important (poste difficile à maintenir),
  • Pas de porte ouverte vers les traitements et les données.

Architecture à deux niveaux (2-tier) (années 2000)

Objectif: Simplifier et normaliser le client/serveur.

Figure figures/bb/arch-2tier

Architecture des applications

Figure figures/bb/arch-appli

Constats :

  • Les parties métier et données sont dupliquées dans plusieurs applications,
  • Il est très difficile de maintenir ces implantations (technologies, ressources humaines, objectifs différents),
  • La couche de stockage est le seul élément commun.

La couche métier regroupe les actions métier qui sont indépendantes des logiques applicatives :

Figure figures/bb/app-middleware

Cette approche permet de

  • simplifier les applications,
  • gérer les communications inter-applications,
  • pérenniser et sécuriser et faire évoluer la partie métier.

Architecture à trois niveaux (3-tier)

Introduction du middleware qui permet de factoriser les traitements métier.

Figure figures/bb/arch-3tier

Avantages :
  • Simplification des applications
  • Indépendance du stockage
  • Montée en charge
  • Sécurité accrue
  • Ouverture vers les traitements
  • N-tiers
Inconvénients :
  • Choix d'une technologie
  • Choix d'une couche de transport
  • Conception du middleware
  • Empilement des couches

Le client reprend de l'importance

Dans les applications récentes, nous allons délocaliser vers le client une partie des traitements (code javascript) :

Figure figures/bb/app-js

Avantages :

  • meilleure interactivité des applications,
  • diminution du traffic réseau,
  • utilisation des ressources locales,

Architecture orientée services (SOA)

Figure figures/bb/arch-soa

Définition d'un service logiciel (brique de base):

Figure figures/bb/service

Les services sont déployés dans des machines virtuelles et/ou des conteneurs qui exploitent un serveur bare-metal mutualisé.

Architecture orientée micro-services

Avant : Un service = un métier (achat, vente, réservation). Un service est donc un objet complexe difficile à faire évoluer.

Maintenant : Mise à place de micro-service :

  • Un service = un sous-métier, une entité
  • Avantages :
    • simplification des services,
    • augmentation du découplage,
    • conception, réalisation, déploiement facilités (agilité),
    • l'orchestration est de plus en plus importante.
  • Déploiement
    • dans des conteneurs (docker)
    • orchestrés (kubernetes)

Architecture orientée messages (ESB)

Dans les ESB (Enterprise Service Bus) un bus de messages assure l'interopérabilité entre les services.

Figure figures/bb/arch-ESB

L'ESB assure le routage, la distribution et la mise en place de standards.

On utilise des principes d'orchestration (définition de processus métiers basés sur des services métiers) (BPEL: Business Process Execution Language). Technologies : XML/XSLT/JSON/Rest/SOAP

Synthèse des architectures

Répartition des données et des traitements dans les différentes architectures :

Figure figures/bb/arch-couches

Architecture JEE

Java Enterprise Edition: J2EE 1.1 puis 1.4 puis JEE 5 puis JEE 6, JEE 7 (2013), jakarta EE 8 (2017) et JEE 9 (2020), JEE 10 (2022)

Figure figures/bb/arch-jee

JEE : ensemble de spécifications destinées à définir un environnement multi-niveaux (n-tiers) pour des applications métier.

Cours : Architecture, Spring, JDBC, JPA, Servlet/JSP, Spring MVC

JEE « outillé »

Dans les applications modernes, la plateforme JEE a besoin d'être outillée.

Figure figures/bb/jee-outils

Sprint Boot est un facilitateur qui permet de mettre en cohérence des composants d'origine variée.