EAI Intégration Des Applications D'entreprise (EAI) [PDF]

Zitiervorschau

Module 307

Intégration de logiciels

Intégration des applications d'entreprise (EAI)

Introduction Aspects technologiques Web services Bibliographie Webographie

Gérard-Michel Cochard [email protected]

Intégration des applications d'entreprise (EAI) Introduction

définition le modèle de base EAI

Définition L'EAI (Enterprise Application Integration) signifie en français Integration d'Applications d'Entreprise. C'est une notion ancienne mais toujours d'actualité. En effet, le besoin de faire communiquer des applications développées à des moments différents, dans des technologies différentes et de manière indépendante est réel si l'on veut au sein d'une entreprise aboutir à un système d'information global et performant. L'ERP est une première réponse à cette problématique. Elle ne couvre cependant pas tous les besoins de l'entreprise et nécessite une installation logicielle (et souvent matérielle) nouvelle avec tous les problèmes d'organisation et de formation qu'elle implique. En résumé, ● ●

les ERP remplacent une partie du système d'information seulement, mais pas la totalité des applications métiers les ERP sont conçus pour communiquer parfaitement entre eux, mais pas avec d'autres d'autres applications.

L'EAI se veut plus large et tient compte au mieux de l'existant. Le problème se pose souvent dans les termes suivants : étant donné un ensemble d'applications "communicantes" comment faire pour intégrer une nouvelle (qui peut d'ailleurs être ancienne) application ? Bien entendu, une entreprise ne travaille pas en vase clos. Elle doit communiquer de manière périodique avec d'autres entreprises partenaires (fournisseurs, distributeurs, prestataires extérieurs,....). Il faut donc envisager également une intégration d'applications appartenant à des entreprises différentes. Cette situation dépasse le cadre de l'EAI (ou le complète), car nous entrons ici dans le domaine du B2B (Business To Business) ou IAI (Inter-Enterprise Application Integration) où des solutions sont d'ailleurs proposées (ebXML, RosttaNet, ...). En fait, de nos jours, Internet et les technologies associées (dont principalement XML) joue un rôle majeur et a donné naissance à bon nombre de développements de complexité croissante depuis le B2C (Business To Customer, orienté vers la clientèle comme le e-Commerce) jusqu'au B2B (Business To Business) en passant par les Services Web et l'EAI. Ces développements, fatalement, se recoupent et une classification n'est pas simple (la mode des sigles n'arrange pas les choses).

