Les projets d’intégration et rôle de l’ESB, dans un Système d’information

NB : cet article est le premier d’une série de présentation et de tutoriaux pour démystifier Mule ESB : http://net-progress.blogspot.com/)

De la nécessité d’un projet d’intégration dans un S.I. (Système d’information)

Il est communément connu que la majorité des S.I. (Système d’information) dans les entreprises soufrent d’un manque d’intégration et se trouvent souvent au stade d’ilots, dont les parties interconnectés soufrent du syndrome spaghetti (dite Spaghetti Oriented Architecture).

L’intégration coûte chère à l’entreprise : on parle de 70% du budget IT, ce qui laisse peu “de budget” pour les nouveaux projets et explique la longévité de certaines applications, bien qu’elles soient non adaptées.

Le S.I. (Système d’information) de toute entreprise a besoin d’une intégration entre ses applications et service, pour adresser les enjeux suivants :

• interopérabilité native et organisation efficace de la circulation de l'information entre des applications hétérogènes,
• communication fluide entre les différentes applications de l'entreprise, voire même celles des partenaires (clients, fournisseurs, sous-traitants, cotraitants, …) >

D’où le besoin de rationaliser le projet intégration entre ses applications et services d l’entreprise (dit EAI Enterprise Application intégration, à l’époque le mot service n’avait la notion se Service métier, on parle de EAI et non pas de SEAI, pour dire SOA aujourd’hui).

Un projet intégration entre ses applications et services d l’entreprise consiste :

• à mettre en place une architecture de communication entre les différentes applications, e services

• à développer des connecteurs et services (avec ou sans middleware, appelé avant outil EAI et ESB maintenant) permettant d'interfacer des applications utilisant des protocoles de communications différents,

• Au-delà de l'interopérabilité entre applications, l‘intégration doit, permettre de définir un Workflow entre applications (existantes et futures).

Rappelons que la finalité d’un projet d’intégration est de "fluidifier, simplifier et structurer" les échanges entre applications.

Le mot EAI (Enterprise Application Integration) souvent utilisé souvent remplacé par SOA (Service Orientéed Architecure), rappelons que …

• SOA est un concept
• Bus est une architecture logique
• ESB est un produit

Les types d’intégration

En complexité croissante, les différents types d’intégration qu’on rencontre sont :

· Intégration par les données :

• transmission de données avec des transformations éventuelles d’une source à une destination
• le scénario le plus classique est l’échange et le partage des données applicatives via base de données commune
• l’usage de XML (Extensible Markup Language) est particulièrement utile pour l'intégration applicative inter-entreprise,

· Intégration parles applications :

L’utilisation d’API métier pour transférer ou intégrer des flux de données

Basée sur des apples points à points ou sur des logiciels d’intégration (solution EAI plus complète), sans ou avec produits de middleware orientés messages (MOM)

· Intégration par les processus

• Orchestration d’un ensemble de tâches à effectuer par différentes applications avec ou sans intervention humaine

Un projet d’intégration peut combiner ces trois approches, mais le rêve de tout DSI (Directeur de Système d’information) est de mettre en place une approche d’intégration par les processus.

Intégration par les données :

Lorsque les applications n’ont pas la possibilité de lire et de traiter les données provenant d’une autre application, un ESB (Mule par exemple) résout le problème en fournissant un framework de messagerie qui lit, transforme, et envoie les données comme des messages entre les applications.

(source mule.org)

L’ESB en tant qu’outil d’intégration par les données propose :

• · des services de transformation de données,

• · la mise à disposition des données vers une ou plusieurs cibles

• · la sécurisation et la fiabilisation des échanges,

• · l’utilisation de connecteurs standards d'accès aux sources de données,

Cette approche n’a de sens que dans une phase d’urgence (certains vont se dire, c’est toujours le cas).

Notons que le principal point négatif de cette approche est que la couche métier est court-circuité et les règles de gestion (règles métiers) ne sont pas vérifiées dans les transferts ou bien doivent être réécrites dans le connecteurs .

