RENNES, 35000
+33644312205
contactATdmi-tech.com

L’architecture d’un ESB – Enterprise Service Bus

Ingénierie & Services

Architecture d'un ESB

Quel est le problème que l’on rencontre lorsqu’on développe différentes applications avec différents langages, et surtout comment ces applications dites hétérogènes communiquent pour offrir du service.

Surtout comment les faire communiquer sans pour autant exploser le nombre d’interconnexions ?

Pendant longtemps dans les entreprises, les applications étaient réalisées avec des technologies différentes. C’est même encore le cas aujourd’hui d’ailleurs.

La communication était effectuée par des programmes de type batch,

Les applications étaient développées et déployées de façon isolée,

Ces applications au fil du temps se sont accrues sans une vraie solution architecturale,

Elles constituent aujourd’hui ce qu’on appelle des silos applicatifs communément appelés « plat de spaghetti »

Communication entre applications hétérogènes

Pour résoudre ce problème, plusieurs solutions:

1 – Modèle à couche

Architecture 3 tiers
  • Modèle d’architecture “3-tier, n-tiers
  • Langages de haut niveau
  • Programmation orientée objet
  • Héritage
  • Encapsulation

2- Modèle des architectures SOA

  • Modèle d’architecture de médiation
  • Met en œuvre des composants logiciels.Avantages SOA
  • Réutilisation
  • Réduction des coûts Facilité d’intégration
  • Maitrise de l’accroissement des applications
  • Interopérabilité

3 -Mise en place d’un ESB

Un ESB (Enterprise Service Bus) par définition est considéré comme un bus de communication de messages qui permet à un consommateur (par exemple : une application du SI) d’accéder à un service. Le service peut être déployé dans le même SI, ou à l’extérieur du SI.

Un ESB doit permettre aux applications ou aux services composites d’accéder aux services disponibles de façon standardisée, flexible et transparente. Les consommateurs des services doivent être indépendants du protocole de communication, de la technologie de déploiement, et de la localisation de service. Le mot d’ordre lorsqu’on parle des ESB est service. Tout doit être pensé en terme de service.

La mise en place d’un ESB doit par exemple permettre d’exposer tous les services avec la même technologie pour simplifier la réalisation du processus, autrement il devra intégrer des outils nécessaires pour la conversion des données échangées au format supporté par les applications participantes. Il peut aussi permettre de créer de nouveaux services par agrégation de ceux existants.

L’architecture d’un ESB est composée des éléments suivants :

  • Le bus de message : assure le transport et la sécurisation des messages entre les différents serveurs impliqués dans le déploiement des clients et des services.
  • Les adaptateurs de protocole : permettent à l’ESB de supporter divers protocoles de communication dans son dialogue.
  • Le moteur de routage : assure l’aiguillage des messages vers leurs destinataires selon des règles. Pour router les messages, le bus prend en compte les informations du contrat de service contenu dans le WSDL, l’entête et/ou le corps du message.
  • Le moteur de transformation : assure la conversion syntaxique du format de message entre deux applications hétérogènes.

Un ESB va fournir les fonctionnalités comme le filtrage, la transformation et l’acheminement des messages en masquant toute fois la logique d’intégration.

Master Data Management (MDM) comme référentiel de données

Le Master Data Management ou encore la gestion des données de référence est l’ensemble des méthodes, outils et processus qui permettent de définir, stocker, maintenir, distribuer les données au sein d’un système d’information. Les données référentiels doivent rester identiques fiables, toujours à jours et utilisables sans risque aucun.

Le MDM gère les tables métiers de références mises à jour en fonction d’une politique de réplication paramétrable, et visibles au travers des services. Il s’agit de collecter et de concentrer toutes les données relatives à un objet métier (client, fournisseur, produits…) ainsi que leurs métadonnées de structuration (clé d’accès, version…). Le MDM peut aussi servir pour la traçabilité qui doit être prise en compte dans les exigences de sécurité.

#Intégration #ESB #Transformation #TIBCO


DMI TECHNOLOGY SERVICES est spécialisé dans l’intégration des applications d’entreprise + 10 ans d’expérience. Si vous avez besoin d’une expertise pointue sur TIBCO ? Cliquez sur le lien suivant :👉🏼https://buff.ly/460qZBo

Retrouvez tous nos tutoriels sur 👉🏼https://buff.ly/3EU6N89

Abonnez-vous sur LinkedIn 👉🏼https://buff.ly/3roGJPv

Suivez nous sur Facebook👉🏼https://lnkd.in/eDUqPrEE

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *