Le livre blanc de l’EAI
Intégra ti on des Applications d ’ E n t r e p r i s e
oc to bre 99
© 1999 O CT O Tech no log y. To us dr oi ts rés er vés
Les informations contenues dans ce document représentent le point de vue actuel d’OCTO Technology sur les sujets exposés, à la date de publication.
Dans la mesure où les éditeurs cités doivent s’adapter aux conditions chan- geantes du marché, OCTO ne peut pas garantir l’exactitude des informations présentées après la date de publication.
Les noms de produits ou de sociétés dans ce document peuvent être les marques déposées de leurs propriétaires respectifs.
Au te urs :
Les auteurs de ce document sont des consultants d’OCTO Technology, par ordre alphabétique L. Avignon, T. Brethes, C. Devaux, P. Pezziardi.
Pour tous renseignements complémentaires, veuillez contacter P. Pezziardi ([email protected]).
Constat d’évolution
Un système d’information d’entreprise est constitué de nombreuses applica- tions bâties sur des technologies différentes avec des spécificités propres aux contraintes du moment, et qui de surcroît ont évoluées dans le temps. A pré- sent, lors du développement d’une nouvelle application, une grande partie du travail consiste à développer les interfaces des applications avec lesquelles elle doit échanger des informations.
Dans un contexte où la mondialisation est de mise, ces problèmes prennent une dimension encore plus importante, et deviennent la pierre angulaire des échanges intra-entreprises et inter-entreprises. Les nouveaux concepts et pro- duits de l’Enterprise Application Integration (EAI) se proposent de répondre de manière élégante à cette problématique de gestion des flux d’information dans le SI de l’entreprise.
Les enjeux de l’EAI
L’EAI, traduit en français par “Intégration des Applications d’Entreprise”, per- met de faire communiquer tout type d’applications, que ce soit des dévelop- pements “maison” ou des progiciels intégrés. Il ne s’agit plus dès lors de déve- lopper une nouvelle solution d’interfaçage mais de fournir un cadre d’intégra- tion souple et robuste.
Le fait que l’entreprise puisse faire évoluer en douceur son SI en s’appuyant au maximum sur l’existant est une qualité intrinsèque de l’EAI. Le système d’information a ainsi la capacité d’absorber les changements technologiques toujours plus fréquents. L’entreprise peut alors plus facilement réagir aux nou- velles donnes économiques (fusion, acquisition, mondialisation des marchés et élargissement de la concurrence). De ce point de vue, la valeur de l’EAI rési- de bien dans sa capacité à faire perpétuer le système d’information, tout en minimisant le coût total du changement (TCC).
Cependant, la mise à disposition d’information et l’échange de données entre systèmes nécessitent une normalisation de leurs formats. Dans ce domaine, les technologies de l’EDI ont adressé le problème secteur par secteur (auto- mobile, santé, etc.) en définissant les formats et la cinématique des échanges. Trop complexes et coûteuses à mettre en œuvre, particulièrement pour les PME, elles n’ont pas réussi à s’imposer à grande échelle.
En outre, les échanges de données informatiques s’effectuaient jusqu’à pré- sent sur un mode point à point. Ce modèle éclate aujourd’hui avec l’arrivée
d’une multitude de partenaires et d’organisations de toute taille. En effet, l’avènement des technologies de l’Internet a considérablement allégé les coûts d’investissement et ont permis l’apparition de nouveaux acteurs. De plus, l’apparition de tiers, assurant des fonctions de “place de marché”
(annuaires, catalogues, paiements, commandes, tiers de confiance,...), modi- fie radicalement la cinématique des échanges.
Le format XML, issu du monde du WEB, et les expériences de l’EDI apportent un début de normalisation mais un grand travail reste encore à faire, notam- ment en corrélation avec les éditeurs de progiciels intégrés, sur lesquels de plus en plus d’entreprises gèrent leur personnel, leur stock ou leur système de facturation.
Au delà de ces raisons économiques, deux facteurs technologiques tirent le marché de l’EAI :
• le développement massif des technologies Internet et la possibilité d’uti - liser ce réseau et ses protocoles pour y créer de la valeur ajoutée,
• une adoption généralisée des solutions packagées : Enterprise Ressource Planning (ERP), Customer Relationship Management (CRM), Supply Chain Management (SCM), permettant l’émergence de standards métier.
Acteurs du marché de l’EAI
Une solution EAI contient un ensemble d’outils que l’on peut classer dans les catégories suivantes :
• Les outils de gestion de processus métier, qui gèrent l’ensemble des données métier et assurent le suivi des étapes et des décisions prises,
• Des moteurs de règles pour le routage et la transformation des flux, plus connus sous le nom de Message Broker,
• Des connecteurs et adaptateurs de progiciels intégrés permettant une intégration aisée de ces applications dans le système,
• Des connecteurs vers des formats d’échange déjà en usage (EDI, réseaux de clearing, etc),
• Des passerelles bas-niveau vers les multiples formats de transport (fichier, message, base de données, e-mail, etc.),
• Des middlewares de communications (mode message, transfert de fichiers, Web, messageries).
Aujourd’hui, aucun éditeur du monde de l’EAI ne peut se flatter d’offrir l’en- semble de ces outils. Certains ont une approche “bottom up” : ils viennent du monde des middlewares et proposent des solutions de plus haut niveau au- dessus de leurs technologies existantes.
D’autres ont abordé ce marché en partant de leur expertise métier ou de leur connaissance en matière de progiciels spécialisés, et ont une approche “top down” : ils proposent des outils de gestion de processus ou des connecteurs, et peuvent s’appuyer sur des middlewares existants.
Le spectre des offres actuelles est en pleine ébullition, mais le marché com- mence à se structurer. La bataille se joue à coup d’annonces, d’alliances et acquisitions, afin de pouvoir proposer le plus rapidement possible une offre intégrée globale. A ce jeu, le NASDAQ devient rapidement le baromètre des stratégies.
Ce livre blanc se propose donc d’éclaircir le lecteur sur le pourquoi et le com- ment des technologies EAI.
Une première partie est consacrée à la description de la problématique, la seconde expose les différentes “briques d’architecture” proposées par les édi- teurs, et la dernière présente notre vision du marché… en date de rédaction ! Nous vous souhaitons une excellente lecture, en espérant que vous prendrez autant de plaisir à le lire que nous en avons eu à le rédiger.
S o m m a i r e
I N T R O D U C T I O N 8
1 .VER S L’INT EGRA TI ON DE S AP PLICA TIONS D’ ENT RE PRI SE 1 3
2.A RC HI TE CTU RE E AI 1 6
2. 1.M ÉCA NI SME S D’É CHA NGE 1 6
2.2 .ECH ANGE EN MODE MESSAG E 1 9
2. 3. LES SER VICES FO ND AMEN TA UX DE L’ EAI 2 3
2. 3 .1.Tr an sforma tio ns e t con ne cteu rs 2 3
2.3 .2.Pa sse rell es tec hn iqu es 2 7
2. 3. 3. La gestio n d e proce ssu s ou Work flo w 3 0
2.4 .L’ INTÉGR ATI ON D ES APP LICAT IONS 3 1
2.4 .1.L es app lic ati ons cl ie nt /ser veu r 3 1
2.4 .2.Le s ap plic ations 3- ti ers 3 2
2.4 .3.Le s ER P et autres prog icie ls mét ier 3 3
2. 5. AD MINI STRA TI ON ET EXPLO I TA TION 3 4
2. 6. GES TIO N D E LA S ÉCURIT É 3 6
2 . 7 . C O N C L U S I O N 3 7
3. ACT EURS D U M AR CH É 3 9
3. 1. ACTIVE SOFT WAR E 4 0
3.2 .BEA SYST EMS 4 2
3 . 3 . C R O S S W O R L D S 4 4
3 . 4 . F O R T É 4 6
3 . 5 . I B M 4 8
3 . 6 . M I C R O S O F T 5 0
3 . 7 . N E O N 5 2
3. 8. SO FTW AR E TE CHNOL OGIE S CO RPO RATIO N 5 4
3 . 9 . S O P R A 5 6
3 . 1 0 . T E M P L A T E 5 8
3 . 1 1 . T I B C O 6 0
3.1 2. TS I SOFT WARE 6 2
3.13 .VI EWLOC IT Y (E X F RO NT EC) 6 4
3 . 1 4 . V I T R I A 6 6
T able des fi gu res
Figure 1 : Flux ent ra nts et sorta nts d’une app lication 8
Figu re 2 : Evo lutio n du SI d’u ne entrepr ise à travers le t emps 8
Figure 3 : Cycle d’a cqu isitio n de s technologie s 1 4
Figu re 4 : Princip e du Hub central 1 5
Figu re 5 : Ech ang e basé su r le t ra nsf er t de fich ier 1 6
Figu re 6 : Ech ang e de type “Ex tra ction” 1 6
Figu re 7 : Méca nism e d e ré plica tion entre SGB DR 1 7
Figure 8 : Echanges via un MO M 2 0
Figure 9 : La c ouc he t ransport c om me pre miè re briq ue d e l’EA I 2 1 Figure 10 : Le Mess age B ro ker com me de uxième b rique de l’EAI 2 2 Figu re 11 : Exem ple de reformat age d’un flu x d’information 2 4 Figure 12 : L es co nne cte urs comm e troisiè me brique d e l’EA I 2 5
Figu re 13 : P asse re lle ave c les SGBDR 2 7
Figure 14 : Exemple de déclenchement d’une transaction à réception d’un message 2 9 Figu re 15 : E xem ples de pa sser elles ver s et en provena nce de fichie rs 2 9 Figu re 16 : L es passer elle s comm e quatr ièm e brique de l ’EAI 3 0 Figu re 17 : E xem ple d e pr oce ssus métier autom atisable par un WorkFlo w 3 0 Figu re 18 : L e Workflow comme cinq uième br iqu e de l’EAI 3 1 Figu re 19 : E xem ple de pr ogram matio n visuelle a vec Visual B asic 3 3 Figu re 20 : Le s ou tils d’e xplo itation c omme s ixième br iqu e de l’EAI 3 5 Figu re 21 : La sécurit é : septièm e b riq ue de l’EAI 3 7
...mais g éné ral ement p as la septième me rv eille !
Figu re 22 : L’e nse mbl e des bri ques d’un e offr e d’ EAI 3 7 Figu re 23 : Po sitionne ment de s principaux acteurs du march é de l’EAI 3 9 Figu re 24 : A ctiveW or ks Int egrat ion Syste m (so urce Active Sof tw are) 4 1
Figu re 25 : B EA eL ink So lution (source BEA Systems) 4 3
Figu re 26 : Arch itec ture Cr os sWorlds (source Cro ssWorlds) 4 5 Figure 27 : Fo rté Fusio n Enterpri se Ap plication Integratio n (source Fort é) 4 7 Figure 28 : MQSeries a u cœ ur du Bu sine ss integr at ion (source IBM) 4 9
Figu re 29 : Micros oft BizTal k (s ource Mic ro sof t) 5 1
Figu re 30 : NEON Fo rm ater et NEO N Ruler (so ur ce NEON) 5 3 Figure 31 : e*Gate (ex D ata Gate), la solu tion d’EA I de S TC (source S TC ) 5 5
Figu re 32 : B us Ap plicatif (source Sopra) 5 7
Figure 33 : EIT (sou rc eT em plate) 5 9
Figu re 34: Tib/ Act ive Enter pr ise (so urceTibc o) 6 1
Figure 35: A rchitec tur e Me rcator (source TSI) 6 3
Figu re 36: Composan ts d e l’offr e A MTrix (sou rce Viewlocity) 6 5 Figure 37: Comp osants d e l’offre B usine ssWare (sou rc e Vitria) 6 7
I n t r o d u c t i o n
La problématique d’Intégration des Applications d’Entreprise n’est pas nouvel- le. En effet, faire communiquer entre elles les différentes applications qui composent le Système d’Information n’a rien d’exceptionnel.
Pourquoi une communication entre applications ? Tout simplement parce que un Système d’Information n’est pas constitué d’une seule application. Chaque application spécifique ou progiciel répond à un besoin fonctionnel, mais nécessite, d’une part, des informations gérées par d’autres applications (liste des clients, des produits, etc.) et, d’autre part, produit de l’information qui intéresse également d’autres applications (comptabilité, gestion de stock, etc.). Ce principe est simplement figuré par le schéma suivant, où apparais- sent les flux en entrée et en sortie d’une application :
Fi gu re 1 : F lu x en tr ant s et sortan ts d’une a ppl icati on Cette schématisation, un peu banale certes, présente néanmoins l’avantage d’introduire l’exemple d’une entreprise fictive A et son évolution dans le temps :
F ig ur e 2: Evo lut ion du S I d’u ne e ntr ep ri se à trav er s le t em ps Constat : les
applications d’une entreprise sont excessivement liées entre elles.
Au cours du temps, le SI de toute entreprise tend vers l’état
“spaghetti”
La détail de la chronologie de notre exemple est le suivant :
A c t i o n Mise en œuvre Difficultés rencontrées 1980 Mise en œuvre d’une Utilisation d’un Mainframe. Monopole du fournisseur,
application centrale coût de maintenance
de gestion client/produits. élevé.
1982 Déploiement d’une Ecriture de programmes nouvelle application de synchronisation de comptabilité. des bases des deux
applications.
1990 Mise en œuvre de quatre Mise en place d’un Difficultés en cas de nouvelles applications système de réplication changement de SGBDR.
en régions visant entre les SGBDR des la gestion de nouveaux nouvelles applications.
produits. Ecriture des programmes de synchronisation vers les applications centrales.
1992 Acquisition d’un Ecriture d’un mécanisme Difficultés rencontrées concurrent. de synchronisation des pour fusionner les
bases clients, avec applications de gestion gestion d’un identifiant de produits qui resteront unique. Portage de isolées.
l’ensemble des programmes extrayant des données.
1995 Migration des Ecriture de divers La mise en place de applications centrales programmes de l’ERP est entravée par sous un ERP. synchronisation les nombreuses interfaces
permettant la coexistence existantes à reproduire.
des trois systèmes. Développements lourds Développements réalisés autour de l’ERP.
à l’aide des outils fournis par l’éditeur de l’ERP et de compétences externes.
1996 Création d’un Ecriture d’un programme Difficultés rencontrées DataWarehouse de suivi d’extraction de données pour homogénéiser les de clientèle. depuis le central et les données venant de
régions vers la base sources hétérogènes.
Infocentre.
1998 Ouverture d’un Web. Mise en œuvre de Délais de mise en œuvre nouvelles interfaces vers énormes en regard de la les systèmes hétérogènes. simplicité du service Développement des Ajout de nouveaux flux interfaces vers l’ERP. Duplication des données.
A partir de ces éléments, mettons nous par exemple à la place d’un consul- tant externe et évaluons par une note de 1 à 10 les six points suivants :
• Flexibilité du système
Dans quelle mesure peut-on faire évoluer un projet (une application) indépendamment des autres ? Quelle réactivité peut-on espérer pour la mise en œuvre de projets futurs (Time to Market) ?
• Capacité d’administration et d’exploitation
Les six questions fondamentales pour évaluer l’agilité d’un SI.
Capacité de suivi des flux, maîtrise de l’intégrité transactionnelle de son système: est-on capable de s’assurer que tel achat de produit par le client a bien été comptabilisé, envoyé au datawarehouse, etc. ?
• Capacité du système à diminuer les délais d’échange
Le système est-il capable simplement d’évoluer vers du Straight Through Processing (STP)1, c’est à dire de propager instantanément les événe- ments se produisant dans l’une des applications vers les cibles ?
• Sécurité
Quel est le niveau de sécurité de ces échanges : authentification, contrô- le d’accès, intégrité, confidentialité ?
• Coût de développement et de maintenance
Dans le coût global de ces applications (conception, développement, intégration, exploitation), quelle est la part liée aux échanges inter-appli- catifs ?
• Qualité de service vu du client
Est-on capable simplement de fournir au client une vision synthétique de ces avoirs dans l’entreprise fusionnée A+B, quelle est la fraîcheur de ces informations ?
Procédons maintenant comme dans certains magazines féminins : faites la somme des notes et reportez vous à la rubrique correspondante.
• Vous obtenez un total de plus de 30 (la moyenne) :
Vous êtes un grand optimiste, la nature vous a doté de ce regard positif et parfois naïf sur tout ce qui vous entoure... en revanche, nous vous pro- posons de repasser le test avec les éléments supplémentaires suivants :
■Modifier une application nécessite-t-il de retoucher l’ensemble de ses interfaces ?
■L’exploitation des flux est-elle globale ou dispersée dans les différents ordonnanceurs et logs ?
■Les flux étant ordonnancés la plupart du temps en mode batch avec extraction, transfert de fichier et import, porter un flux en mode fil de l’eau nécessite-t-il une intervention dans les applications ?
■Certains flux ne sont-ils pas issus de programmes batch sous Unix ou MVS, contenant les mots de passe d’accès aux bases cibles ? En fait, la part de la mise en œuvre des flux dans le coût global des applica- tions dépasse largement les 25% (Source Gartner), (extractions, transforma- tions, routages, imports). Cette part augmente exponentiellement dès que les spécifications des flux dépassent la simple synchronisation de référentiels pour aller vers des processus métier complexes.
• Vous obtenez un total de moins de 30 :
Doué d’un sens aigu de l’observation, vous savez déceler les problèmes et y apporter des solutions concrètes. Votre brillant intellect vous pousse ainsi à lire avidement la suite de cet ouvrage.
Effectivement, ce qui était acceptable à l’échellede quelques applications ne l’est plus du tout au niveau des grands Systèmes d’Information : on se trouve confronté au “syndrome Spaghetti”. Chaque nouvelle application nécessite la mise en œuvre de flux d’information depuis et vers elle, l’augmentation de ces flux est exponentielle par rapport au nombre d’applications.
1 La notion de STP vient historiquement du monde de la finance et des réseaux de compensation (comme Swift par exemple).
Par exemple, l’achat de titres dans une application bancaire de back-office générait une impression qui était ressaisie dans l’ap- plication de clearing, puis envoyé sur le réseau Swift. Aujourd’hui, le processus peut s’automatiser, l’application envoie directe- ment un message formaté au point d’entrée Swift qui le propage.
Chaque nouvelle application engendre de nouveaux flux d ’ i n f o rmation vers ou en provenance de l’existant.
L ’ u r b a n i s m e
De la même manière qu’un architecte conçoit un bâtiment en fonction des besoins exprimés par ses futurs occupants à un instant donné, un urbaniste prend en compte les exigences d’une communauté à faire évoluer dans le temps.
A l’origine du concept d’urbanisme, Jacques SASSOON fait l’analogie avec une ville comme Paris et assimile les quartiers aux groupes d’applications qui ont été conçues à peu près au même moment avec une architecture simi- laire. On trouve alors des groupes pour les applications Mainframe en mode Batch ou interactif, les mini-ordinateurs, le client/serveur, et maintenant les nouvelles applications Web. Les urbanistes n’aspirent pas à démolir les anciens quartiers à l’émergence de chaque nouveau style architectural. Mais, ils s’efforcent de maintenir certains standards d’infrastucture dans tous les quartiers. L’approvisionnement en eau et en électricité est nécessaire quelque soit le quartier. Les nouveaux besoins de la communauté provoquent parfois certains travaux d’aménagements des quartiers existants afin d’y apposer une canalisation plus grosse par exemple. Alors que les modèles d’architecture sont statiques, l’urbanisme doit savoir évoluer à travers le temps et prendre en compte les besoins non seulement du présent, mais éga- lement du passé et du futur.
De cette analogie avec la gestion de la ville, ressort un ensemble de règles et de principes :
• Le processus métier global d’une entreprise est découpé en domaines, contenant chacun des districts, comprenant à leur tour des blocs.
• Chaque bloc est autonome et capable d’assurer seul l’accomplissement des fonctions qui lui sont attribuées.
• Il ne doit pas y avoir de dépendance temporelle entre les blocs, chacun opé- rant de manière asynchrone par rapport aux autres.
• Chaque bloc encapsule les données dont il a la charge et qui ne peut être directement accédé par un autre bloc (principe de la technologie objet)
• Chaque bloc produit des résultats et des rapports avec un format standard sans présumer des destinataires
• Chaque bloc doit avoir un gestionnaire d’évènements d’entrée et un géné- rateur d’événements en sortie
• Toutes les communications entre les blocs doivent s’effectuer indirecte- ment au travers d’un gestionnaire de flux.
Les contraintes d’interactions asynchrones entre les blocs n’interdisent cependant pas d’utiliser des technologies synchrones temps réel pour l’invo- cation de méthodes distribuées à l’intérieur d’un même bloc.
Si l’adjonction d’une application Web à un système existant nécessite un cou- plage synchrone étroit entre les deux blocs, on assiste alors à une fusion des deux. C’est un peu comme la nouvelle façade d’un bâtiment. On a alors inté- rêt à ce que les deux blocs s’assemblent parfaitement et que les fenêtres soient bien alignées. Si à l’intérieur d’un même bloc, il existe des fortes contraintes de standardisation d’architecture, une certaine flexibilité entre les blocs est de mise, tant qu’un certain formalisme dans les d’échanges d’in- formation est respecté, par l’utilisation par exemple d’un format fédérateur comme XML.
L’entreprise, pour pallier aux problèmes évoqués plus haut, doit s’équiper d’un système performant pour faire communiquer ces applications.
En effet, le SI n’est malheureusement pas quelque chose de monolithique. Il évolue dans le temps, et, comme tout autre objet sur ce bas monde, obéit aux principales lois de la physique. En particulier son entropie ne cesse de croître, i.e. le désordre en son sein augmente: évolution des technologies et coexis- tence de différents paliers technologiques, choix différents selon les branches de l’entreprise, fusions/acquisitions, ouverture de canaux de distribution vers les partenaires, les clients, etc.
Le décideur est donc confronté à une problématique complexe d’intégration de ces systèmes hétérogènes, cette intégration devant répondre aux cinq critères évoqués plus haut : flexibilité, exploitabilité, capacité de gérer certains flux au fil de l’eau, sécurité et maîtrise des coûts bien entendu. L’objectif prin- cipal est de se donner la capacité de fournir au client final un service de meilleure qualité.
Le chapitre suivant se proposant de dresser un historique des offres en matiè- re d’EAI, nous commencerons donc par plonger dans le passé de ce marché, pour émerger ensuite dans l’actualité des offres, et tenter d’entrevoir leurs futures évolutions.
L’EAI répond à la problématique d’intégration de hétérogènes au sein du SI mais aussi vers l’extérieur : clients et fournisseurs.
1. Vers l’Integration des Applications d’Entreprise
Pour résumer le paragraphe précédent, le objectif de l’EAI est d’échanger de manière performante des informations entre applications ou progiciels, sur plates-formes hétérogènes, dans des Systèmes d’Information en constante évolution.
Historiquement, l’EAI2a été le cheval de bataille d’éditeurs comme Sopra ou IBM depuis les années 80.
Sopra avait développé une technologie de gestion de flux (Règle du Jeux) capable de gérer des transferts de fichiers de façon globale : inventaire, contrôle de flux et transformations. Cette initiative innovante, unique sur le marché de l’époque, se positionnait au-dessus du transport des fichiers, pour fournir des services de transformation, de routage et d’exploitation grâce à un dictionnaire des flux.
IBM proposa aussi assez tôt (à partir de 1993) un middleware asynchrone en mode message (MQSeries), c’est à dire de la “tuyauterie3” permettant de développer des applications s’échangeant des informations au fil de l’eau.
Cette technologie se positionnait précisément sur l’interopérabilité des appli- cations, centrales dans un premier temps, puis sur l’ensemble des plates- formes disponibles sur le marché.
D’autres éditeurs ont par la suite proposé des offres comparables à celle d’IBM (DEC, Pipes et plus récemment Microsoft) voire plus évoluées, comme Tibco par exemple.
Enfin, beaucoup de clients ont réalisé eux-mêmes leur propre système de messagerie inter-applicative et de gestion de flux. Ces initiatives, justifiables dans le cadre de projets limités, apparaissent finalement peu rentables à terme par rapport à l’acquisition de produits, notamment sur les aspects sup- port multi-plate-forme, capacité d’administration et d’exploitation, gestion transactionnelle, outils de développement...
Probablement mal expliqué et mal compris, limité technologiquement et com- plexe à mettre en œuvre, ces solutions ne se sont pas généralisées et sont restées pour beaucoup des solutions techniques, locales à des besoins parti- culiers. L’exemple de Tibco est assez révélateur : sa technologie de Publish and Subscribe, déployée à Wall Street en 1980, puis dans les salles de mar- ché du monde entier, n’a pas réussi à s’imposer réellement ailleurs que dans ces niches. Pourtant techniquement, l’offre était très attractive, le principe en est le suivant :
•le publisher poste des messages sans en connaître les destinataires, il publie sur un thème, par exemple trading.achat
•le s u s b s c r i b e rs’abonne aux messages det r a d i n g . *et reçoit ainsi au fil de l’eau ce qui est publié sur les thèmes t r a d i n g . a c h a t, t r a d i n g . v e n t e. . . Ce principe permet un réel découplageentre les applications, beaucoup plus qu’un moniteur de message classique qui effectue ses envois en point à point (directement de l’émetteur vers les N récepteurs finaux, via N files d’attente).
Dans ce dernier mode en effet, les applications émettrices doivent connaître parfaitement l’adresse des applications destinatrices.
Quel est donc l’événement qui bouleverse aujourd’hui l’état du marché ? Pourquoi donc la presse se fait-elle l’écho de cette problématique aussi ancienne que les Systèmes d’Information ?
La réponse tient en deux points :
•d’un côté l’offre des éditeurss’est enrichie de nouvelles fonctionnalités
2 Qui ne portait pas encore à l’époque ce doux acronyme marketing et “Gartnerien”
3 On parlera dans la suite de Message Oriented Middleware (MOM) pour désigner ces technologies L’éditeur Français
SOPRA a été l’un des précurseurs dans la gestion des flux de l’entreprise.
D’autres acteurs se sont positionnés à différents niveaux : IBM, Tibco, Microsoft...
Certains utilisateurs ont développé leurs propres systèmes de communication inter- applicatives.
Le modèle de communi- cation de type «Publish
& Subscribe» est plus attrayant que le modèle
«Point à point».
simplifiant la mise en œuvre et autorisant une réelle généralisation : pas- serelles, connecteurs aux formats standards et pour la plupart des progi- ciels, offre d’administration, gestion de la sécurité, intégration dans les outils de développement, etc.
• de l’autre les clients réalisent les coûts et la relative vétusté de leurs infrastructures existantes en la matière4.
Une analogie possible se trouve sur le marché des Systèmes de Gestion de Base de Données Relationnelles (SGBDR). Avant l’avènement de la technolo- gie relationnelle, chaque projet réécrivait notamment la gestion transaction- nelle, la gestion de lock, la sécurité et l’exploitation de ses fichiers de base de données. Puis un jour, certains ont proposé de factoriser ces briques de bases dans des systèmes intégrés de gestion de base de données.
La courbe suivante est assez instructive quant aux différentes étapes du cycle d’acquisition d’une technologie et l’évolution du niveau :
Fi gure 3: Cycle d ’ac qui sition de s te chno logi es
Aujourd’hui, le marché a bénéficié à ces éditeurs bien sûr, mais surtout aux clients : il serait inimaginable de nos jours de se priver de ces systèmes et des outils de conception, de développement et d’administration qui les accompa- gnent.
De la même manière donc, le marché de l’EAI se situe en France dans la phase de “Début d’acceptation” (il est un peu plus avancé aux Etats-Unis). Il est enfin perçu comme un puissant outil d’interconnexion capable de résoudre des problématiques transactionnelles, sécurisées, à caractère critique et d’améliorer la qualité de service des systèmes actuels.
Le positionnement est clair : fédérerl’ensemble des technologies qui aujour- d’hui tissent des adhérences fortes entre applications et y apporter une valeur ajoutée. Les échanges sont essentiellement de type :
• échanges de fichiers,
•échanges de messages,
•systèmes de réplication SGBDR,
• systèmes d’extraction de données orientés DataWarehouse.
Le syndrome spaghetti évoqué au paragraphe précédent est constitutif de la superposition des technologies mentionnées. Les travers sont nombreux : interdépendance des applications, codage de la logique de transformation et de routage en L3G (C, Perl, Shell, etc.), réplication sauvage des données dans plusieurs référentiels, difficulté de suivi global, mauvaise sécurisation, difficul-
4 Parfois douloureusement puisque certaines entreprises ont réalisé après coup la nécessaire prise en compte des programmes d’interconnexion dans les projets An 2000...
Les utilisateurs réali- sent l’énorme potentiel des solutions d’EAI.
EAI : de puissants outils d’interconnexion en phase d’acceptation
tés de passage en mode fil de l’eau (STP).
Le stratégie étant précisée, la tactique d’implémentation consiste à fédérer les échanges d’information autour d’un Bus d’Echange. Le Bus (ou Hub) est un élément focal du Système d’Information, il centralise les flux en assurant les transformations et les routages nécessaires.
Le système fonctionne par essence en mode “Publish and Subscribe”, c’est à dire que dès qu’une information présente dans une application est susceptible
“d’intéresser” d’autres applications, elle est transmise, non pas aux destina- taires finaux, mais au bus d’échange. Celui-ci a la charge d’en assurer ensui- te le routage vers les applications “intéressées” en y appliquant éventuelle- ment les transformations nécessaires à leur bonne interprétation. Nous détaillerons plus loin les services supplémentaires qui peuvent se greffer au niveau de ce Bus, c’est-à-dire son niveau d’“intelligence”.
F igure 4 : Pr inci pe du Hu b cen tr al
Le gain apparaît clairement : tous les aspects d’extraction, transformation et émission, auparavant gérés programmatiquement, sont désormais déportés dans un outil adapté. Donc, au-delà du simple gain en terme de coûts de développement, c’est la totalité du Système d’Information qui bénéficie :
•d’un gain de flexibilité
Une modification dans une application n’impacte que sur le Bus et non les N destinataires,
•d’un gain de robustesse
La centralisation des flux permet un réel suivi, des sauvegardes, des reprises,
•d’un gain en fluiditéet en sécurité
Nous le verrons au paragraphe suivant, les technologies proposées se fondent sur des mécanismes asynchrones fil de l’eau et peuvent propo- ser une gestion poussée de la sécurité.
Ainsi la qualité de serviceglobale s’améliore bien entendu : les temps d’inté- gration d’une nouvelle application sont réduits, la gestion des flux est sécuri- sée, la fraîcheur et la sécurité des données augmente.
Quelle(s) technologie(s) mettre en œuvre pour implémenter cette fonction ? C’est l’objet du prochain chapitre.
La solution EAI : un bus d’échange central fonctionnant en mode « Publish & Subscribe «.
Un puissant outil de gestion du changement
2. Architecture EAI
2.1. Mécanismes d’échange
Comme nous l’avons évoqué précédemment, la majorité des mécanismes d’interopérabilité se fondent sur la donnée. On peut en citer trois principaux, par ordre d’importance décroissant dans les systèmes actuels :
•les transferts de fichiers,
• les systèmes d’extraction orientés DataWarehouse,
• les systèmes de réplication SGBDR.
Explicitons rapidement le mode de fonctionnement de ces trois mécanismes.
Le transfert de fichier représente l’immense majorité des flux d’information aujourd’hui. Quand deux applications communiquent, le premier mécanisme mis en œuvre consiste à extraire une partie de l’information contenue dans l’application, puis, pour chaque destinataire, la formater et la transmettre.
D’une manière générale, les deux premiers points constituent des développe- ments spécifiques (extraction et formatage), le dernier point (transport) étant assuré par des transferts “classiques” (FTP, partage de fichiers) ou plus évo- lués à base de progiciels spécialisés (Computer Associates XCOM, Sterling Commerce Connect Direct, Sopra CFT et InterPel, etc.).
Fig ure 5: Echa ng e ba sé sur le t ran sfert de fi chie r
Les systèmes d’extraction orientés DataWarehouse ( E x t r a c t -Transform-Load : ETL) constituent une avancée dans le domaine puisqu’ils prennent en charge la gestion d’un dictionnaire mettant en relation les données sources (qui peuvent être sous différentes formes : fichiers, bases relationnelles, etc.) et les données cibles du DataWarehouse. Exemple : pour alimenter la table clients d’un D a t a Warehouse, on décrira au niveau d’un dictionnaire centralisé où et comment aller chercher cette donnée. En particulier, si celle-ci se trouve dans un fichier, un script automatique sera mis en œuvre grâce au dictionnaire pour transporter le fichier et l’importer dans le DataWarehouse (ETI, Informatica, Ardent, Constellar, etc.), de même si elle vient d’une base relationnelle, d’un annuaire, etc.
Fi gure 6 : Ech ange de type “Extr ac tio n”
Le transfert de fichier est encore aujourd’hui le principal mode d’échange d’informa- tion entre applications.
Les ETL ne se focalisent que sur l’extraction de données.
Les systèmes de réplication SGBDRsont optimisés pour répliquer en mode fil de l’eau ou en mode batch des données issues de SGBDR.
Les produits les plus avancés étendent leur capacité à d’autres sources de données, comme les fichiers VSAM par exemple.
Capables de fonctionner en mode événementiel (dès qu’un UPDATE base de données est déclenché par exemple), ces outils s’appliquent très bien à une problématique d’intégration d’applications client/serveur.
Comme nous le verrons au paragraphe développement, ils permettent d’inté- grer ces applications sans intervention dans le code.
En revanche, ils ne s’appliquent correctement qu’à ce type d’environnement, leur capacité de routage et de formatage d’événements n’étant pas suffisam- ment évoluée.
Figu re 7 : Mé ca nisme de rép lic ati on en tre S GB DR
Si les inconvénients d’un système d’échange reposant entièrement sur les transferts de fichiers sont bien connus, les limites d’une interopérabilité uni- quement fondée sur la donnée sont en revanche moins évidentes à appré- hender.
La réplication SGBDR est bien entendu une niche dans laquelle ne rentrent pas aisément les applications centrales, les ERP et les communications hété- rogènes au sens large.
Ces outils pourront cependant être complémentaires d’une architecture EAI pour adresser des problématiques spécifiques, dans le cas d’applications client/serveur par exemple.
Les ETL pourraient en revanche constituer un excellent socle technique d’in- teropérabilité.
Malheureusement, leur objectif est de créer une nouvelle base de don- nées, pas de diriger des événements vers différents systèmes hétéro- gènes.
En somme, c’est une excellente “pompe”, mais un mauvais “routeur”5 : ils mettent en œuvre un référentiel de méta-donnéesdécrivant où l’information se trouve et ce qu’elle signifie, mais pas le référentiel de règles métierdécri- vant les flux voire les processus complexes.
Exemple : la fermeture d’un compte déclenche une facturation, le passage d’un ordre boursier déclenche sa comptabilisation, etc.
Nous le découvrirons en détail dans la suite, les seuls outils à fournir ces deux fonctionnalités sont les Message Broker.
Comme leur nom l’indique assez bien, ces outils s’appuient sur des commu- nications de messages asynchrones.
5 A noter cependant que des acteurs comme Constellar, issus des premières générations d’ETL, ont abordé le problème dans sa globalité et offrent aujourd’hui une intégration poussée avec les outils d’EAI.
Les mécanismes de réplication SGBDR sont trop limités en terme de routage et formatage.
L’idée de faire communiquer les applications en mode message est relative- ment ancienne puisque avant d’apparaître dans les Message Oriented Middleware (MOM) actuels, elle est le fondement de la communication entre objets, distribués ou non. Un message peut contenir plus que de la donnée simple. Il pourra, comme dans le cas des communications entre objets, inclu- re la méthode, c’est à dire l’action qu’il représente. Exemple : envoi d’un mes- sage commandercontenant la quantité, le code de l’article; envoi d’un mes- sage règlercontenant la devise, le clientet le montant, etc.
Pour assurer le transport de ces messages, nous avons deux principales tech- nologies à notre disposition :
• les Message Oriented Middleware
Des produits comme MQSeries (IBM), Tib’Rendez-vous (Ti b c o ) , MessageQ (BEA), MSMQ (Microsoft) proposent ce style d’offre.
• les Object Request Broker (ORB)
Visibroker (Inprise), Orbix (Iona), ou plus récemment les offres d’Application Server (IBM WebSphere, BEA WebLogic, Microsoft MTS, Sun, etc.) qui sont parfois bâties au-dessus d’un ORB.
L’interopérabilité soulève cependant une contrainte forte : ne pas lier les sys- tèmes entre eux. En particulier, le fait que, pour échanger, deux applications doivent être simultanément disponibles en permanence n’est clairement pas acceptable.
Synch rone ou async hr one ?
Les architectures distribuées et l’émergence de technologies de com- munication entre applications imposent des choix de conception archi- tecturale. Une des décisions importantes à prendre reste le mode de communication : synchrone ou asynchrone?
Dans un mode synchrone, l’émetteur doit localiser le destinataire sur le réseau, se connecter à l’une de ses instances et attendre la répon- se. Dans un tel mode, la requête n’est jamais perdue. En cas d’erreur ou de rejet, l’application émettrice en est directement avertie.
Les technologies RPC, HTT P, Corba, COM, etc entrent dans cette caté- g o r i e .
A l’inverse, dans un mode asynchrone, la disponibilité du destinataire au moment de l’émission n’est plus indispensable. Celui-ci traitera la requête en temps voulu. Charge au middleware utilisé de garantir alors que la requête ne se perde pas.
Les technologies de Message Oriented Middleware comme IBM MQSeries, Microsoft MSMQ, Tibco/Rendez-Vous entrent dans cette c a t é g o r i e .
Si l’émetteur de la requête a besoin de la réponse avant de passer à une autre tâche, les technologies synchrones sont à privilégier, ce qui nécessite alors un haut niveau de disponibilité à la fois du réseau et des applications destinatrices.
Si une telle disponibilité n’est pas garantie ou si la réponse n’est pas immédiatement nécessaire, il sera alors préférable de mettre en œuvre des communications orientées sans connexion.
D’une manière générale, il est fortement conseillé de réduire les besoins de synchronisation entre les applications afin d’améliorer leur disponibilité et leurs performances.
Un mécanisme d’échan- ge avec fort découplage:
le message.
6 Object Management Group, groupement d’éditeurs et d’utilisateurs publiant la standard CORBA (Common Object Request Broker Architecture).
En ce sens, la vision de l’OMG6 qui propose une communication synchrone d’objets à objets est irréaliste dans le cadre de l’EAI.
Les systèmes doivent demeurer le plus indépendants possibles, et les méca- nismes qui les lient le plus asynchrone possible. Le système A doit fonc- tionner même si le système B n’est plus disponible ; à son retour, B récupé- rera ce qui lui était destiné.
Bien entendu, on rétorquera que les ORB disposent de mécanismes asyn- chrones que sont les Event Services et autre Notification Services. Cependant, on l’a vu, le simple transport ne suffit pas. La valeur ajoutée d’une architectu- re EAI se situe au niveau des services de transformation et de contrôle de flux qu’elle met en œuvre, voire au niveau d’autres services que nous détaillerons plus loin.
Dans ce domaine, seules les offres se fondant sur des MOM sont aujour- d’hui à même de couvrir ce besoin.
Que le lecteur ne conclue pas trop vite, les éditeurs d’ORB ou de serveurs d’applications commencent à intégrer ce type de technologie dans leurs pro- duits.
Voir à ce propos Iona et le projet Warhol, Forté Fusion, BEA et son partenariat avec TSI (l’éditeur du Message Broker Mercator), Jasmine de Computer Associates, IBM avec WebSphere ou Microsoft COM+.
Du reste, même si l’asynchrone doit être privilégié dans la mesure du possible, il est des cas où le mode synchrone question/réponse est nécessaire.
Par exemple dans le cas d’une consultation de référentiel externe, bloquante pour un processus donné.
On verra donc dans l’avenir des produits s’appuyer indifféremment sur du middleware synchrone (HTT P, IIOP, RMI, DCOM, etc.) ou asynchrone (MQSeries, MSMQ, etc.).
Bien que le retard de l’offre EAI des éditeurs de serveurs d’applications soit encore important, il est donc probable que les deux approches fusionnent à moyen terme: les communications en entrée et en sortie du serveur d’appli- cations seront pilotées par un moteur d’EAI, fournissant des services de bien plus haut niveau que l’accès à un protocole technique comme HTTP ou IIOP.
Pour les entreprises, il n’y a donc pas de choix à proprement parler, pour démarrer un projet d’EAI aujourd’hui, il faut se tourner vers les offres de MOM et de Message Broker.
L’important étant de constater qu’il s’agit d’une trajectoire claire du marché, c’est-à-dire dans laquelle s’inscrivent aussi bien les acteurs historiques du monde de l’asynchrone que les ténors du moniteur transactionnel ou du ser- veur d’applications.
Nous vous proposons donc au travers des prochains paragraphes de décrire les briques d’architecture qui incluent le transport et les services à valeur ajou- tée d’une architecture EAI : transformations, routages, passerelles, connec- teurs, gestion de processus complexes (workflow).
Enfin, nous illustrerons les aspects liés au développement d’application et la problématique d’administration et de sécurité.
2.2. Echange en mode Message
Le mode de transport principalement utilisé par les Message Oriented Middleware est du point à point. C’est à dire qu’une application émettrice posteun message dans une file d’attente précise. L’application réceptrice R1, quand elle le décide, consomme les messages postés par le programme émetteur. Les deux applications communiquent donc directement, au travers
Les services d’échanges asynchrones du stan- dard CORBA ne satis- font pas aujourd’hui aux besoins complexes de l’EAI.
Routage et transforma- tion sont assurés par les Message Broker.
Message Oriented Middleware : une technologie orienté échange point à point...
d’une file d’attente commue des deux parties. Si l’application émettrice doit fournir l’information à un deuxième programme R2, elle doit poster le mes- sage une seconde fois.
Fi gu r e 8: Ec ha nges v i a un MOM
Au-delà de la simple gestion de files d’attente, le MOM assure un certain nombre de services pour sécuriser l’architecture :
• Garantie de délivrance
Un message, une fois soumis par l’application, sera forcément traité par le système : soit l’application réceptrice le consomme (et il y a garantie d’unicité) soit sa durée de vie expire et il est envoyé dans une file d’at- tente particulière (dead-letter queue) où une action de l’exploitant est requise.
• Notification
Il est possible de “simuler du synchrone” par l’utilisation de reply queue dans laquelle l’application émettrice attend une réponse en retour de son message.
• Priorité, groupage des messages
Il est possible de marquer les messages comme ayant une priorité par- ticulière ou comme faisant partie d’un groupe de messages.
• Sécurité
Il est intéressant de pouvoir restreindre l’accès pour des files d’attente particulières. Par exemple tout le monde ne doit pas pouvoir publier des messages dans une file d’attente “paiement” sans contrôle. Un messa- ge peut être authentifié, son contenu rendu intègre ou confidentiel. Nous détaillerons ces points au paragraphe Sécurité.
• Triggering
Sur l’arrivée d’un message dans une file d’attente, il est possible de déclencher automatiquement un programme. Par exemple, une transac- tion, une mise à jour de base de données, etc.
• Transaction
Le MOM peut se comporter comme un Ressource Manager vu d’un moniteur transactionnel ou d’un OTS. Ainsi, il est possible d’écrire des composants s’exécutant dans un Application Server et qui réalisent une mise à jour de base de données et un envoi de message, le tout de manière transactionnelle.
Inversement, le MOM peut aussi jouer le rôle du Transaction Manager, c’est le cas par exemple lorsque le MOM synchronise l’envoi d’un mes- sage avec des mises à jour de plusieurs SGBDR
La principale fonction d’un MOM est de transmettre des mes- sages de manière sécurisée
Les applications pevent donc être directement liées à la couche transport (MOM, fichiers, email ORB...). Dans le cas du MOM, les applications utilisent des verbes très simples de type mq_ p u tpour poster des messages et mq_get pour les retirer :
F ig ur e 9: La co uc he tr an sp ort c omm e p re mi èr e br ique d e l’ EA I
Un poi nt sur les modèl es de communi cat i on
L’habitude est de classer les méthodes de communication entre applications en cinq modèles. Chacun de ces modèles repose sur l’un des deux principes de base suivants :
• Le mode bidirectionnel souvent orienté connexion, correspond à la plupart des implémentations de communication conversationnelle et question/réponse
• Le mode unidirectionnel souvent orienté sans connexion, correspondant généralement aux implémentations par messages.
Conversationnel : Dans ce mode, les deux applications communiquent à l’intérieur d’une même connexion, un peu comme une conversation télépho- nique entre deux personnes. Il suppose que les deux partenaires soient dis- ponibles au moment de l’échange. L’émetteur initialise la connexion. Un dia- logue sous forme de questions/réponses s’instaure. Puis la communication prend fin sur demande explicite d’un des participants.
Request/Reply : Ce mode est également synchrone, impliquant par consé- quent la disponibilité des deux partenaires. C’est le mode d’implémentation des appels de fonctions distantes (RPC). Une application appelle une fonc- tion qui s’exécute à distance, de manière transparente. L’application appe- lante reste bloquée le temps d’exécution de la requête.
Message Passing : A l’inverse des deux modes précédents, ici l’échange est généralement unidirectionnel et jamais bloquant, elle prend la forme d’un échange de message, de la même manière que l’émission d’une lettre. Ce mode étant sans connexion, la disponibilité du destinataire à l’instant de l’émission n’est pas nécessaire.
Message Queuing : Ce mode est très similaire au mode précédent, il en est une implémentation “sécurisée”. Entre l’émission et la réception, le messa- ge est stocké sur disque. Comme précédemment, la disponibilité du desti- nataire au moment de l’émission n’est pas nécessaire puisque le paradigme de base est sans connexion.
Publish-and-Subscribe : C’est le troisième mode mettant en œuvre l’échange de messages. Ici l’échange n’est plus 1 à 1 mais 1 vers N. Un mes- sage est envoyé par un émetteur à plusieurs destinataires. Ce modèle repo- se sur un échange de messages et présente donc les avantages liés au modèle sans connexion.
7 Exemple : tous les ordres de paiement de moins de 10 000 F sont routés vers tel réseau de compensation, ceux de plus de 10 000 F vers tel autre : le routage dépend du contenu du message.
Ce type d’architecture a néanmoins un défaut important : il n’enraye pas le syn- drome spaghetti puisque finalement les applications dialoguent toujours en point à point. Un réseau de ce type est donc très rapidement complexe (N nœuds don- nent N*(N-1) flux possibles !), et s’avère rapidement très difficile à administrer.
Une solution, tout d’abord introduite par Tibco dans son MOM Tib’RendezVous, consiste à publier des messages en multi-point. C’est la notion de Publish and Subscribe. Les technologies actuelles permettent de réaliser deux modes de Publish and Subscribe :
• Mode Décentralisé
L’initiative du Publish et du Subscribe revient aux applications. Elles utili- sent des verbes de publication de type mq_put(domaine de publication, message). Les applications réceptrices s’abonnent avec des verbes de type mq_subscribe(domaine_de_publication). Tibco, et plus récemment IBM MQSeries 5.1 et MSMQ2000 (COM+) implémentent ces fonction- nalités. Les domaines de publication sont des chaînes de caractères du type domaine.sous-domaine.sous-domaine.etc., il est possible de s’abonner à un domaine précis ou à un ensemble de domaine (domai- ne.*).
• Mode Centralisé
Dans ce mode, les applications n’ont pas l’initiative de la publication ou de la souscription. Celle-ci revient à un Hub centralisé par lequel passent tous les messages. Dans ce mode, le Hub est un Message Broker : MQSeries Integrator (IBM), Mercator (TSI), Tib/MessageBroker (Tibco), etc. C’est l’administrateur du Hub qui décrit les règles de routage de cha- cun des flux. Ces règles peuvent se fonder sur la file d’attente de récep- tion, mais aussi sur le contenu même du message7, on parle alors de content-based routing.
Le schéma logique d’utilisation du Publish and Subscribe décentralisé ou cen- tralisé est le suivant :
Fi gu re 1 0: Le Mess age Broke r co mme d eu xièm e b riq ue de l’EA I
La différence fondamentale entre les 2 modes réside dans le fait que, pour le premier mode, les applications embarquent du code pour publier et s’abonner.
Dans l’autre mode, les applications publient sur des files d’attente du Hub.
Elles utilisent encore l’API mq_put/mq_get du MOM comme dans le cas du point à point, mais uniquement pour communiquer avec le Hub : N applica- tions génèrent N flux possibles (configuration en étoile vers le Hub).
Les deux modes du modèles Publish
& Subscribe : centralisé et décentralisé.
Concrètement, le publish/subscribe décentralisé s’applique à l’échelle d’une application(par exemple une application de Front Office qui “s’abonne”
à telle cotation de titres), mais n’est pas adapté à une architecture EAI à l’échelle de l’entreprise étendue. Pour cela, le Publish/Subscribe centralisé, à l’aide d’un Message Broker, va permettre d’assurer au niveau central un cer- tain nombre de services additionnels tels que les transformations de mes- sages, les passerelles vers d’autres systèmes ou middlewares, ainsi que la gestion de processus complexe. Ces servicesvont permettre de diminuer la part de code nécessaire à la communication dans les applications.
2.3. Les services fondamentaux de l’EAI
Dans une architecture EAI centralisée sur un ou plusieurs “Hubs”, il est pos- sible (voire conseillé !) d’implémenter des services à valeur ajoutée pour trai- ter les messages reçus. Nous allons donc détailler ici les services de forma- tage, les passerelleset la gestion de processus.
■2.3.1. Transformations et connecteurs
Comme nous l’avons présenté dans l’analyse de la communication entre deux systèmes, l’une des phases concerne le formatage des données envoyées. Par exemple, si une application A envoie tous les soirs à l’application B la liste des clients qu’elle gère, les deux applications devront s’accorder sur un format.
Exemple : un fichier où chaque enregistrement est formaté en “pas fixe” :
Généralement, pour arriver à ce fichier, il aura fallu extraire la donnée de l’ap- plication, puis développer un programme, en Shell, en C, en Perl, etc. géné- rant le fichier au bon format.
Indépendamment de cette première extraction, certaines applications desti- natrices de cette information pourront l’attendre sous un format différent, par exemple :
Dans une architecture à base de Message Broker, il est possible d’externaliser totalement cette étape de transformation au niveau du broker. L’intérêt est multiple :
•Le développement est facilité par l’utilisation de l’éditeur de formats, qui est en fait un AGL dédié à la conception de règles de formatage.
En particulier, l’outil va permettre de “parser” des messages, de définir des champs, d’appliquer plusieurs règles sur un champ, de réorganiser les champs, etc. pour produire un nouveau message.
•Les règles de transformation sont centralisées, les compétences néces- saires minimisées.
Le développement de ces modules n’est plus à la charge des projets
0 1 2 3 4
01234567890123456789012345678901234567890 0012670000DUPONT Gérard
0012671000DURANT Gabriel ...
<CLIENT><ID>0012670000</ID><NAME>DUPONT</NAME>
<FIRSTNAME>Gerard</FIRSTNAME></CLIENT>
<CLIENT><ID>0012671000</ID><NAME>DURANT</NAME>
<FIRSTNAME>Gabriel</FIRSTNAME></CLIENT>
...
Le mode centralisé du modèle Publish &
Subscribe est adapté à la problématique d’EAI.
Les éditeurs de format sont de puissants outils dédiés à la description sémantique des messages.
applicatifs, mais devient l’affaire d’une équipe dédiée à la gestion des flux. Un référentiel de “méta-données” décrivant les données de l’entre- prise est constitué.
•Le système, dédié à cette tâche, est beaucoup plus robuste que la somme des interfaces précédemment utilisées.
F igur e 11: E xem pl e de re fo rmata ge d’ un flu x d ’i nf or mation
Au-delà de cette possibilité de développement, un des grands intérêts des Message Broker du marché réside dans la disponibilité de connecteurs stan- dards. Un connecteur est un ensemble de règles de formatage destiné à inter- facer des messages vers :
•des ERP8 : SAP, PeopleSoft, JD-Edwards, Baan, Oracle Applications, etc.
•des formats standardisés
■finance : clearing Swift, Fix, CHAPS, EuroClear, ...
■industrie, santé : réseaux EDIFACT, X.12 EDI, HL7, ...
■autres domaines : télécom, transports, énergie, ...
•des progiciels orientés métier: facturation (Kenan, BSCS, etc.), gestion de la relation client (Siebel, Vantive, Clarify, Remedy, etc.), ...
•des formats techniques: XML, SGML, copy book COBOL, …
Ces connecteurs réduisent considérablement l’effort nécessaire à l’intégration de ces progiciels ou réseaux à valeur ajoutée dans le Système d’Information.
Cette économie est d’autant plus intéressante à long terme que la mainte- nance est garantie par l’éditeur. Celle-ci, à défaut d’être gratuite, permet une réelle maîtrise des coûts d’évolution du SI.
Reprenons l’exemple du chapitre 2, et comparons par exemple l’effort initial puis récurrent nécessaire à l’intégration de l’ERP avec le reste du SI : le déve- loppement des nombreux scripts d’import/export9, de transformation et de transport est remplacé par la mise en œuvre de produitset leur paramétra- ge. De plus, la compatibilité de ces produits avec les futures versions des pro- giciels est garantie par l’éditeur. Ce point est fondamental, car même si les coûts de maintenance du Message Broker ne sont pas négligeables, ils sont connus. Ce qui n’est pas forcément le cas pour des projets de maintenance nécessitant du développement interne.
Le schéma suivant positionne le service dans l’architecture, les transforma- tions sont développées au niveau du Message Broker, où des connecteurs
8 Enterprise Resource Planing : progiciel de gestion intégré
9 Notamment écrits avec les langages et interfaces proposés par l’ERP. Les compétences sur ces technologies étant très rares, elles sont forcément coûteuses.
Les connecteurs standards (formats prédéfinis) augmentent fortement la
productivité et la maintenabilité d’une solution EAI.
fournis par l’éditeur peuvent cohabiter :
F ig ur e 12: Les co nnec te urs c omme tro isième bri qu e d e l’EA I
Pour les nouvelles applications, il est important de ne pas continuer à réin- venter différents types de formats pour désigner le même type d’événement.
En ce sens, l’introduction d’un format pivot, dontXMLpourrait constituer l’im- plémentation, est fondamentale pour limiter le volume des transformations.
Le format pivot va définir de manière unique dans l’entreprise la représenta- tion d’une donnée métier : un client, un paiement, une commande de produit, un achat de titres, une compensation, etc.
Certains éditeurs ont bien perçu ce besoin, généralement ceux qui ont une approche “top-down”, c’est à dire avant tout une vision métier, qu’ils implémen- tent ensuite eux-mêmes. Le principe est beau... mais structurant !
Avant de standardiser toute l’entreprise, une approche incrémentale devra être a d o p t é e .
X ML : la s ol utio n de l ’i nt er opér abil it é
Quand on parle de commerce électronique, l’image qui se dégage est celle d’un site Web où l’on peut acheter des biens et des services.
Ce commerce électronique, appelé Business to Consumer (BtoC) ne repré- sente en fait qu’environ 30% du chiffre d’affaire de ce secteur.
Où sont donc passés les 70% restants ?
Réponse : dans le commerce inter-entrerprises (Business to Business, BtoB)... et encore peu sur Internet.
Jusqu’à présent, les entreprises utilisait l’EDI (Electronic Data Interchange) pour se connecter avec leurs fournisseurs et leurs clients.
Mettant en œuvre des connexions de type point à point sur des réseaux pri- vés (ou public) de type X.400, ces solutions se sont avérées coûteuses et complexes. Seules de grandes entreprises ont pu investir et proposer (impo- ser... !) ce type de système à leurs prestataires.
Aujourd’hui, les technologies Internet et le standard XML sont des alterna- tives beaucoup plus simples et économiques, permettant à une multitude de nouveaux acteurs d’y participer.
En fait, cette migration du trafic EDI vers des flux XML sur l’Internet va pro- longer la vie des systèmes existants et répondre aux besoins d’intégration de tous les partenaires (fournisseurs, clients, tiers,...) de manière beaucoup plus ouverte.
Point clef de l’étape de formatage : passer par un format pivot .
L’exemple suivant donne une idée de la codification XML pour un échange EDI, ici la commande d’un livre:
<?xml version=»1.0» encoding=»ISO-8859-1» standalone=»no»?>
<?xml-stylesheet href=»edi-lite.xsl» type=»text/xsl»>
<!DOCTYPEBook-Order SYSTEM «edi-lite.dtd»>
<Title>EDITEUR Lite-EDI Book Ordering</Title>
<Order-No>967634</Order-No>
<Message-Date>19990308</Message-Date>
<Buyer-EAN>5412345000176</Buyer-EAN>
<Order-Line Reference-No=»0528835»>
<ISBN>0201403943</ISBN>
<Author-Title>Bryan, Martin/SGML and HTML Explained</Author-Title>
<Quantity>1</Quantity>
</Order-Line>
<Order-Line Reference-No=»0528836»>
<ISBN>0856674427</ISBN>
<Author-Title>Light, Richard/Presenting XML</Author-Title>
<Quantity>1</Quantity>
</Order-Line>
</Book-Order>
XML représente un élément fédérateur important de l’EEI (Intégration Extra Entreprise). Il permet aux compagnies de définir, pour les messages qui vont constituer les flux entre les systèmes, des dictionnaires standards partagés par les fournisseurs et des tiers tels que les portails ou les systèmes de paie- ment. Des éditeurs de solutions de commerce électronique intégrent de plus en plus des composants d’accès standards aux catalogues des fournisseurs.
Par exemple, le dictionnaire “Common Commerce Library” de CommerceOne définit au format XML des objets et des transactions génériques élémen- taires. Ariba annonce Commerce XML (cXML) qui est un ensemble de DTD allégées pour des informations de catalogues et de transactions d’achat.
Parmi les initiatives de normalisation en cours, BizTalk de Microsoft offrira des DTD pour tous les types de flux (commandes, personnel, comptabilité,...) entre les principaux ERP (SAP, PeopleSoft).
Les éditeurs de progiciels intégrés n’ont pas attendu les organismes de stan- dardisation et proposent déjà des solutions d’interopérabilité inter entreprise basées sur l’emploi du format XML. C’est le cas notamment de SAP dont le dernier module SAP B2B Procurement permet l’intégration dans le SI d’une entreprise des catalogues de ses fournisseurs. Les éditeurs profitent de la flexibilité et de la puissance de cette technologie à l’intérieur même de leurs produits. En outre, la plupart des Message Brokers proposent une intégration forte avec le format XML.
L’int ég r at io n d es tec hn olo gie s Int er ne t d ans SA P En conclusion, XML n’invente rien de nouveau, il démocratise simplement les technologies de l’EDI.
■ 2.3.2. Passerelles techniques
La capacité d’une architecture EAI à adresser l’ensemble de la problématique de l’entreprise repose bien entendu sur ses possibilités d’interfaçage avec les systèmes existants.
Ceux-ci sont généralement divers et variés, le champ est donc vaste. Les MOM et Message Brokers du marché proposent en standard des interfaces vers :
•des SGBDR : Oracle, DB2, SQLServer, Sybase, Informix, etc,
•des moniteurs TP : Tuxedo, CICS, IMS,
•des serveurs d’applications : WebSphere, Oracle Application Server, WebLogic, MTS, Inprise Application Server, etc,
•du transfert de fichiers : avec la notion de conversion message vers fichier et fichier vers message,
•d’autres MOM(MQSeries, MSMQ, BEA MessageQ).
l L’accès aux SGBDR
Se connecter à des sources de données relationnelles est fondamental pour :
•Mettre à jour des données sur arrivée de message,
Par exemple, à l’arrivée d’un message, une table est mise à jour avec les données contenues dans le message.
•Envoyer des messages sur modification de données,
Par exemple, sur modification d’un enregistrement dans la base, un message est émis.
•Utiliser des données externes au niveau du Message Broker pour réaliser une transformation. On parle alors d’enrichissement par des accès à des tables de références croisées.
Par exemple, à l’arrivée d’un message contenant un clientID, celui-ci va être transformé en un autre clientID compatible avec l’application desti- natrice, au travers d’une table de translation.
Fi gu re 1 3: P asse relle a ve c les S GBDR
Les deux premiers points vont nécessiter l’utilisation d’une passerelle entre le MOM et le SGBDR. Suivant les technologies, ces passerelles sont fournies par l’un ou l’autre des éditeurs. A titre d’exemple, Oracle propose sa technologie Oracle Gateways pour s’interfacer à MQSeries. Tibco fournit quant à lui sa propre solution d’interfaçage aux dernières versions d’Oracle (Tib/Connect for Oracle).
Ces passerelles permettent de déclencher des ordres SQL ou des procédures
Trois interactions pos- sibles avec les SGBDR : en entrée, en sortie, et en lecture.