Exemple : base de données avec données stockées incluant des règles de gestion (appartenance à un type pu une catégorie…).

L’intégration au niveau données ne tient pas compte de cette couche et se connecte directement à la base de donnée avec le risque d’atteinte d’intégrité des données (d’un point de vue métier).

Intégration par les API :

L’intégration au niveau des applications consiste à utiliser les API métier pour faire communiquer deux applications une dite consommateur et l’autre fournisseur.

Il est important que l’application fournisseur expose ses fonctionnalités sous forme d’une API. L’idéal serait que cette API soit définit d’un point de vue métier et que l’exposition soit basé sur des standards

· L’intégration au niveau des applications est un bon départ en vue d’une exposition des API métier sous forme de Web Services

· Mais l’intégration de la couche métier n'est pas toujours aisée :

• La majorité des applications ne fournissent pas des API métier, puisqu’elle ont été pensé en terme de silos ou monoblocs.

• o les applications anciennes des environnements centralisés sont souvent des blocs monolithiques sans notion de couche, leurs seules interfaces sont constituées de grilles d'écran,

• o l’exposition risque de déclencher un important travail de restructuration, en préalable à toute intégration d’applications,

· La couche de présentation gère l’interface utilisateur, cette couche peut constituer un point d'intégration potentiel (intégration au niveau «écran») en se basant sur les Mashup.

· Dans certains cas où une API métier est disponible, il n’est pas toujours possible de l’exploiter directement tel quel :

• o protocoles de communication propriétaires, nécessite la création d'une surcouche d'adaptation, c’est le principe de Proxy ou d’adapter (utilisé dans SOA de façade)

· Stabilité des API applicatifs dans le temps: approche Contract-First

• o L’API est le point d'entrée de l'intégration,

• o une modification interne dans une application ne doit, théoriquement pas, entraîner une modification de l’API métier,

Intégration par les processus

Intégrations au niveau données et applications focalisées sur aspects techniques de l'intégration,

Intégration au niveau des processus métier prône une approche fonctionnelle de l’intégration d’applications,

Ce sont les processus métier qui pilotent l’intégration.

Le Business Process Integration (dit BPI) , est le fait de concevoir des processus métier et de les relier aisément aux applications sous-jacentes,

Les produits de BPI utilise se base sur un moteur d'orchestration (moteur BPM) connaissant les étapes et les données du processus.

Le moteur BPM se charge

• · de l'aiguillage des flux de données dans le cadre des processus métier,

• · du suivi de l'état d'avancement de chaque processus,

• · d’activer des alertes en cas de déviation du fonctionnement

Le moteur BPM doit proposer :

• · un support natif de certains processus classiques (briques élémentaires prédéfinies et configurables),

• · un formalisme claire (standard de préférence, privilégier le BPMN pour les nouveaux projets) pour définir le processus métier sous forme de combinaison de plusieurs briques métier,

• · un outil de modélisation graphique,

· sur cette base, le moteur BPM se charge :

• o de générer automatiquement le code nécessaire aux interactions entre les actions élémentaires,

• o et de donner les instructions au moteur pour exécuter les processus définis.

Un ESB au service de l’intégration

En conclusion, l’ESB peut jour un rôle important dans un projet d’intégration.

Il n’est pas indispensable

Il ne doit pas être forcément cher à acquérir.

C’est une commodité.

Un ESB doit permettre de mettre en ouvre ces 3 types d’intégration, simplement, par configuration les fonctions suivantes :

· Routage

· Transformation de Message

· Enrichissement de Message

· Transformation entre Protocole de Transport

· Mapping entre services

· Traitement des Messages

· Chorégraphie entre processus

· Orchestration entre service pour créer un Processus

· Gestion de Transaction

· Sécurité

dans ce cadre Mule ESB a un rôle à jouer dans l’intégration de votre SI, notamment pour les POC et les projets Pilotes

mais ceci est un autre sujet

---------------------

autres sujets :

Fonctionnalités des ESB et offre open source : le marché n’est pas encore consolidé