Intgration de logiciels

Module 307

Intgration des applications d'entreprise (EAI)

Introduction Aspects technologiques Web services Bibliographie Webographie

Grard-Michel Cochard cochard@u-picardie.fr

Intgration des applications d'entreprise (EAI)

Introduction

dfinition le modle de base EAI

Dfinition
L'EAI (Enterprise Application Integration) signifie en franais Integration d'Applications d'Entreprise. C'est une notion ancienne mais toujours d'actualit. En effet, le besoin de faire communiquer des applications dveloppes des moments diffrents, dans des technologies diffrentes et de manire indpendante est rel si l'on veut au sein d'une entreprise aboutir un systme d'information global et performant. L'ERP est une premire rponse cette problmatique. Elle ne couvre cependant pas tous les besoins de l'entreprise et ncessite une installation logicielle (et souvent matrielle) nouvelle avec tous les problmes d'organisation et de formation qu'elle implique. En rsum,
G G

les ERP remplacent une partie du systme d'information seulement, mais pas la totalit des applications mtiers les ERP sont conus 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 problme se pose souvent dans les termes suivants : tant donn un ensemble d'applications "communicantes" comment faire pour intgrer une nouvelle (qui peut d'ailleurs tre ancienne) application ? Bien entendu, une entreprise ne travaille pas en vase clos. Elle doit communiquer de manire priodique avec d'autres entreprises partenaires (fournisseurs, distributeurs, prestataires extrieurs,....). Il faut donc envisager galement une intgration d'applications appartenant des entreprises diffrentes. Cette situation dpasse le cadre de l'EAI (ou le complte), car nous entrons ici dans le domaine du B2B (Business To Business) ou IAI (Inter-Enterprise Application Integration) o des solutions sont d'ailleurs proposes (ebXML, RosttaNet, ...). En fait, de nos jours, Internet et les technologies associes (dont principalement XML) joue un rle majeur et a donn naissance bon nombre de dveloppements de complexit croissante depuis le B2C (Business To Customer, orient vers la clientle comme le e-Commerce) jusqu'au B2B (Business To Business) en passant par les Services Web et l'EAI. Ces dveloppements, fatalement, se recoupent et une classification n'est pas simple (la mode des sigles n'arrange pas les choses).

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

Nous reprenons la dfinition de B. Manouvrier (EAI, Herms) : "L'EAI est un ensemble de mthodes, d'outils et de services qui concourent faire communiquer des applications htrognes dans le cadre de l'entreprise traditionnelle, rpartie ou tendue." On dsigne aussi quelquefois l'EAI par le sigle AtoA (Application To Application). Considrons une entreprise avec toutes ses applications mtiers. On peut envisager de relier toutes ces applications pour qu'elles communiquent par des interfaces spcifiques. Si il y a n applications, on sera donc conduit raliser n(n-1)/2 interfaces ; donc pour 100 applications, 4950 interfaces ! Il est clair que ce modle "spaghetti" n'est pas l'idal et qu'il faut se tourner plutt vers des solutions de "commutation" :

Un exemple classique peut tre donn par la gestion commerciale d'une entreprise o trois applications sont amenes 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 prcdent, on peut distinguer 4 fonctions de l'EAI, en supposant que les systmes informatiques de l'entreprise sont relis par un Intranet :
G

change de donnes : il s'agit de prendre des donnes dans une application et de les intgrer dans une autre. Puisque en gnral, les systmes informatique sont htrognes, il faut choisir des technologies comme les services Web. conversion de donnes : elle est souvent ncessaire pour que les applications communiquent. Cette conversion peut, par exemple, tre effectue par XSLT. routage de donnes : transmettre des informations vers la bonne application destinataire. SOAP peut tre un bon candidat pour cette opration. grer le processus global de bout en bout. Ceci implique la dfinition de processus mtiers et on peut utiliser BPML.

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

Le modle de base EAI

Dans sa version d'origine, une plateforme EAI est construite sur 4 couches :
G

le transport des donnes l'extraction d'informations et l'insertion d'informations entre applications les composants le moteur d'intgration

Quand une information est extraite, elle est recueillie par un connecteur applicatif puis "emballe" dans un message plac et conserv dans une file d'attente. Le moteur d'intgration, activ par l'arrive d'un message, traduit les donnes pour les acheminer vers l'application destinataire. Les composants peuvent intervenir pour apporter le traitement mtier (vrification des rgles, traitement particulier,...). Puis les donnes sont transmises au connecteur, adapt l'application destinataire, qui effectue la mise jour adquate. transport

Cette couche correspond la messagerie inter-applications : des messages sont stocks 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 rle de moteur d'intgration. Il s'agit d'un middleware asynchrone car aprs 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 :
G

la gestion des priorits : on peut traiter les messages dans un ordre dtermin la gestion des vnements : l'arrive d'un message ou sa remise peuvent provoquer des vnements (cration d'autres messages par exemple) la scurit des changes : un message ne peut se perdre et n'est trait qu'une seule fois la scurit d'accs : on peut restreindre l'accs 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 plutt dans des relations entre applications d'entreprises diffrentes (B2B). donnes Les connecteurs ou adaptateurs applicatifs extraient les donnes en fonction des besoins (dclenchement par l'arrive d'un message) et les dirigent vers l'application destinataire. De nos jours, les connecteurs sont de type "intelligents" : ils savent retrouver les bonnes donnes en se rfrant aux modles des applications (tables dans les SGBD) ; ils peuvent aussi s'adapter la modification des bases de donnes. composants Les composants compltent le moteur d'intgration qui n'est que "mcanique" en apportant une vision mtier du traitement. Par exemple, lors d'une commande, le composant mtier correspondant va regarder dans la base client si le client ncessite une remise particulire au vu de sa situation. moteur d'intgration Les rles du moteur d'intgration sont de transformer les donnes et de les diriger vers les applications destinataires. La transformation de donnes est comprhensible car deux applications peuvent trs bien utiliser les mmes donnes mais dans des formats et sous des noms diffrents ; pire encore, des donnes correspondantes de deux applications communicantes peuvent ne pas avoir la mme smantique. Le routage peut tre simple : transfert d'une donne provenant d'une application vers une autre application aprs transformation ; il peut tre aussi plus complexe : agrgation de donnes provenant de plusieurs applications, cration d'un nouveau message et envoi plusieurs applications. Comme voqu prcdemment, sur ce modle de base viennent s'ajouter deux catgories de fonctionnalits technologiques :
G

l'infrastructure d'change B2B qui doit permettre aux entreprises de communiquer entre partenaires et qui complte l'EAI d'une entreprise particulire. le moteur de workflow qui modlise et met en oeuvre la gestion d'un processus mtier.

Intgration des applications d'entreprise (EAI)

Aspects technologiques

Modles de communication entre applications Message Brokers Les processus mtier

Modles de communication entre applications

Deux principes de base permettent de faire une classification initiale entre les diffrentes possibilits de communication entre applications : le mode "orient connexion" et le mode "sans connexion".

Modes orients connexion

Il implique qu'une "session" est tablie entre les deux entits communicantes et que ces entits sont disponibles pendant la dure de la session. mode conversationnel il est analogue la communication tlphonique. L'une des entits prend l'initiative d'tablir la connexion. Un dialogue, sous forme d'envoi et de rception d'information sous forme de blocs de donnes ou de messages s'effectue entre les deux entits. L'une des deux entits prend l'initiative de rompre la connexion. mode question/rponse Synchrone comme le mode prcdent, le mode implique la disponibilit des deux entits communicantes. Une requte est envoye d'une entit A vers une entit B. Celle-ci excute des processus pour obtenir une rponse qu'elle transmet l'entit A. Pendant le travail de l'entit B, l'entit A se met en attente active ou est bloque. RPC (Remote Process Control) est caractristique de ce mode. Modes sans connexion Les modes sans connexion sont bass sur l'change de messages standardiss. Message passing Ce mode correspond un simple envoi de message. une entit A dsirant communiquer avec une entit B lui envoie un message de requte, puis continue de fonctionner (pas de blocage). L'entit B, lorsqu'elle aura pris le temps de formuler une rponse, renvoie celle-ci l'entit B. Message queuing Le systme utilise un intermdiaire charg de recevoir et de stocker les messages. Les destinataires peuvent tre sollicits par le systme de gestion des messages ou bien aller voir directement s'ils ont reu du "courrier". Les messages sont placs l'arrive dans une file d'attente ; ils sont ensuite traits pour identifier le destinataire. Publish-and-subscribe L'change de messages est beaucoup plus organis que le prcdent. Les destinataires disposent (subscribe) de botes aux lettres spcifiques et un message envoy (publish) peut tre destin plusieurs destinataires. Ces deux derniers modes sont prpondrants dans les systmes d'EAI.

Message Brokers
Un certain nombre d'architectures EAI repose sur l'utilisation des Message Brokers qui sont des composants lmentaires qui peuvent tre utiliss par le MOM. Les Message Brokers sont des intermdiaires (on les qualifie quelquefois de Middleware pour le Middleware) mettant en relation des applications source et destination via un systme de messages. De fait, l'architecture correspondante est assez analogue celle de la commutation de rseaux. 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 rcupres par les message brokers. Sur d'autres files d'attente, sont abonnes des applications en attente de messages (subscribe). Elles rcuprent les messages publis et placs sur ces files d'attente par les message brokers. En gnral les files d'attente de "souscription" correspondent des processus spcifiques. On notera que le mise en correspondance de applications peut aussi bien tre un-vers-une comme un-vers-plusieurs". On peut gnraliser la mthode pour assurer une monte en charge et la tolrance aux invitables pannes. L'emploi de plusieurs "hub" est donc possible. toutefois, elle peut augmenter la complexit au niveau du routage.

Les processus mtier

Prenons un exemple cit par "EAI : de l'intgration au e-business" (voir Webographie). On suppose que la communication entre applications est ralise par des message brokers. Un client commande un produit. cette information est transmise un composant mtier vrifiant l'tat de stocks. Supposons que cet tat permet le traitement de la commande mais ncessite un rapprovisionnement de stocks. Cette information (cruciale) est transmise via le moteur d'intgration et un message l'application "approvisionnement". Celle-ci gnre une commande fournisseur. Le responsable des achats est prvenu automatiquement par e-mail et doit slectionner un fournisseur. L'attente de la dcision du responsable d'achats interrompt le processus mtier. En gnral, aprs un dlai suffisant (24h par exemple), si le responsable des achats n'a pas pris de dcision, une dcision automatique est prise (ce qui ncessite des informations suffisantes sur les fournisseurs). Il est clair que ce ne sont pas les message brokers qui grent ce processus li aux habitudes de l'entreprise : interruption de processus, reprise sur vnement, notification vers le fournisseur choisi,... C'est un moteur de workflow qui doit prendre en compte cette succession d'vnements et de procdures. Ainsi les aspects techniques (architecture du systme d'information) net les aspects mtier (analyse mtier) doivent tre spars. Le moteur de worflow doit automatiser autant que possible la transmission d'informations d'utilisateur utilisateur :
G G G

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'oprations

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

le transport et le contrle d'informations dure limite la mise en mmoire vive de l'tat d'un processus (au sens informatique) un nombre raisonnable de messages par seconde une rapidit d'excution, au sens de la transmission par les technologies Web un contrle conduisant des journaux d'oprations permettant une reprise en cas d'incidents

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

aiguillage conditionnel : envisager les diffrentes prises de dcisions envisageables dans un fonctionnement d'entreprise. Cet aiguillage reflte une personnalisation du fonctionnement d'une entreprise donne qui n'est pas transposable globalement vers une autre entreprise. cas spciaux : un vnement doit tre trait, soit "manuellement" par recours un utilisateur flch, soit automatiquement par des procdures d'urgence. synchronisation : des processus composants peuvent tre coordonns pour donner naissance un processus unique. Il y a donc matire grer cette synchronisation ce qui se traduit gnralement par l'attente de finition d'un processus composant ou celle d'une intervention "manuelle".

Ainsi le systme d'information de l'entreprise constitue une couche de base pour les processus mtiers qui vont le piloter. Pour les moteurs de workflow des travaux orchestrs par le Workflow Management Coalition (WfMC) tentent d'aboutir une standardisation : terminologie, spcifications d'interoprabilit, langage de requtes, rponses aux requtes, .... 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 troisime groupe, anim par Microsoft et IMBM notamment, a lanc un troisime produit issu du prcdent, 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 complmentaire appele BPDM (Business Process Definition Metamodel).

Intgration des applications d'entreprise (EAI)

Web Services

Introduction WSDL SOAP UDDI

Introduction
Les services Web (ou Web Services) sont des composants logiciels bass sur XML et ddis la gestion des processus mtier :
G G G

Web Service Description Language (WDSL) dcrit les services Web offerts Simple Object Access Protocol (SOAP) est ddi au transport des donnes Universal Description, Discovery ans Integration (UDDI) permet de rfrencer 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 distribue, Corba et DCOM utilisaient dj un langage de dfinition 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 lments suivants :
G

G G

G G

<definition> qui englobe la dfinition d'un service et qui contient les lments gnriques <message>, <portType>, <binding> et <service>. <message> dcrit les oprations offertes par le service et les paramtres ncessaires <portType> complte l'lment <message> en dcrivant un ensemble d'oprations dfinies par les lments <operation> <operation> correspond la dfinition d'un couple de messages entre et sortie <binding> associe <portType un protocole particulier (SOAP ou Corba ou DCOM), mais gnralement c'est SOAP qui est utilis. <service> donne des informations complmentaires sur le service offert pour y accder. Dan,s ce but il comprend des lments <port> <port> est l'association d'un <binding> un URI.

Imaginons un service dfini par une classe java consistant en l'acquittement d'un message (opration) : public class Ack{ public String echo(String expression){ return "bien reu, "+blabla ; } }

On peut modliser le service par une classe UML :

La description du service par WDSL sera la suivante : <definition xmlns:xsd="http://www.w3.org/1999/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"> <message name="AckInput"> <part name="blabla" type="xsd:string"/> </message> <message name="AckOutput"> <part name="blabla" type="xsd:string"/> </message> <message name="AckFault"> <part name="erreurMessage" type="xsd:string"/> </message <portType name="AckPortType"> <operation name="Ack"> <input message="AckInput"/> <output message="AckOutput"/> <fault message="AckFault"/> </operation> </portType> <binding name="AckSoapBinding" type="tns:AckPortType"> <soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"> <operation name="Ack"> <soap:operation soapAction="urn:ServiceAck">

<input> <soap:body use="encoded" encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/> </input> <output> <soap:body use="encoded" encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/> </output> <fault> <soap:body use="encoded" encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/> </fault> </soap/operation> </operation> </soap:binding> </binding> <service name="AckService"> <port name="Acksoap" binding="tns:AckSoapBinding"> <soap:address location="http://www.tagada.fr/ServiceAck"/> </port> </service> </definition>

SOAP
Contrairement Corba ou DCOM, SOAP est plus facile mettre en oeuvre. SOAP est la suite logique de XML-RPC (RPC = Remote Procedure Call ou Appel de Procdure Distance). XML-RPC La mthode est simple : une application A envoie une application B un message demandant l'activation d'une procdure. Ce message est un message HTTP incluant du XML. Le message est interprt par l'application B qui excute la procdure demande et retourne le rsultat dans un message HTTP/XML de manire analogue. L'exemple ci-dessous illustre le procd : un client demande le prix du camembert "Comte de Normandie"

Fondement de SOAP XML-RPC ne permet pas l'envoi de donnes complexes et travaille seulement en synchrone : l'opration requte-rponse fait un tout. SOAP surmonte ces inconvnients. Le protocole SOAP est compos de trois parties :
G G G

l'envelope SOAP (Payload) dfinissant la nature du contenu et le destinataire, SOAP RPC qui dfinit le protocole d'change de messages les rgles d'encodage SOAP

La structure de l'enveloppe SOAP est schmatise ci-dessous (on voit bien la filiation avec XML-RPC) :

SOAP RPC definit le dialogue requte-rponse, toujours bas, comme XML-RPC sur HTTP et XML. Un service SOAP est un service Web accessible par SOAP. Il peut tre programm dans n'importe quel langage de programmation. Il est accessible grce un identifiant unique, l'URN (Universal Resource Naming) (ce systme de nommage est centralis). l'URN est un URI (Universal Resource Identifier) qui comprend outre les URN, les URL (Uniforme Resource Locator) et les URC (Universal Resource Characteristics). La mthode Ack, dfinie en Java plus haut, est dsigne, par exemple, par l'URN "urn:Ack". La requte du service Ack utiliserait le SOAP body suivant : <SOAP-ENV:Body> <m:Ack xmlns:m="urn:Ack"> <expression type="xsd:string"> Bonne Journe </expression> </m:Ack> </SOAP-ENV:Body>

Cette requte sera interprte par l'interface WDSL. La rponse sera du type : <SOAP-ENV:Body> <m:Ack xmlns:m="urn:Ack"> <return type="string"> message reu : Bonne Journe </return> </m:Ack> </SOAP-ENV:Body>

UDDI
UDDI permet de rfrencer les services Web et les entreprises concernes. C'est un annuaire rparti de services Web et d'entreprises et est lui-mme un service Web. Il a t dvelopp initialement par Microsoft, IBM et Ariba. UDDI comporte l'annuaire proprement dit qui constitue le corps du service : UDDI Business Registry (UDDI BR) et les interfaces d'accs cet annuaire. L'annuaire UDDI BR comporte trois parties :
G

les pages blanches qui correspondent aux coordonnes des entreprises enregistres. Les informations correspondantes sont dcrites dans des entits Business Entity les pages jaunes qui donnent des renseignements sur les mtiers des entreprises et les services proposs. Les informations correspondantes sont dcrites dans des entits Business Service. les pages vertes qui donnent des informations de nature technique sur les services proposs. Les informations correspondantes sont dcrites dans un Binding Template et un Technoloy Model (ou tModel).

Pour obtenir un service Web chez un fournisseur de Web Services, il faut d'abord que celui-ci soit enregistr dans le UDDI BR (1). Un utilisateur consulte le UDDI BR , trouve le service adquat(2) et appelle alors le fournisseur (3).

Un UDDI BR peut tre rpliqu d'un oprateur (comme IBM, Ariba, ...) vers un autre. On peut, en fait distinguer plusieurs types d'UDDI :
G G G

UDDI oprateur : l'UDDI BR est propos en accs libre sur Internet par un oprateur (IBM, Microsoft, HP) UDDI place de march : regroupement dans un UDDI d'informations relatives un corps de mtier spcifique. UDDI portail : l'UDDI BR est propos sur un site portail par une entreprise qui propose ses services et grade la matrise des informations UDDI catalogue partenaires : l'UDDI BR est propos aux applications de l'entreprise et maintenu par cette entreprise qui slectionne ainsi ses partenaires. UDDI EAI : il s'agit d'un UDDI BR restreint l'entreprise et ne proposant que les services de cette entreprise dans le but de faire collaborer des applications internes.

Intgration des applications d'entreprise

Bibliographie

G G G

G G G

B. Manouvrier , "EAI, Intgration des applications d'entreprise", Herms M. Rowell, "Understanding EAI : Enterprise Application Integration", Sams L.Avignon, D.Joguet, P.Pezziardi, "Integration nd'applicatiuons : l'EAI au coeur du e-business", Eyrolles D.S.Linthicum, "Enterprise Application Integration", Addison-Wesley Le livre blanc EAI, Mediadev, (voir Webographie) A.Boukhors et al., "XML, la synthse, Intgrez XML dans vos architectures", Dunod

Intgration des applications d'entreprise

Webographie

G G

G G

D. Girad, T. Crusson, "XML pour l'entreprise", http://www.application-servers.com/livresblancs/xml/ Le livre blanc EAI, Mediadev, http://www.dsi.cnrs.fr/ref-partage/ Documents/EAI/livre_blancMEDIADEV.pdf D. Donsez : Enterprise Application Integration, http://www-adele.imag.fr/~donsez/cours/ L.Avignon, T.brethes, C.Devaux, P.Pezziardi, "Le livre blanc de l'EAI : Intgration des Applications d'Entreprise", Octo Technology, http://www.dsi.cnrs.fr/ref-partage/ EAI/Intranet_EAI_publications.htm F.rivard, J-C. Bernadac, F.Knab, "EAI, de l'intgration l'e-business", Cosmobay, http://www.dsi.cnrs.fr/ref-partage/ EAI/Intranet_EAI_publications.htm