(d'après D. Girard, T. Crusson, XML pour l'entreprise, http://www.application-servers.com/livresblancs/xml/ )

Nous reprenons la définition de B. Manouvrier (EAI, Hermès) : "L'EAI est un ensemble de méthodes, d'outils et de services qui concourent à faire communiquer des applications hétérogènes dans le cadre de l'entreprise traditionnelle, répartie ou étendue." On désigne aussi quelquefois l'EAI par le sigle AtoA (Application To Application). Considérons une entreprise avec toutes ses applications métiers. On peut envisager de relier toutes ces applications pour qu'elles communiquent par des interfaces spécifiques. Si il y a n applications, on sera donc conduit à réaliser n(n-1)/2 interfaces ; donc pour 100 applications, 4950 interfaces ! Il est clair que ce modèle "spaghetti" n'est pas l'idéal et qu'il faut se tourner plutôt vers des solutions de "commutation" :

Un exemple classique peut être donné par la gestion commerciale d'une entreprise où trois applications sont amenées à communiquer : la gestion des commandes, la gestion des clients, la gestion de la facturation, chacune de ces gestions correspondant à une application informatique :

En se basant sur l'exemple précédent, on peut distinguer 4 fonctions de l'EAI, en supposant que les systèmes informatiques de l'entreprise sont reliés par un Intranet : ●

●

●

●

échange de données : il s'agit de prendre des données dans une application et de les intégrer dans une autre. Puisque en général, les systèmes informatique sont hétérogènes, il faut choisir des technologies comme les services Web. conversion de données : elle est souvent nécessaire pour que les applications communiquent. Cette conversion peut, par exemple, être effectuée par XSLT. routage de données : transmettre des informations vers la bonne application destinataire. SOAP peut être un bon candidat pour cette opération. gérer le processus global de bout en bout. Ceci implique la définition de processus métiers et on peut utiliser BPML.

Comme on le voit, on peut être conduit à assembler plusieurs technologies pour atteindre le but recherché.

Le modèle de base EAI Dans sa version d'origine, une plateforme EAI est construite sur 4 couches : ●

le transport des données

●

l'extraction d'informations et l'insertion d'informations entre applications

●

les composants

●

le moteur d'intégration

Quand une information est extraite, elle est recueillie par un connecteur applicatif puis "emballée" dans un message placé et conservé dans une file d'attente. Le moteur d'intégration, activé par l'arrivée d'un message, traduit les données pour les acheminer vers l'application destinataire. Les composants peuvent intervenir pour apporter le traitement métier (vérification des règles, traitement particulier,...). Puis les données sont transmises au connecteur, adapté à l'application destinataire, qui effectue la mise à jour adéquate. transport

Cette couche correspond à la messagerie inter-applications : des messages sont stockés dans des files d'attente en attente de traitement. Il s'agit du Message Oriented Middleware (MOM). Le MOM fonctionne en relation avec un outil d'administration des message (Message Broker) qui joue le rôle de moteur d'intégration. Il s'agit d'un middleware asynchrone car après la constitution d'un message, l'application source peut continuer à fonctionner et la disponibilité de l'application cible n'a pas besoin d'être garantie. Un MOM apporte les services suivants : ●

●

la gestion des priorités : on peut traiter les messages dans un ordre déterminé la gestion des événements : l'arrivée d'un message ou sa remise peuvent provoquer des événements (création d'autres messages par exemple)

●

la sécurité des échanges : un message ne peut se perdre et n'est traité qu'une seule fois

●

la sécurité d'accès : on peut restreindre l'accès à certaines files d'attente

Il existe aussi des middlewares synchrones comme ORB (Object Request Brokers) ou les protocoles standards de l'Internet (HTTP, TCP/IP). Les ORB disponibles sont Corba, DCOM, EJB. HTTP, quant à lui, est largement favorisé par l'utilisation d'Internet. On le trouvera donc plutôt dans des relations entre applications d'entreprises différentes (B2B). données Les connecteurs ou adaptateurs applicatifs extraient les données en fonction des besoins (déclenchement par l'arrivée d'un message) et les dirigent vers l'application destinataire. De nos jours, les connecteurs sont de type "intelligents" : ils savent retrouver les bonnes données en se référant aux modèles des applications (tables dans les SGBD) ; ils peuvent aussi s'adapter à la modification des bases de données. composants Les composants complètent le moteur d'intégration qui n'est que "mécanique" en apportant une vision métier du traitement. Par exemple, lors d'une commande, le composant métier correspondant va regarder dans la base client si le client nécessite une remise particulière au vu de sa situation. moteur d'intégration Les rôles du moteur d'intégration sont de transformer les données et de les diriger vers les applications destinataires. La transformation de données est compréhensible car deux applications peuvent très bien utiliser les mêmes données mais dans des formats et sous des noms différents ; pire encore, des données correspondantes de deux applications communicantes peuvent ne pas avoir la même sémantique. Le routage peut être simple : transfert d'une donnée provenant d'une application vers une autre application après transformation ; il peut être aussi plus complexe : agrégation de données provenant de plusieurs applications, création d'un nouveau message et envoi à plusieurs applications. Comme évoqué précédemment, sur ce modèle de base viennent s'ajouter deux catégories de fonctionnalités technologiques : ●

●

l'infrastructure d'échange B2B qui doit permettre aux entreprises de communiquer entre partenaires et qui complète l'EAI d'une entreprise particulière. le moteur de workflow qui modélise et met en oeuvre la gestion d'un processus métier.

Intégration des applications d'entreprise (EAI) Aspects technologiques

Modèles de communication entre applications Message Brokers Les processus métier

Modèles de communication entre applications Deux principes de base permettent de faire une classification initiale entre les différentes possibilités de communication entre applications : le mode "orienté connexion" et le mode "sans connexion".

Modes orientés connexion Il implique qu'une "session" est établie entre les deux entités communicantes et que ces entités sont disponibles pendant la durée de la session. mode conversationnel il est analogue à la communication téléphonique. L'une des entités prend l'initiative d'établir la connexion. Un dialogue, sous forme d'envoi et de réception d'information sous forme de blocs de données ou de messages s'effectue entre les deux entités. L'une des deux entités prend l'initiative de rompre la connexion. mode question/réponse Synchrone comme le mode précédent, le mode implique la disponibilité des deux entités communicantes. Une requête est envoyée d'une entité A vers une entité B. Celle-ci exécute des processus pour obtenir une réponse qu'elle transmet à l'entité A. Pendant le travail de l'entité B, l'entité A se met en attente active ou est bloquée. RPC (Remote Process Control) est caractéristique de ce mode. Modes sans connexion Les modes sans connexion sont basés sur l'échange de messages standardisés. Message passing Ce mode correspond à un simple envoi de message. une entité A désirant communiquer avec une entité B lui envoie un message de requête, puis continue de fonctionner (pas de blocage). L'entité B, lorsqu'elle aura pris le temps de formuler une réponse, renvoie celle-ci à l'entité B. Message queuing Le système utilise un intermédiaire chargé de recevoir et de stocker les messages. Les destinataires peuvent être sollicités par le système de gestion des messages ou bien aller voir directement s'ils ont reçu du "courrier". Les messages sont placés à l'arrivée dans une file d'attente ; ils sont ensuite traités pour identifier le destinataire. Publish-and-subscribe L'échange de messages est beaucoup plus organisé que le précédent. Les destinataires disposent (subscribe) de boîtes aux lettres spécifiques et un message envoyé (publish) peut être destiné à plusieurs destinataires. Ces deux derniers modes sont prépondérants dans les systèmes d'EAI.

Message Brokers Un certain nombre d'architectures EAI repose sur l'utilisation des Message Brokers qui sont des composants élémentaires qui peuvent être utilisés par le MOM. Les Message Brokers sont des intermédiaires (on les qualifie quelquefois de Middleware pour le Middleware) mettant en relation des applications source et destination via un système de messages. De fait, l'architecture correspondante est assez analogue à celle de la commutation de réseaux. On dit d'ailleurs que ces architectures sont des hub-and-spoke puisqu'elles permettent via un "hub" de mettre en communication des applications.

Une application envoie (publish) des messages sur le hub. Ces messages vont sur des files d'attente où elles sont récupérées par les message brokers. Sur d'autres files d'attente, sont abonnées des applications en attente de messages (subscribe). Elles récupèrent les messages publiés et placés sur ces files d'attente par les message brokers. En général les files d'attente de "souscription" correspondent à des processus spécifiques. On notera que le mise en correspondance de applications peut aussi bien être un-vers-une comme un-vers-plusieurs". On peut généraliser la méthode pour assurer une montée en charge et la tolérance aux inévitables pannes. L'emploi de plusieurs "hub" est donc possible. toutefois, elle peut augmenter la complexité au niveau du routage.

Les processus métier Prenons un exemple cité par "EAI : de l'intégration au e-business" (voir Webographie). On suppose que la communication entre applications est réalisée par des message brokers. Un client commande un produit. cette information est transmise à un composant métier vérifiant l'état de stocks. Supposons que cet état permet le traitement de la commande mais nécessite un réapprovisionnement de stocks. Cette information (cruciale) est transmise via le moteur d'intégration et un message à l'application "approvisionnement". Celle-ci génère une commande fournisseur. Le responsable des achats est prévenu automatiquement par e-mail et doit sélectionner un fournisseur. L'attente de la décision du responsable d'achats interrompt le processus métier. En général, après un délai suffisant (24h par exemple), si le responsable des achats n'a pas pris de décision, une décision automatique est prise (ce qui nécessite des informations suffisantes sur les fournisseurs). Il est clair que ce ne sont pas les message brokers qui gèrent ce processus lié aux habitudes de l'entreprise : interruption de processus, reprise sur événement, notification vers le fournisseur choisi,... C'est un moteur de workflow qui doit prendre en compte cette succession d'événements et de procédures. Ainsi les aspects techniques (architecture du système d'information) net les aspects métier (analyse métier) doivent être séparés. Le moteur de worflow doit automatiser autant que possible la transmission d'informations d'utilisateur à utilisateur : ● ● ●

gestion d'un processus à vie "longue" incorporant l'intervention d'utilisateurs particuliers conservation de l'état du processus dans un espace de stockage gestion du grand nombre d'opérations

On observera en outre que le moteur de workflow modélise fortement et donc structure le fonctionnement de l'entreprise. En revanche, l'automatisation de processus concerne ● ● ● ● ●

le transport et le contrôle d'informations à durée limitée la mise en mémoire vive de l'état d'un processus (au sens informatique) un nombre raisonnable de messages par seconde une rapidité d'exécution, au sens de la transmission par les technologies Web un contrôle conduisant à des journaux d'opérations permettant une reprise en cas d'incidents

Le moteur de worflow doit prendre en compte les aspects suivants :

●

●

●

aiguillage conditionnel : envisager les différentes prises de décisions envisageables dans un fonctionnement d'entreprise. Cet aiguillage reflète une personnalisation du fonctionnement d'une entreprise donnée qui n'est pas transposable globalement vers une autre entreprise. cas spéciaux : un événement doit être traité, soit "manuellement" par recours à un utilisateur fléché, soit automatiquement par des procédures d'urgence. synchronisation : des processus composants peuvent être coordonnés pour donner naissance à un processus unique. Il y a donc matière à gérer cette synchronisation ce qui se traduit généralement par l'attente de finition d'un processus composant ou celle d'une intervention "manuelle".

Ainsi le système d'information de l'entreprise constitue une couche de base pour les processus métiers qui vont le piloter. Pour les moteurs de workflow des travaux orchestrés par le Workflow Management Coalition (WfMC) tentent d'aboutir à une standardisation : terminologie, spécifications d'interopérabilité, langage de requêtes, réponses aux requêtes, .... Une autre organisation, Business Process Management Initiation (BPMI) a lancé en 2001 des travaux concurrents sous la forme du langage BPML (Business Process Modeling Language). Un troisième groupe, animé par Microsoft et IMBM notamment, a lancé un troisième produit issu du précédent, BPEL (Business Process Execution Language). Ce language est maintenant maintenu par l'organisme de standardisation OASIS. Par ailleurs, UML propose, via l'OMG, une initiative complémentaire appelée BPDM (Business Process Definition Metamodel).

Intégration des applications d'entreprise (EAI) Web Services

Introduction WSDL SOAP UDDI

Introduction Les services Web (ou Web Services) sont des composants logiciels basés sur XML et dédiés à la gestion des processus métier : ● ● ●

Web Service Description Language (WDSL) décrit les services Web offerts Simple Object Access Protocol (SOAP) est dédié au transport des données Universal Description, Discovery ans Integration (UDDI) permet de référencer les services Web par les utilisateurs

Les services Web, du fait de leur fondation sur XML et de l'utilisation des technologies du Web, constituent des solutions modernes à la communication entre applications intra ou inter-entreprise.

WDSL Le concept n'est pas nouveau. Dans la programmation distribuée, Corba et DCOM utilisaient déjà un langage de définition d'interfaces de communication : IDL. WDSL en est l'équivalent. Il y en a d'autres : SDL, puis SCL (Microsoft), NASSL

(IBM). Un document WDSL est un document XML comportant, dans sa forme usuelle, les éléments suivants : ●

● ●

● ●

●

●

qui englobe la définition d'un service et qui contient les éléments génériques , , et . décrit les opérations offertes par le service et les paramètres nécessaires complète l'élément en décrivant un ensemble d'opérations définies par les éléments

correspond à la définition d'un couple de messages entrée et sortie associe