COSMOBAY - Livre Blanc Eai - Tres Complet

EAI
De l’intégration à l’e-business
François Rivard Novembre 2000

consultant senior
Tél : +33 1 53 24 67 80
frivard@cosmosbay.com
Jean-Christophe Bernadac
directeur technique
Tél : +33 4 72 65 21 00
jcbernadac@cosmosbay.com
François Knab
vice-président
Tél : +33 1 53 24 67 80
fknab@cosmosbay.com
Avec le concours
de François Bourcier
EAI
EAI De l’intégration à l’e-business / T a b l e d e s m a t i è r e s
Table des matières

Table des matières ................................................................................................................................................................................................... 4
1 VUE D’ENSEMBLE : LE SYSTÈME D’INFORMATION E-BUSINESS 7
Fédérer, unifier, s’adapter ..................................................................................................................................................................................................... 8
Mettre en œuvre un système intégré ................................................................................................................................................................................... 9

Recréer un système d’information intégré ................................................................................................................................................................................ 9
Généraliser les passerelles interapplicatives ............................................................................................................................................................................ 9
Fédérer les systèmes .................................................................................................................................................................................................................... 10
Domaines d’application ......................................................................................................................................................................................................... 11

Gestion de la chaîne logistique ................................................................................................................................................................................................... 11
Gestion de la relation client ......................................................................................................................................................................................................... 11
e-marketplaces ............................................................................................................................................................................................................................. 12
De l’intégration à l’e-business ............................................................................................................................................................................................. 13
2 LE MODÈLE EAI 16
Transport : un middleware pour les données ..................................................................................................................................................................... 16

Définition ........................................................................................................................................................................................................................................ 16
Fonctionnalités et technologies .................................................................................................................................................................................................. 16
Couche plate-forme et EAI .......................................................................................................................................................................................................... 19
Données : les adaptateurs applicatifs ................................................................................................................................................................................. 19
4 Définition ....................................................................................................................................................................................................................................... 19
Couche données et EAI ................................................................................................................................................................................................................ 20
Composants : appliquer la logique d’entreprise ............................................................................................................................................................... 21
Moteur d’intégration : le cœur du système d’e-business ................................................................................................................................................ 23

Définition ........................................................................................................................................................................................................................................ 23
Fonctionnalités .............................................................................................................................................................................................................................. 23
Technologies : les message brokers .......................................................................................................................................................................................... 24
Couche moteur d’intégration et EAI ........................................................................................................................................................................................... 26
3 DE L’EAI À L’INTÉGRATION ÉTENDUE 27
Processus : modélisation métier .......................................................................................................................................................................................... 27

Définition ....................................................................................................................................................................................................................................... 27
Couche processus et eAI ............................................................................................................................................................................................................. 29
B2B : eAI ou l’intégration étendue ....................................................................................................................................................................................... 29

Définition ....................................................................................................................................................................................................................................... 29
Couche B2B et eAI ........................................................................................................................................................................................................................ 31
4 XML ET L’EAI 33
XML et les six couches du modèle eAI ............................................................................................................................................................................... 33

XML et transport .......................................................................................................................................................................................................................... 33
XML et connecteurs ..................................................................................................................................................................................................................... 34
XML et composants ...................................................................................................................................................................................................................... 34
XML et moteur d’intégration : les serveurs d’applications .................................................................................................................................................... 34
XML, composants métier et workflow ...................................................................................................................................................................................... 36
XML et B2B ................................................................................................................................................................................................................................... 37
XML, langage privilégié de l’échange B2B ........................................................................................................................................................................ 37

cXML, d’Ariba Software ............................................................................................................................................................................................................... 38
xCBL, de Commerce One ............................................................................................................................................................................................................. 38
OBI, de CommerceNet ................................................................................................................................................................................................................. 38
eCo, de CommerceNet ................................................................................................................................................................................................................. 39
ebXML, de l’UN/Cefact et Oasis ................................................................................................................................................................................................. 39
BizTalk, de Microsoft .................................................................................................................................................................................................................... 41
RosettaNet ...................................................................................................................................................................................................................................... 42
Autres initiatives ........................................................................................................................................................................................................................... 43
En résumé… ................................................................................................................................................................................................................................. 43
Une architecture alternative d’EAI bâtie sur XML ............................................................................................................................................................. 43

Applications front-office ............................................................................................................................................................................................................... 44
Table des matières
Sources de données ..................................................................................................................................................................................................................... 45

Moteur d’intégration ..................................................................................................................................................................................................................... 46
Référentiel de synchronisation .................................................................................................................................................................................................... 46
5 MARCHÉ DE L’EAI ET OFFRES DES ÉDITEURS 48
Panorama du marché de l’EAI ............................................................................................................................................................................................... 48

Quelques chiffres ........................................................................................................................................................................................................................... 48
Tendances ....................................................................................................................................................................................................................................... 48
Les offres ....................................................................................................................................................................................................................................... 49
Organisation des fiches produits ................................................................................................................................................................................................ 49
Candle ........................................................................................................................................................................................................................................ 51
Présentation de la société ............................................................................................................................................................................................................ 51
Architecture technique du produit .............................................................................................................................................................................................. 51
Le modèle EAI de Candle ............................................................................................................................................................................................................. 52
Synthèse ......................................................................................................................................................................................................................................... 54
Constellar .................................................................................................................................................................................................................................. 55
Présentation du produit ................................................................................................................................................................................................................ 55
Le modèle EAI de Constellar ........................................................................................................................................................................................................ 56
Synthèse ........................................................................................................................................................................................................................................ 58
Level 8 ....................................................................................................................................................................................................................................... 59
Présentation de la société ............................................................................................................................................................................................................ 59 5
Le modèle EAI de Level 8 ............................................................................................................................................................................................................ 60
Synthèse ......................................................................................................................................................................................................................................... 62
Mercator Software ................................................................................................................................................................................................................... 63

Présentation du produit ................................................................................................................................................................................................................ 63
Le modèle EAI de Mercator ......................................................................................................................................................................................................... 64
Synthèse ......................................................................................................................................................................................................................................... 66
Neon (New Era of Networks) .................................................................................................................................................................................................. 67

Le modèle EAI de Neon ................................................................................................................................................................................................................ 68
Synthèse ......................................................................................................................................................................................................................................... 70
STC (Software Technology Corporation) .............................................................................................................................................................................. 71

Le modèle EAI de STC e*Gate 4 ................................................................................................................................................................................................. 72
Synthèse ........................................................................................................................................................................................................................................ 75
Tibco Software .......................................................................................................................................................................................................................... 76

Le modèle EAI de Tibco ............................................................................................................................................................................................................... 77
Synthèse ......................................................................................................................................................................................................................................... 79
Viewlocity .................................................................................................................................................................................................................................. 80
Le modèle EAI de Viewlocity ....................................................................................................................................................................................................... 81
Synthèse ......................................................................................................................................................................................................................................... 82
Vignette-OnDisplay .................................................................................................................................................................................................................. 83
Présentation de la société ........................................................................................................................................................................................................... 83
Le modèle EAI de Vignette-OnDisplay ........................................................................................................................................................................................ 84
Synthèse ........................................................................................................................................................................................................................................ 85
webMethods .............................................................................................................................................................................................................................. 86
Présentation ................................................................................................................................................................................................................................... 86
Le modèle EAI de webMethods ................................................................................................................................................................................................... 87
Synthèse ......................................................................................................................................................................................................................................... 89
6 CONCLUSION 90
6
Vue d’ensemble
C H A P I T R E
Vue d’ensemble
Le système d’information e-business
Dans l’entreprise, les développements ont longtemps été pensés et budgétés à un niveau départemental. Cette situation corres-
pondait au succès des technologies client-serveur et au besoin de constituer des applications légères s’appuyant sur leur propre
base de données et sachant exploiter le confort procuré par un réseau local. Les réponses apportées aux besoins de l’entreprise en 7
matière de système d’information et de traitement des données étaient en partie guidées par les possibilités technologiques
disponibles au moment de la conception de ces systèmes départementaux.
Depuis quelques années déjà, Internet met ce modèle en cause. Plusieurs facteurs récents définissent de nouveaux enjeux et
élargissent le périmètre du besoin :
• La mondialisation de l’économie – Les changements incessants de la nature des marchés, des pratiques commerciales, des
législations nécessitent une réactivité accrue de la part de l’entreprise à tous les niveaux de son organisation.
• La réduction du time-to-market et l’avantage concurrentiel procuré par le fait d’être le first-to-market – Devant la banali-
sation des produits et l’érosion de la fidélité des clients, la stratégie Internet d’une entreprise devient un facteur non négligeable
de sa réussite commerciale et doit être focalisée sur la fidélisation de sa clientèle et sur la différenciation de sa marque.
• La croissance externe et les stratégies de partenariat – Elle sont précédées d’études désormais stratégiques sur la flexibilité
du système d’information des entreprises concernées. Lorsque deux systèmes d’information fusionnent, il est indispensable
de maintenir un existant opérationnel tout en amorçant la transition vers une consolidation des données. Les acteurs disposent
ainsi d’informations fédérées d’aide à la décision assurant la cohérence d’une stratégie partenariale et accompagnant la
démarche commerciale et opérationnelle.
Ces nouveaux enjeux convergent tous vers la généralisation des besoins d’intégration. Qu’il s’agisse de la production (ERP,
Enterprise Resource Planning), de la logistique (SCM, Supply Chain Management) ou de la relation client (CRM, Customer
Relationship Management), la chaîne de valeur d’une entreprise se conçoit dans sa globalité et non plus au niveau départemental.
L’ensemble des données d’une entreprise (clients, fournisseurs, produits, utilisateurs, etc.) doivent pouvoir évoluer en offrant la
garantie de leur cohérence. Cet objectif conduit naturellement à la mise en œuvre de référentiels d’entreprise : l’émergence des méta-
annuaires l’illustre parfaitement.
Pour autant, il n’est pas concevable de se lancer dans une refonte globale du système d’information. D’une part, l’expérience a
prouvé que bon nombre de projets aussi volumineux présentaient un risque d’échec important s’ils n’étaient pas découpés en sous-
projets de taille plus raisonnable, chacun d’eux étant mis en œuvre progressivement. D’autre part, la réduction du cycle de vie des
projets, liée au modèle économique d’Internet, et le besoin de mettre rapidement en application une politique d’e-business
nécessitent de s’appuyer sur tout ou partie du système d’information existant.
Cette exploitation des données et des applications de l’entreprise doit s’affranchir des rigidités inhérentes aux spécificités de ces
systèmes et à leur hétérogénéité. Le système résultant doit être en mesure de réagir efficacement au changement, qui est le nouveau
défi permanent lancé à l’entreprise. Toute modification du contexte économique et concurrentiel doit être absorbée sereinement par
le système d’information de l’entreprise. Les travaux d’adaptation et d’évolution ne doivent entraîner aucune instabilité, même
temporaire, car le facteur Internet impose la disponibilité permanente des systèmes de commerce électronique.
EAI De l’intégration à l’e-business / V u e d ’ e n s e m b l e
Ayant été conçu sans une vision d’ensemble des besoins de l’entreprise, un système départemental ne peut pas servir de fondement
à un projet d’e-business : le système d’information doit désormais être pensé à l’échelle de l’entreprise, afin d’atteindre une logique
d’unification et de communication globale. Bien sûr, tout au long de cette démarche, il faut accorder un soin particulier à la flexibilité
et à l’interopérabilité des éléments d’infrastructure qui constitueront le système fédéré. Les principales technologies mises en œuvre
dans les projets d’intégration répondent à ces exigences et s’appuient aujourd’hui, pour étendre l’intégration aux partenaires de
l’entreprise, sur l’apport des technologies d’Internet, notamment de leur champion : XML (eXtensible Markup Language).
Fédérer, unifier, s’adapter

Les mots-clés régissant l’infrastructure d’un système intégré sont fédération, unification et adaptation.
• La fédération est la démarche qui privilégie la réutilisation des sources de données et des règles métier existant dans l’entre-
prise.
• L’unification est la mise en place de processus métier d’entreprise coordonnant les sources de données et les applications entre
elles.
• L’adaptation est la capacité du système à prendre en compte de nouveaux processus métier ou de nouvelles applications et à
modifier les processus et les applications existants.
Un système conçu dans cet esprit peut être qualifié de système d’e-business. Examinons à l’aide d’un exemple les bénéfices de cette
8 démarche d’intégration.
L’entreprise Brique et Mortier étend son activité au Web dans le but d’y vendre ses produits. Après chaque commande effectuée en
ligne par un internaute, les opérateurs du site reçoivent l’information par e-mail et éditent un bon de commande papier. Ce bon de
commande est transmis par courrier interne au responsable logistique, qui vérifie l’état des stocks au moyen de l’interface de son
progiciel de gestion intégré (ERP). Constatant l’indisponibilité du produit, il décide de s’adresser à son fournisseur par le biais du
logiciel d’approvisionnement spécifique qu’il utilise depuis plusieurs années. Le fournisseur transmet la date de réception du produit
aux opérateurs du site web, qui se chargent d’en informer le client en répondant à son e-mail de commande après y avoir ajouté le
délai de livraison.
Dans cet exemple, les intermédiaires et les sources de données se multiplient, et donc les incohérences et les sources d’erreur aussi.
Par exemple, les désignations des produits sont en théorie identiques dans l’ERP et dans le logiciel d’approvisionnement spécifique,
mais dans la pratique un contrôle humain est indispensable pour garantir la cohérence. Dans ce contexte, il est difficile de tenir les
engagements pris auprès des clients sur les délais de livraison.
Ce scénario illustre les limites d’une approche départementale cloisonnée ; il montre que l’entreprise doit s’interroger sur les moyens
à mobiliser pour prolonger efficacement son activité sur le Web. Pour Brique et Mortier, les enjeux sont l’amélioration de la coordi-
nation entre ses différents départements et l’optimisation de la relation avec ses fournisseurs. Cela implique une communication
« dématérialisée » entre les applications engagées dans le processus de vente en ligne. Une démarche d’intégration du système
d’information est indispensable pour doter Brique et Mortier d’une infrastructure informatique capable d’accompagner sa stratégie
e-business.
Envisageons maintenant un système dans lequel les applications sont interconnectées. L’arrivée d’une commande en provenance du
site Internet déclenche un processus métier pilotant l’interrogation de l’application logistique pour vérifier la disponibilité des
produits, puis la transmission des informations à l’application d’approvisionnement pour alimentation automatique du stock.
Lorsque le stock doit être reconstitué, le fournisseur contacté transmet en retour le délai d’approvisionnement. L’internaute est alors
informé du meilleur délai de livraison qui peut lui être proposé.
Dans le même esprit, plusieurs fournisseurs peuvent être mis en concurrence pour servir la demande de l’internaute. Le rapport
délais-coût est ainsi optimisé. Enfin, chaque fournisseur doit pouvoir informer le site marchand de la disponibilité de ses produits
et de ses offres promotionnelles pour agencer au mieux le catalogue en ligne proposé aux internautes. L’automatisation complète
reste une hypothèse de travail car dans la pratique, une intervention humaine demeure indispensable en certains points du processus
de vente et de livraison. Les bénéfices sont néanmoins réels : on observe en effet que la mise en œuvre de systèmes d’achats
intégrés peut réduire de 85 % les coûts habituellement liés à ces opérations.
Vue d’ensemble
Mettre en œuvre un système intégré

Les trois logiques suivantes peuvent guider la démarche d’implémentation d’un système intégré :
• récréer un système d’information intégré ;
• généraliser les passerelles interapplicatives ;
• fédérer les systèmes.
Recréer un système d’information intégré

Cette approche conduit habituellement en une migration de l’existant vers un nouveau système et a donc des conséquences
importantes sur les coûts et les délais. Face aux changements permanents et aux fortes contraintes du marché, la refonte d’un
système d’information se justifie en général plus par son obsolescence que par le seul besoin d’intégration. Cette logique mène
naturellement à la mise en œuvre de progiciels qui sont intégrés par essence et qui disposent d’ouvertures sur les technologies
Internet nécessaires à l’implémentation de services d’e-business.
Le tout-intégré est séduisant car il libère de l’hétérogénéité des systèmes et garantit l’interopérabilité des différents services métier
offerts, dont la gestion de production (ERP), l’optimisation de la chaîne logistique (SCM) et la gestion de la relation client (CRM).
Cette approche rend cependant l’évolutivité du système d’information dépendante des services et des technologies Internet définis
dans la stratégie produit de l’éditeur du progiciel. Cette démarche d’intégration n’incite pas à la réalisation d’un système flexible 9
susceptible, le cas échéant, de coopérer facilement avec les outils concurrents adoptés par les partenaires de l’établissement.
L’entreprise qui prend la décision de recréer un système d’information intégré doit veiller à garantir l’ouverture et la flexibilité des
applications mises en œuvre en vue d’en assurer la pérennité.
Généraliser les passerelles interapplicatives

Les entreprises disposant d’un existant pérenne peuvent être tentées de résoudre leur problématique d’intégration en mettant en
œuvre des passerelles point à point, en général à travers un développement spécifique fondé sur un middleware adapté.
Les problématiques d’intégration ont souvent été résolues par ce type de développements. L’interconnexion de systèmes départe-
mentaux qui en résulte aboutit rarement à un système d’information global et cohérent, pour des raisons de temps, de coûts et
parfois de faisabilité technique. Dans de nombreux cas, le résultat final de cette démarche est une écrasante complexité et une totale
opacité. Les projets sont difficiles à terminer, puis à maintenir. La solution apportée freine les possibilités d’intégration de nouvelles
fonctionnalités ou de remplacement des briques existantes.
Le Gartner Group qualifie ce type de solution de système « spaghetti ».
Applications Applications
légataires spécifiques
SCM CRM
ERP E-commerce
Figure 1 – Système « spaghetti »

Par rapport à la logique de développement d’un nouveau système, cette implémentation a l’avantage de s’appuyer sur l’existant. En
revanche, la solution résultante est rigide, ses frais de maintenance et ses coûts totaux de changement (TCC, Total Cost of Change)
explosent rapidement. Si n est le nombre d’applications à interconnecter, le nombre de passerelles bidirectionnelles à développer
pour aboutir à un système complètement communicant est n (n – 1). Pour 6 applications, il faut donc 30 passerelles… De plus, le
remplacement d’une application par une nouvelle version ou par une application d’un autre éditeur risque fort de rendre la passerelle
obsolète ou d’entraîner des travaux de maintenance complexes et coûteux : l’équipe de développement initiale n’est plus forcément
disponible et la documentation technique est parfois insuffisante pour permettre la reprise des développements. Dans certains cas,
la passerelle devient incontournable et retarde le remplacement de l’application obsolète.
En résumé et d’après le cabinet Forrester Research, les entreprises confrontées à un environnement en constant changement
consacrent jusqu’à 40 % de leur budget informatique annuel au remodelage des flux d’informations entre leurs différents systèmes
et applications. Le chantier d’intégration est donc un poste important du budget informatique des entreprises ; sa bonne utilisation
doit privilégier la flexibilité et la pérennité du système intégré.
Fédérer les systèmes

Préserver l’existant tout en assurant la flexibilité et l’évolutivité du système intégré sont les fondements des plates-formes d’inté-
gration. Ces plates-formes proposent des outils capables de se connecter aux sources de données et aux applications existantes
d’une entreprise et d’échanger des informations de l’une à l’autre. Ces outils autorisent la mise en application d’une démarche de
10 fédération du système d’information nommée EAI (Enterprise Application Integration, intégration des applications d’entreprise).
L’EAI est un processus graduel, logique et répétitif qui permet à une entreprise de passer du système « spaghetti » à une architecture
modulaire dans laquelle les applications peuvent être modifiées séparément sans impact sur le système existant. La démarche d’EAI
permet de mettre le client au centre du système d’information en lui fournissant l’ensemble des fonctionnalités et des données dont
il a besoin en temps et en heure. On parle d’architecture hub-and-spokes (à moyeu et à rayons) ou d’architecture soleil.
Applications Applications
légataires spécifiques
Solution
d'EAI
SCM ERP CRM E-commerce
Applications packagées
Figure 2 – Système d’e-business hub-and-spokes (à moyeu et à rayons)

Vue d’ensemble
La concrétisation d’une démarche d’EAI peut représenter un défi technique au coût non négligeable. Mais les avantages procurés
par ces outils dans la mise en œuvre du système d’e-business (fluidification des échanges d’information, modélisation des
processus métier, flexibilité et réactivité au changement) et l’évolutivité de ces plates-formes dans le cadre de l’intégration de
nouvelles applications garantissent un retour sur investissement très rapide – en général après quelques mois d’exploitation. Les
plates-formes d’EAI conduisent également à une industrialisation des processus de conception, de développement et de déploiement
des applications, gage de la pérennité des systèmes intégrés ainsi réalisés.
En résumé, tout concourt à privilégier la démarche d’EAI dans le processus d’évolution d’un système d’information vers l’e-business.
Domaines d’application
Les bénéfices de la démarche d’EAI couvrent toute la chaîne de valeur de l’entreprise et l’accompagnent dans l’application de sa
stratégie d’e-business. Cette démarche est un facteur de réussite important dans les domaines de la gestion de la chaîne logistique
(SCM), de la gestion de la relation client (CRM) et des places de marché sur Internet (e-marketplaces).
Gestion de la chaîne logistique

La gestion de la chaîne logistique (SCM) désigne un ensemble d’échanges entre partenaires et leur coordination. Il s’agit d’une
approche globale qui couvre tous les aspects logistiques de l’entreprise, depuis la planification des ressources jusqu’à la livraison
des produits, en passant par les prévisions, la conception et la fabrication. 11
Ce type de besoin concerne tout particulièrement les entreprises dont la croissance s’est effectuée par fusions ou acquisitions et qui
ne disposent pas d’une infrastructure informatique centralisée. Il émane aussi d’entreprises soucieuses, dans une optique d’entre-
prise étendue, d’intensifier leur collaboration avec leurs partenaires.
Une chaîne logistique intégrée est un facteur important d’amélioration du délai de mise sur le marché d’un produit ou d’un service.
Cette intégration permet un gain de temps dans les procédures d’achat et dans les prévisions de fabrication, grâce à un meilleur
contrôle du processus global de production. Cette démarche conduit naturellement à une meilleure productivité, à une réduction des
coûts et, parallèlement, à l’amélioration de la qualité du service rendu au client.
Une chaîne logistique intégrée rend possible le pilotage de la production par la demande. C’est le modèle build-to-order, qui permet
à une entreprise de réduire ses coûts de stockage et d’inventaire et de s’adapter sans difficulté à une modification imprévue de la
demande. L’organisation doit bien sûr refléter ce modèle de flexibilité pour en garantir l’efficacité et assurer la satisfaction du client
final par une offre synchronisée à la demande.
Le modèle du build-to-order est l’illustration du lien étroit qui existe entre la gestion de la chaîne logistique et celle de la relation
client. Le projet d’intégration répond alors pleinement à une problématique globale d’entreprise.
Gestion de la relation client

La gestion de la relation client (CRM) a pour objectif d’améliorer la satisfaction et la fidélité des clients. Le développement d’appli-
cations CRM nécessite une démarche d’unification des informations dispersées dans l’entreprise pour constituer le référentiel client
(voir l’encadré « Le référentiel client »). Ce dernier s’enrichit d’informations fournies par des services traditionnellement mis en
œuvre au sein du back-office. Il faut donc bien penser l’intégration du projet CRM au système d’information et qualifier avec soin les
données qui constitueront le référentiel client.
Le besoin d’intégration se fait particulièrement sentir sur le plan de l’alimentation des services de gestion de la relation client. En
effet, le système CRM, situé à la croisée de domaines tels que la vente, le marketing et le support client, est un consommateur avide
d’informations consolidées. En aval, il peut également s’intégrer avec les applications de facturation et de comptabilité ou avec des
systèmes décisionnels.
Cette démarche d’intégration des informations client élargit le potentiel de personnalisation des services offerts. Ce potentiel se
manifeste lors de l’extension des activités de l’entreprise sur Internet. La personnalisation du contenu et des services est une
stratégie payante en matière de fidélisation des clients ; cette démarche rend possible la collecte d’un ensemble d’informations
indispensables à la connaissance du profil des internautes visitant le site. Cette application devient en effet un point de contact
privilégié avec des clients que l’entreprise ne verra peut-être jamais physiquement.
L’e-business est une forme d’intermédiation dans laquelle les informations sont présentées au client sans le concours des collabo-
rateurs du front-office. Ceux-ci, de par leur connaissance du métier, savent masquer la complexité des processus d’entreprise et ont
une appréhension « physique » du client qu’une application Internet ne peut pas avoir. L’application Internet doit comporter des
mécanismes permettant de créer cette connaissance à partir des informations fournies sur le site par le client.
Le référentiel client
Chaque application à intégrer (CRM, ERP, applications légataires, etc.) dispose d’une vue différente de l’entité client.
La constitution d’un référentiel client unifié est bien plus qu’une problématique technique car elle influe sur la définition même du client et
des processus métier qui l’utilisent. La fiabilité des informations échangées dépend à la fois du format des données et de l’application des
règles métier. Pour assurer la cohérence, il faut construire une vue unifiée du client en temps réel. Cette vue unifiée constitue le référentiel
client, indispensable aux applications CRM et point central des applications d’e-business construites sur le nouveau système.
12
e-marketplaces
Une place de marché est un point de liaison central destiné à réunir des centaines d’acheteurs et de vendeurs. Sur Internet, le concept
de place de marché se traduit par la mise en relation des systèmes d’information des entreprises au travers d’une intégration
« métier ». Ces places de marché sont généralement spécifiques à des industries, mais les besoins d’intégration sont similaires et
convergent aujourd’hui vers un certain nombre d’initiatives de normalisation. Ce nouveau modèle économique impose la prise en
compte de trois dimensions :
• La gestion des transactions, de la sécurité (cryptage et authentification des parties) et de l’infrastructure réseau –
Techniquement, les besoins sont proches de ceux de l’EAI interne à une entreprise : messaging, non-répudiation et sécurité.
• La gestion des fournisseurs et des catalogues – Il s’agit de la capacité à recruter des vendeurs, à collecter les catalogues
(sous tous formats, y compris papier) et à générer des catalogues normalisés.
• L’offre de services à valeur ajoutée – Ce sont des enchères, des appels d’offres, ou encore les services de logistique ou de
facturation électronique. La différenciation concurrentielle tient à l’originalité du modèle de services et à sa qualité. La partici-
pation financière des acteurs pourra être fixée au mois ou à la transaction.
On retrouve différents acteurs sur ce marché :
• Des éditeurs d’applications d’e-marketplace, comme i2 Technology et son produit TradeMatrix.
• Des éditeurs de progiciels comme SAP, avec mySAP.com ou Oracle, avec Oracle Exchange. La spécificité de ces offres est de
se connecter à leurs propres environnements logiciels.
• Des acteurs du B2B, comme Ariba Software ou Commerce One.
• Des acteurs de l’EAI qui, comme Tibco, enrichissent leur offre d’EAI initiale de modules complémentaires d’EIP (Enterprise
Information Portal) et de B2B.
Les solutions de places de marché sont en général créées à partir de technologies complémentaires. Par exemple, e2open.com est
une place de marché reliant les acteurs des industries informatique et électronique fondée sur B2B Commerce Platform, d’Ariba
Software, sur l’application d’e-marketplace TradeMatrix, d’i2 Technology, et sur WebSphere Commerce Suite, d’IBM.
EAI et EIP
La distinction entre EAI et EIP (Entreprise Information Portal) peut paraître floue dans la mesure où ces deux types de solutions se
connectent à des systèmes hétérogènes et à des sources de données variées. Cependant, l’EAI a pour objectif l’échange de données entre
applications, alors que l’EIP agrège les informations pour une application cible qui va se charger de les présenter à l’utilisateur final.
L’EIP a donc une finalité front-end marquée, alors que l’EAI est orientée back-end. En règle générale, ces deux solutions sont complémen-
taires et l’application d’EIP constitue le front-end du système d’information dont les données proviennent en partie de la plate-forme d’EAI.
L’e-marketplace est un réseau à valeur ajoutée dont la matérialisation tient autant de l’EIP que de l’eAI (l’extension sur Internet de l’inté-
gration d’applications).
Vue d’ensemble
Parmi les trois démarches de conception d’un système intégré que nous avons décrites précédemment, la démarche d’EAI est celle
qui permet de s’appuyer sur les applications existantes en se focalisant sur la flexibilité et l’adaptabilité du système résultant.
Par définition, la démarche d’EAI est un processus d’intégration d’applications développées indépendamment, utilisant des techno-
logies incompatibles et devant continuer à être gérées séparément. La flexibilité, l’évolutivité et l’adaptabilité, aujourd’hui indispen-
sables au maintien de la compétitivité de l’entreprise, sont également des bénéfices stratégiques qui découlent de la mise en œuvre
de ces solutions.
Ainsi, non seulement une démarche d’intégration permet d’orienter les systèmes d’information vers l’e-business, mais elle est aussi
la plus apte à assurer leur pérennité face aux besoins d’évolution. Cette réactivité couvre la possibilité d’accueillir facilement de
nouvelles applications au sein de l’entreprise conçue dans sa globalité, c’est-à-dire étendue aux systèmes de ses partenaires.
Pour répondre à de telles exigences, les plates-formes d’EAI imbriquent des technologies très variées. Afin d’en aborder la richesse
et d’en comprendre l’évolution, examinons les différentes briques qui constituent aujourd’hui les solutions d’intégration.
La première génération de plates-formes d’EAI, dédiée à la libération des flux d’information au sein de l’entreprise, est dotée d’une
organisation, que nous qualifierons de modèle EAI, construite sur quatre briques techniques :
• Le transport des données – Potentiellement sécurisé, il passe par des files d’attente de messages qui encapsulent l’infor-
mation et la stockent jusqu’à son exploitation.
13
• L’extraction d’informations depuis les applications et l’insertion de nouvelles informations dans ces applications – Cette
opération est réalisée par l’utilisation de connecteurs qui se « branchent » sur les applications.
• Les composants – Ils permettent d’effectuer des traitements métier complémentaires sur les données extraites. Ils
enrichissent et étendent l’intelligence de la plate-forme d’intégration.
• Le moteur d’intégration – Il administre les règles de transformation et de routage des données. Cœur du système, il fournit
également un ensemble de services complémentaires d’administration, de surveillance et d’analyse de l’activité du système.
Ce modèle est représenté graphiquement par la figure 3.
Moteur d'intégration
Composants
Données
Transport
Figure 3 - Modèle EAI
Lors d’une extraction de données, l’information est recueillie par les connecteurs applicatifs, puis empaquetée dans un message
placé et conservé dans des files d’attente. Le moteur d’intégration, alerté par l’arrivée d’un message, traduit les données pour les
router vers l’application destinataire. Les composants peuvent être sollicités pour vérifier certaines règles métier et influencer le
comportement du moteur d’intégration. En dernier lieu, les données sont transmises, via la couche transport, au connecteur branché
sur l’application destinataire et chargé d’opérer la mise à jour des données.
Ce modèle est extrêmement flexible, car il existe des connecteurs applicatifs pour un grand nombre d’applications standard du
marché. Il devient dès lors plus facile de remplacer une application obsolète par une application exploitant de nouvelles fonctionna-
lités et de nouvelles technologies. De plus, l’intégration d’une application au système d’EAI s’opère par simple abonnement de celle-
ci aux files d’attente de messages, configurées depuis le moteur d’intégration. Le système d’information bénéficiant de l’apport d’une
plate-forme d’EAI devient un système modulaire dont l’évolution n’est pas source d’instabilité.
La deuxième génération est tournée vers les processus métier et les échanges interentreprises : elle prend en compte les nouveaux
modèles économiques créés et promus par Internet et ses technologies (TCP/IP, SMTP, HTTP, FTP, XML, etc.). Cette deuxième
génération de plates-formes d’eAI dispose d’une architecture enrichie, qualifiée désormais d’eAI, offrant un modèle d’intégration
étendu à ses partenaires. Les technologies qui viennent se greffer sur le modèle initial sont :
• Un moteur de workflow – Il sert à modéliser et à mettre en œuvre au sein de la plate-forme d’intégration les processus métier
de l’entreprise.
• Une infrastructure d’échange B2B – Elle permet aux entreprises de communiquer.
14 Le moteur de workflow complète le travail des composants dans l’organisation de la logique métier. Concrètement, les processus
métier modélisés au sein du moteur de workflow sont implémentés par ces composants. Leur exécution s’enrichit de mécanismes
de synchronisation ou de rendez-vous, prend en compte l’intervention humaine à travers des notifications et encapsule des transac-
tions longues avec possibilité de restaurer les données dans leur état initial.
La brique d’échange B2B ouvre la plate-forme vers l’extérieur. Cette ouverture s’appuie sur un échange des données formatées dans
des langages normalisés construits sur XML. Cet échange s’intègre dans un processus métier workflow, lui-même normalisé par les
travaux d’organismes fédérateurs que nous présentons plus loin dans ce livre blanc.
Seront ainsi distingués les processus privés, internes à l’entreprise, et les processus publics, partagés avec les partenaires.
Ces deux nouvelles briques viennent se superposer au modèle initial pour définir la topologie à six couches représentée graphi-
quement par la figure 4.
B2B
Processus
Moteur d'intégration
EAI eAI
Composants
Données
Transport
Figure 4 - Modèle eAI

Vue d’ensemble
Ce modèle complet a été initialement introduit par le Hurwitz Group, cabinet de conseil de Boston. On constate que les services
initiaux du modèle EAI sont toujours présents et constituent les fondations du modèle étendu. Des fonctionnalités complémentaires
sont intégrées, mais le mode de fonctionnement de la plate-forme est inchangé. La flexibilité est toujours présente ; elle s’étend aux
partenaires de l’entreprise. Il est ainsi aisé d’intégrer de nouveaux partenaires aux processus d’échanges sur la base des normes
établies.
Chaque couche dispose de sa propre technologie. La plate-forme d’eAI est la concrétisation de la cohabitation réussie de ces techno-
logies. Le modèle reflète bien la nature profonde de l’eAI : un domaine où des composants essentiellement technologiques (le
middleware, les connecteurs, etc.) côtoient des éléments d’un haut niveau d’abstraction (modélisation des processus métier) pour
aligner la stratégie du système d’information sur celle de l’entreprise.
Ainsi, si une intégration efficace des technologies détermine les performances de l’ensemble de la plate-forme, la capacité de celle-
ci à traduire les aspects fonctionnels en éléments techniques en validera la viabilité en tant que solution d’entreprise.
Nous aborderons dans la suite de ce livre blanc le détail des technologies mises en œuvre par le modèle EAI et son évolution vers
l’eAI.
15
EAI De l’intégration à l’e-business / L e m o d è l e E A I
C H A P I T R E
Le modèle EAI
Ce chapitre reprend les couches décrites dans la vue d’ensemble :

• transport ;
• données ;
• composants ;
• moteur d’intégration.
16
Transport : un middleware pour les données
Définition
Les services de transport assurent la livraison des données aux applications via le moteur d’intégration, tout comme l’appareil
circulatoire alimente en sang chaque organe du corps. Dans la pratique, toutes les solutions d’EAI reposent sur une couche plate-
forme, ou middleware, soit propriétaire, soit fournie par un éditeur partenaire.
Plus généralement, une solution d’EAI doit savoir se connecter à tout middleware existant et doit proposer des passerelles entre les
middlewares hétérogènes présents dans l’entreprise. L’intégration s’opère ainsi à tous les niveaux : applications, données et
middlewares.
Fonctionnalités et technologies
Le middleware de l’EAI par excellence est asynchrone. Il est constitué de files d’attente de messages (message queues). Ces
solutions sont regroupées sous la dénomination de MOM (Message Oriented Middleware). La plus connue est sans conteste
MQSeries, d’IBM ; Microsoft propose MSMQ, sa propre solution. Les MOM sont une couche de transport et ont besoin pour
fonctionner d’un outil d’administration des messages transportés : le message broker. Dans une solution d’EAI, ce dernier tient le
rôle de moteur d’intégration.
Deux autres middlewares synchrones sont également utilisés dans une logique d’intégration :
• les ORB (Object Request Brokers), qui correspondent à la fois au middleware sur lequel reposent certaines solutions d’EAI et
au middleware constitutif de l’existant d’une entreprise qu’il faut savoir intégrer ;
• TCP/IP et HTTP (HyperText Transfer Protocol), protocoles standard de l’Internet, en passe de devenir le middleware de
référence de l’échange workflow.
Retenons pour l’instant qu’avec un middleware asynchrone, il n’est pas nécessaire de s’assurer de la disponibilité de l’application
destinataire, alors qu’un middleware synchrone va l’exiger. Or, tout progiciel connaît régulièrement des phases d’indisponibilité,
correspondant au lancement de traitements de masse ou à des opérations de maintenance. Les middlewares sont donc plutôt des
technologies complémentaires qu’une plate-forme d’EAI doit savoir intégrer et faire communiquer avec le système de MOM sur
lequel elle repose.
Le modèle EAI
Middleware asynchrone : les MOM

Les MOM désignent les technologies d’échange des messages stockés dans des files d’attente. Le MOM est un routeur de flux
interapplicatifs reposant sur une logique asynchrone : le message est envoyé sans que le processus émetteur attende une
quelconque réponse avant de poursuivre son exécution.
La disponibilité de la file d’attente n’implique pas la disponibilité de l’application à laquelle le message est destiné, ni la fiabilité du
réseau par lequel le message doit être véhiculé. Le couplage entre applications est un couplage lâche et non intrusif réalisé par l’inter-
médiaire des files d’attente.
Voici une liste des services traditionnellement délivrés par les MOM :
• Gestion des priorités – Les messages peuvent être traités selon un ordre déterminé grâce à l’affectation d’un niveau de
priorité.
• Gestion événementielle – La réception d’un message, ou sa délivrance, sont des événements dont la réalisation peut en
déclencher un ou plusieurs autres : création automatique de messages immédiatement postés dans les files d’attente,
invocation de méthodes sur les composants métier, etc.
• Sécurité des échanges – Les échanges sont sécurisés par :
- la garantie de délivrance : un message n’est jamais perdu ; s’il ne peut être remis, il est placé dans une file intermédiaire
gérée par un administrateur ;
- la garantie d’unicité : un message est traité une et une seule fois.
• Sécurité d’accès – Elle couvre la gestion des profils utilisateurs et la gestion des profils applicatifs (restriction de l’accès à
certaines files d’attente).
Le modèle de communication de ce type le plus répandu est le publish and subscribe. Les programmes enregistrés « s’abonnent »
à un sujet (une file de messages) et peuvent alors y poster des messages ou y recueillir les messages publiés. 17
Rules
Subscriptions
Publisher Topic
subscribe
Agent
registrer
receive notification/
message
Subscriber
Subject, Channel Agent
Figure 5 – Modèle publish and subscribe

Middlewares synchrones : les ORB et HTTP

Les ORB
Les ORB peuvent être considérés comme une évolution structurée des mécanismes de RPC (Remote Procedure Calls). Dans les
deux cas, le principe est l’invocation synchrone de fonctions applicatives sur des serveurs distants. A la suite de l’appel, le client
attend un message l’informant de l’issue de l’exécution de la fonction.
Ce type de fonctionnement est difficilement compatible avec une logique d’intégration, selon laquelle les applications autonomes
doivent continuer à s’exécuter indépendamment les unes des autres. Rendre le système intercommunicant ne signifie pas le rendre
interdépendant ; dans une perspective d’intégration, l’interdépendance forte des systèmes est à éviter.
Notons de plus qu’un système fondé sur ces mécanismes nécessite une bande passante élevée pour faire face au trafic réseau requis
par les nombreux échanges de messages interapplicatifs.
Si on peut difficilement placer les ORB au centre d’une plate-forme d’intégration, on peut néanmoins les rencontrer parmi les techno-
logies à intégrer, notamment pour réutiliser les services métier fournis par des composants placés sur un bus ORB. Nous allons
brièvement décrire les mécanismes ORB et ses implémentations les plus fréquemment rencontrées dans l’entreprise.
Un ORB forme un bus logique sur lequel se trouvent des composants métier qui fournissent des services. L’ORB traite l’arrivée des
requêtes, localise le composant appelé et retourne le résultat de l’appel. Un référentiel (interface repository) est nécessaire pour
connaître les interfaces de tous les composants disponibles. Les ORB sont conçus pour être utilisés dans des projets utilisant une
véritable approche orientée objet.
Les implémentations d’ORB disponibles sur le marché sont Corba (Common Object Request Broker Architecture), de l’OMG (Object
Management Group), DCOM (Distributed Component Object Model), de Microsoft et les EJB (Enterprise JavaBeans), de Sun
Microsystems.
18 • Corba – L’OMG, groupement de plusieurs centaines de membres, a défini dans les années 90 un standard pour le monde des
ORB : Corba. Ce standard est un ensemble de spécifications laissant le choix de l’implémentation aux éditeurs. Des incompa-
tibilités entre les API et entre les ORB en ont résulté.
Corba est avant tout un mouvement qui a amené les vendeurs à une meilleure reconnaissance et a facilité les développements.
Deux grandes étapes ont marqué la vie de ce standard :
- La création d’IDL (Interface Definition Language), langage de description des interfaces de composants logiciels.
- La définition, en 1996, du protocole IIOP (Internet Inter-ORB Protocol), qui a été un pas important pour la communication
inter-ORB. Ce protocole a ensuite été étendu à des ORB ne s’alignant pas sur Corba, comme RMI (Remote Method
Invocation), de Sun Microsystems, et par conséquent au modèle EJB.
• DCOM – DCOM est une évolution du modèle de composants propriétaires COM, de Microsoft. Cet ORB utilise le protocole
ORPC (Object Remote Procedure Call) et fonctionne essentiellement sous le système d’exploitation Windows.
Son avantage est d’être plus accessible que la technologie Corba car globalement moins complexe. Des éditeurs tiers
fournissent des services COM sur différentes plates-formes. Les services offerts par DCOM sont plus limités que ceux
proposés par les spécifications Corba, mais ils s’améliorent avec COM+ ou avec l’adjonction d’autres technologies Microsoft.
• EJB – Le monde Java propose une solution de rechange émergente, reposant sur RMI et sur le modèle de composants métier
EJB couplé au référentiel JNDI (Java Naming Directory Interface).
Grâce à l’apport de la spécification EJB 1.0 puis 1.1, les architectures Java disposent désormais d’un ORB capable de
communiquer avec des ORB Corba. Malheureusement, des spécifications non exhaustives ont, comme pour Corba, obligé les
éditeurs à effectuer leurs propres implémentations du modèle, rendant les composants EJB peu portables. La spécification 2.0
vise à combler ces lacunes.
Le modèle EAI
HTTP
Nous avons évoqué les raisons pour lesquelles un middleware synchrone paraît inadapté à une architecture d’intégration. HTTP
semble pourtant y avoir sa place, mais peut-être davantage dans le modèle eAI que dans le modèle EAI.
En effet, en plus de sa nature synchrone, HTTP propose des performances moyennes comparées à celles des MOM, ce qui semble
lui barrer la route de l’intégration intra-entreprise. Il permet en revanche un couplage faible et non intrusif entre les systèmes d’infor-
mation d’entreprises autonomes, rendant l’échange possible sans qu’il soit nécessaire de connaître les technologies utilisées chez
les partenaires. De plus, HTTP est un standard véhiculé par un autre standard, le réseau Internet, qui permet d’élargir facilement la
gamme des services offerts, là où Edifact et X.12, protocoles de l’EDI, sont nettement plus fermés.
HTTP peut devenir, en tant que couche de transport de messages métier XML, le middleware de l’échange interentreprise. Ce
middleware se superpose à celui utilisé en interne par la plate-forme d’intégration : le message provenant d’un partenaire est
transmis à une file d’attente qui assure la jointure entre les parties internes et externes du système d’e-business.
Certaines discussions concernent aujourd’hui la généralisation de HTTP dans une architecture d’intégration en vue de créer des
systèmes d’e-business « temps réel » entièrement fondés sur un protocole synchrone.
Couche plate-forme et EAI

Aujourd’hui, le middleware prédominant dans les offres d’EAI du marché est bien le MOM ; le couple MOM/message broker est le
noyau d’intégration majoritaire dans les offres des éditeurs.
Il est d’ailleurs intéressant de noter que certaines entreprises d’EAI, telles que Level 8 ou Neon Software, ont été créées par des
ingénieurs ayant précédemment participé aux spécifications ou au développement de solutions de message queuing parmi les plus
renommées (citons MQSeries et MSMQ). De par leur rôle et leur position, ils ont su saisir toute l’importance de cette technologie et
les développements qu’elle était susceptible de susciter et de supporter. Leur approche est qualifiée de bottom-up. 19
Certaines offres d’EAI bénéficient de la présence d’un middleware propriétaire. C’est le cas de Geneva MQ, de Level 8, de
TIB/Rendezvous, de Tibco, ou des Intelligent Queues, de STC. Les offres d’EAI utilisent généralement un message broker qui a
besoin de ce type d’infrastructure, qui garantit un bon niveau de performances sur son architecture propre. Lorsque l’éditeur ne
propose pas de solution, la plate-forme est généralement conçue pour reposer sur un des MOM du marché, parmi lesquels figurent
en bonne place MQSeries et MSMQ.
D’autres grands acteurs présents sur le segment de marché des MOM ou sur celui des message brokers (sans qu’il s’agisse pour
autant de leur unique activité) ont aussi évolué vers l’ouverture de leurs solutions à l’intégration d’applications. IBM a pu s’y
consacrer grâce à son MOM MQSeries, aujourd’hui réputé et très répandu, et Oracle a profité de son offre AQ (Advanced Queues)
pour présenter OIS (Oracle Integration Server).
Données : les adaptateurs applicatifs

Définition
Les données de chaque application doivent être conservées dans leur format natif et sur leur support d’origine, en vue de permettre
à l’application qui les héberge de continuer à assurer les services fournis avec le même niveau de performances et d’éviter les coûts
liés à leur migration d’un référentiel vers un autre.
Les adaptateurs applicatifs (ou connecteurs) vont extraire ces données en fonction des besoins (événements déclenchés par l’arrivée
d’un message, étape d’un processus métier) et les diriger vers l’application destinataire. Les connecteurs assurent la communication
entre la plate-forme d’EAI et les applications ou les services applicatifs du système d’information.
Un adaptateur applicatif est un composant logiciel qui offre la connectivité nécessaire à l’interfaçage avec les applications et les
sources de données, avec ou sans intelligence métier. Cette couche logicielle masque à l’utilisateur la complexité de la communi-
cation entre l’API du moteur d’intégration et celle de l’application.
Les connecteurs doivent être des systèmes non intrusifs (on n’introduit pas de portions de codes dans les systèmes sources ou
cibles).
Ils peuvent fournir des services complémentaires tels que la gestion des exceptions ou des mécanismes de remontée d’erreurs. Ils
doivent donc être dotés de l’intelligence nécessaire à l’interprétation de ces messages. Il faut également que la plate-forme d’inté-
gration soit capable d’interpréter les messages d’erreur en tant que tels.
Typologie des adaptateurs

Il existe aujourd’hui un grand nombre d’adaptateurs, qui correspondent aux différents types d’applications que l’on peut rencontrer.
Le nombre d’adaptateurs fournis avec chaque solution est d’ailleurs un argument de vente des éditeurs d’EAI.
Pour décrire les offres d’EAI, nous adopterons dans ce livre blanc la classification suivante :
SGBD – DB2, SQL Server, Informix, Oracle, Sybase, Lotus Notes, ODBC, JDBC, etc. ;
ERP – PeopleSoft, SAP, Oracle Applications, JDEdwards, Siebel, etc. ;
CRM – Vantive, Siebel, Clarify, BroadVision, etc. ;
SCM – i2 Technology, etc. ;
Mainframes – SNA, CICS, IMS, OSI TP, VSAM, EBCDIC, 3270, OS/390, etc. ;
MOM – MQSeries, MSMQ, etc. ;
ORB – Corba, DCOM, Java, etc. ;
Protocoles Internet – HTTP, XML, SMTP, etc. ;
B2B – Swift, Edifact, X.12, XML (RosettaNet, BizTalk), etc.
Applications spécifiques
20
Il y a, dans une entreprise, un ensemble d’applications spécifiques légataires pour lesquelles il ne peut exister d’adaptateur standard
sur le marché. Pour cette raison, les éditeurs fournissent généralement avec leur plate-forme un kit de développement. Il guide la
mise en œuvre de connecteurs et masque une partie de la complexité technique propriétaire, notamment la communication avec les
files d’attente.
Les kits de développement (SDK, Software Development Kit), la documentation sur les API existantes et la formation dessinent la
panoplie du développeur de connecteurs. Il est donc important, lors de la recherche d’une plate-forme d’EAI, de vérifier si des
formations sont assurées, éventuellement sur site et, au besoin, si elles sont dispensées en français.
Généralement, l’éditeur propose aussi des prestations de conseil et d’ingénierie pour la réalisation des adaptateurs ou délègue ces
missions à des intégrateurs partenaires.
Couche données et EAI

La technologie des adaptateurs est un point sur lequel les éditeurs insistent fortement lors de la promotion de leurs plates-formes.
Le nombre d’adaptateurs fournis et la qualité de la technologie et des services pris en charge sont des critères différenciateurs entre
deux offres. En effet, la technologie des connecteurs a énormément évolué depuis les débuts de l’EAI. Nous allons en tracer un bref
historique pour mieux présenter les technologies disponibles.
De l’adaptateur « léger » à l’adaptateur « riche »

Les adaptateurs « légers » effectuent une simple translation d’API pour offrir une interface commune au message broker. Cependant,
l’ajout d’une interface de programmation intermédiaire pénalise les performances sans réellement fournir de nouvelles fonctionna-
lités. De plus, le connecteur n’est pas utilisable en mode natif : il faut nécessairement programmer pour accéder à ses services, tâche
compliquée par la nécessité d’être familier avec l’API du message broker, probablement propriétaire.
Les adaptateurs « riches » rendent la programmation très aisée, voire inutile. Dans de nombreux cas, l’utilisateur emploie une
interface graphique pour connecter les systèmes sans recourir à la programmation. Ces adaptateurs fournissent également une
qualité de service supérieure, comme la prise en compte d’une partie de la montée en charge par multithreading statique ou
dynamique.
Le modèle EAI
De l’adaptateur « riche » statique à l’adaptateur intelligent

La première génération d’adaptateurs, légers ou riches, est celle des adaptateurs statiques, qui demandent systématiquement une
configuration manuelle. Par exemple, dans le cas d’une base de données, l’adaptateur a besoin d’être informé manuellement de la
composition des tables et de leurs attributs. Si les informations de configuration ne sont pas correctes, le système ne fonctionnera
pas. Par conséquent, si le schéma de la base de données change, aucun mécanisme intelligent ne saura mettre automatiquement la
configuration à jour.
Les adaptateurs intelligents, connecteurs applicatifs de deuxième génération, apportent la réponse à cette problématique. Ils savent
s’autoconfigurer en consultant les référentiels des applications auxquelles ils se connectent (tables système dans les bases de
données ou référentiels dans les ERP) par l’intermédiaire de processus d’introspection.
Ils sont aussi capables d’apprendre. Un adaptateur connecté à une base de données sait trouver dans les tables système la
description des tables existantes et de leur structure (nom et types des attributs). Toute modification de la composition de la base
est alors dynamiquement identifiée par l’adaptateur et remontée à l’opérateur.
Les services complémentaires sont :
• le multithreading ;
• le filtrage des données ;
• le gestionnaire d’événements, notamment pour déclencher un premier niveau de transformation au sein du connecteur. Les
adaptateurs de webMethods/Active Software et de STC fonctionnent sur ce mode. La conversion des données s’opère généra-
lement dans un format propriétaire directement compréhensible par le moteur d’intégration. La plate-forme d’EAI Sagavista,
de Saga, transforme préalablement les données en Document Sagavista, format pivot du système d’information ; la plate-forme
Fusion, de Forte, utilise pour sa part XML comme langage commun.
Grâce aux adaptateurs intelligents, les développements liés aux connecteurs applicatifs disparaissent. Les connecteurs deviennent 21
un ensemble de technologies sophistiquées et prêtes à l’emploi au service d’un type d’application. Une console graphique de
configuration restitue le résultat des processus d’introspection effectués par les connecteurs. Dans le cas d’un ERP, le connecteur
remonte par exemple la liste des fonctions disponibles, et le travail de l’utilisateur consiste ensuite à définir le groupe de fonctions
à exploiter et les données qui leur servent d’arguments.
Composants : appliquer la logique d’entreprise

Le moteur d’intégration est le cœur de la plate-forme d’EAI. C’est un organe essentiellement technique, qui ne dispose pas d’un
référentiel de logique métier adapté à l’entreprise. Cette logique doit être implémentée dans des composants, auxquels le moteur
s’adressera pour vérifier les règles liées à l’arrivée d’un message.
Imaginons que le moteur d’intégration reçoive une commande émise depuis une application d’e-commerce. Dans un premier temps,
son travail va consister à relayer le message, grâce à son référentiel de routage, jusqu’au bon composant métier. Celui-ci va
interroger le référentiel du CRM pour connaître le montant des achats effectués par ce client le mois précédent afin de lui proposer
une remise dont le taux est lié à ce montant. On constate qu’une extraction complémentaire de données est demandée au moteur
d’intégration lors de la vérification de la règle métier. Une fois la remise calculée, le résultat du travail effectué par le composant est
transmis au moteur d’intégration, qui va mettre à jour les données de l’ERP et du CRM avec ces nouvelles informations.
Ces composants peuvent être des composants externes reliés au message broker via un connecteur applicatif adapté (connecteur
Corba, connecteur DCOM, connecteur Java).
Ils peuvent aussi être générés par la plate-forme d’intégration et reposer sur des bases technologiques propriétaires à cette plate-
forme. C’est le cas des BOB de l’éditeur STC. Pour modéliser ces composants, les plates-formes d’EAI incorporent parfois des outils
de modélisation objet (comme Rational Rose) et des ateliers de développement.
Enfin, lorsque nous aborderons les apports de la brique de workflow, nous verrons que ces composants peuvent également être
générés à partir des processus métier définis dans le workflow, pour devenir la représentation technique de ces processus.
OAGI (Open Application Group, Inc.)

OAGI est un consortium industriel à but non lucratif créé en 1995. Regroupant au départ des entreprises comme Dun & Bradstreet Software,
Oracle, PeopleSoft ou SAP, le consortium compte désormais plus de 37 membres.
Son but est de promouvoir l’intégration de composants métier logiciels pour l’entreprise en définissant un modèle de solutions pratiques
et implémentables pour rendre l’interopérabilité possible.
Après 18 mois de travaux, OAGI a rendu en juin 1997 la proposition OAGIS (Open Application Group Integration Specification), qui spécifie
exhaustivement la démarche d’intégration.
Ce modèle contient :
• une architecture applicative ;
• des définitions de composants métier logiciels ;
• des diagrammes de scénario d’intégration de composants ;
• des définitions détaillées d’API nécessaires à l’intégration de composants métier logiciels ;
• un dictionnaire de données décrivant les éléments individuels de ces API.
Une démarche d’intégration type est également définie :
• définition du besoin et du scénario d’intégration ;
• définition des composants métier logiciels et de leur granularité ;
• développement d’un scénario d’intégration détaillé.
La phase de modélisation est évidemment déterminante dans un projet d’EAI. Elle permet de définir les objectifs à atteindre et, à travers
eux, de déterminer le nombre, la complexité et la portée des processus métier :
• modélisation des processus métier et définition des relations entre les composants métier ;
• définition d’un dictionnaire de données commun pour permettre aux composants métier de partager le même vocabulaire ;
22 • mise au point de normes pour décrire les flux entre les composants logiciels métier, définissant l’interopérabilité pour la synchronisation
de données, la validation, les transactions, le reporting, l’audit, la sécurité et l’authentification.
OAGIS se concentre sur la démarche et non sur la technologie. Le consortium a néanmoins défini un niveau d’interopérabilité des
composants par la définition d’un modèle d’objet virtuel, en réalité une couche d’implémentation standardisée venant se superposer à
l’interface publique de tout composant et la rendant virtuellement privée. Les composants communiquent alors entre eux par l’échange de
BOD (Business Object Documents) entre ces interfaces virtuelles.
Le modèle EAI
Moteur d’intégration : le cœur du système d’e-business

Définition
Le moteur d’intégration centralise l’intelligence de la plate-forme d’EAI via son référentiel, qui contient toutes les règles de routage
et de transformation des données. Il sait à quel événement métier appartient le message recueilli et assure la continuité de cet
événement. Il se configure et s’administre grâce à un ensemble d’outils munis d’une interface graphique. Le moteur d’intégration
est donc la brique qui donne naissance au prototypage, puis au développement du projet d’EAI.
Le rôle du moteur d’intégration consiste à convertir les données, qui sont au départ au format de l’application source, dans le format
utilisé par l’application de destination (fonctionnalités de transformation) et à les transmettre à cette application (fonctionnalités de
routage).
Transformation
Les applications du système d’information ont des modèles de données différents. Les données de l’application A ne sont pas
directement compréhensibles par une application B : elles ne partagent généralement pas les mêmes types ni la même sémantique.
Par exemple, un champ Date d’émission stocké au format texte dans une application mainframe peut correspondre au champ Date
de sortie, de type date, dans la base de données d’une application Internet. Le moteur d’intégration connaît les spécificités de chaque
application et sait comment transformer les informations pour assurer la correspondance entre les modèles de données. C’est le
processus de mapping, étape importante de tout projet d’EAI.
Convertir des données entre deux applications est une opération délicate, dont la complexité s’intensifie à mesure que de nouvelles
applications s’ajoutent aux précédentes. La facilité d’évolution d’une plate-forme d’EAI vers l’intégration de nouvelles applications
doit être étudiée avec soins lors du choix d’une plate-forme. La richesse des outils de configuration et de l’interface graphique à
23
disposition de l’utilisateur doit être qualifiée avec soin.
Routage
L’intelligence de routage est complémentaire de l’intelligence de transformation. Toute plate-forme d’EAI inclut un référentiel des
métadonnées, qui contient les règles de routage mises en rapport avec le processus métier auxquelles elles se réfèrent. Ainsi,
l’arrivée d’un message est corrélée avec une étape de processus, et le référentiel indique les actions à mener et l’application à laquelle
il faut s’adresser pour passer à l’étape suivante.
Le routage ne désigne pas systématiquement une communication one-to-one linéaire entre une application A et une application B.
Les données peuvent être recueillies auprès de plusieurs sources, puis agrégées pour créer un nouveau message qui sera envoyé à
plusieurs applications. Ce mode de communication many-to-many se rencontre lorsque des processus métier se croisent ou dans
le cas d’une intégration incrémentale (remplacement progressif d’une application par une autre application fonctionnellement
équivalente ou plus évoluée).
Fonctionnalités
Le moteur d’intégration, point central du système, complète ses fonctionnalités de transformation et de routage par les services
d’administration et de surveillance énumérés ci-après.
Configuration, administration et supervision

Les plates-formes d’EAI proposent habituellement trois types d’outils pour insérer la plate-forme au sein du système d’information
et l’exploiter au quotidien. Ils sont généralement dotés d’une interface graphique, qui entraîne, pour certains, la nécessité d’admi-
nistrer la plate-forme depuis un client Microsoft Windows. Le déploiement peut cependant généralement s’opérer sur des machines
équipées de systèmes d’exploitation hétérogènes (Unix majeurs du marché et parfois Linux). On recense :
• Des outils capables de découvrir facilement les ressources mises à disposition par les sources de données et les applications
existantes, de créer les schémas de correspondance entre les structures de données et les transformations de ces données.
• Des outils capables de tracer les échanges de messages, de suivre le déroulement des processus et d’élaborer des rapports
d’activités. Il est indispensable de savoir si les processus se sont correctement achevés et de connaître la durée de leur
exécution. Il faut être en mesure d’identifier la nature et la raison des problèmes rencontrés et de reprendre tout ou partie d’un
processus non achevé. Enfin, il est nécessaire de disposer de rapports sur les performances de la plate-forme et du système
et sur son comportement au moment des pics de charge.
Ces informations vont avoir des conséquences sur la configuration du système, car l’administrateur va alors rechercher la configu-
ration optimale afin d’améliorer les performances et la robustesse du système. Les points d’optimisation concernent la montée en
charge (déplacement des charges et pics de charge), la tolérance aux pannes, les goulets d’étranglements, les ruptures de
connexions réseau, etc. Des outils capables de modifier facilement la répartition des éléments du système et la distribution à distance
de ses composants ou des message brokers (architecture multi-hub) vont permettre de pratiquer cette optimisation facilement et à
distance.
Stockage de messages
Le but est d’assurer la persistance des messages non transmis : garantie de la non-perte et de la diffusion de l’information, gestion
de l’intégrité des messages, archivage, journaux de fonctionnement et audit des volumes traités.
Référentiel
Répertoire des applications connectées et de leurs spécificités, connaissance des informations à transmettre d’une application à
l’autre et de la traduction à effectuer. Ce référentiel est soit une base propriétaire propre à l’architecture de l’éditeur, soit l’exploitation
d’une des bases de données majeures du marché (IBM, Microsoft, Oracle, Sybase).
Ouverture aux fonctions d’annuaires

Les traitements peuvent être combinés avec un annuaire d’entreprise pour authentifier et localiser les utilisateurs et les systèmes et
24
personnaliser la transformation.
Technologies : les message brokers

Les message brokers mettent en relation des entités sources et des entités destinataires via un échange de messages entre elles. Il
intègre nativement les fonctions de routage et de transformation évoquées.
1. Les message brokers ne remplacent pas les middlewares traditionnels comme les MOM, les ORB et HTTP, mais ils s’y couplent.
Un message broker peut ainsi être perçu comme un « middleware pour le middleware ». MOM et message brokers forment
aujourd’hui un duo indispensable à toute architecture d’intégration.
2. L’architecture qui en résulte est qualifiée de hub-and-spoke (à moyeu et à rayons) : le moteur d’intégration se conduit comme un
hub centralisé. Il utilise les technologies de files d’attente pour traiter les messages en provenance des différentes applications du
système. Il est le nœud centralisateur ; il apporte sa valeur ajoutée au contenu et à la structure des messages avant de les diffuser
aux applications cibles.
Les connecteurs applicatifs et le système des files d’attente permettent au message broker de s’affranchir de la technologie des
applications auxquelles il transmet des données. En contrepartie, les applications émettrices envoient des messages sans se soucier
de la technologie de l’application cible, ni même de celle du message broker. Le couplage lâche entre le message broker et les
applications du système d’information qui résulte de la mise en œuvre de ces technologies procure un avantage indéniable à cette
architecture.
Aucun aménagement lié à l’intégration n’est nécessaire dans les applications sources : le développement est réalisé visuellement
depuis les interfaces graphiques du message broker et centralisé dans le référentiel d’intégration.
3. Les message brokers reposent généralement sur des technologies de message queuing, avec un support du publish and
subscribe.
Les applications publient (publish) des messages sur les files d’attente du MOM gérées par le message broker. Celui-ci transforme
les messages et les place sur d’autres files d’attente, où d’autres applications abonnées (subscribe) à ces files les récupèrent. Chaque
file d’attente est caractérisée par un sujet (par exemple, enterprise.erp.logistique).
Le modèle EAI
4. Dans un contexte d’EAI, un message broker assure des communications any-to-any et many-to-many.
Any-to-any désigne une connexion facilitée et transparente entre toutes sources de données. Celle-ci est garantie par la présence
d’adaptateurs applicatifs standard et par la possibilité d’en développer.
Many-to-many signifie que toute application sait se connecter aux informations publiées par toute autre application et sait les utiliser.
Les capacités de transformation du message broker sont alors déterminantes.
5. La vocation d’une plate-forme d’intégration est de se placer au centre du système d’information. Cette place stratégique implique
des architectures performantes, robustes et capables de traiter de gros volumes de données. Elle requiert aussi des fonctionnalités
comme le support des transactions, l’intégration de processus métier sophistiqués aux règles de routage complexes ou l’ouverture
aux fonctions d’administration réseau, qui ne sont pas la vocation première de ces plates-formes.
Le support des transactions n’est pas pris en charge par un message broker. Il est important que la plate-forme d’EAI incorpore un
gestionnaire de transactions sachant communiquer avec le message broker, mais cette possibilité intéressante aura obligatoirement
un impact sur les performances.
L’intégration de processus métier complexes est liée aux difficultés parfois rencontrées par un message broker pour coder certaines
règles de routage. Le niveau de sophistication exigé n’est pas forcément atteint. Cette raison a poussé l’EAI à intégrer une véritable
brique de workflow et à la rendre communicante avec le message broker. La complexité des processus d’entreprise à modéliser
déterminera le besoin d’intégration et donc la nécessité ou non d’utiliser cette brique de workflow.
L’ouverture aux fonctions d’administration réseau, par connexion à des agents SNMP, permet d’inclure la plate-forme dans un
ensemble plus vaste.
La plate-forme d’intégration doit incorporer un ensemble de fonctions d’ouverture à des éléments extérieurs qui élargiront son
spectre fonctionnel et technique tout en supportant la charge de travail qui en résultera.
6. Les architectures d’EAI reposant sur un message broker sont nombreuses et majoritaires. Citons ActiveWorks, d’Active Software
25
(désormais webMethods), Mercator, de Mercator Software, e-Biz Integrator, de Neon, e*Gate, de STC, ou encore ActiveEnterprise,
de Tibco. Les offres de ces éditeurs sont présentées en détail dans le chapitre 5 de ce livre blanc, « Marché de l’EAI et offres des
éditeurs ».
Couche moteur d’intégration et EAI

Rappelons que les architectures d’EAI utilisant un message broker et fonctionnant selon le mode que nous avons décrit sont
qualifiées d’architectures hub-and-spoke. Les applications sont connectées à un nœud central, qui concentre les flux. Ce hub
contient les règles nécessaires pour connecter des applications et rassembler des messages. C’est l’architecture typique d’une plate-
forme d’intégration.
Application
Application Application
Message
Application Broker
Application
Application
Application
Figure 6 – Architecture hub-and-spoke (source : Software Development Magazine)

26
L’architecture hub-and-spoke autorise une administration centralisée et simplifiée. Le nœud central est le point de connexion
physique et le routeur des échanges. Cette architecture supporte des systèmes flexibles auxquels il est aisé d’intégrer de nouvelles
applications. L’intégration entre elles d’applications déjà connectées au hub peut être rapidement mise en œuvre et celles-ci peuvent
se connecter facilement à toute nouvelle application intégrée.
La montée en charge et la tolérance aux pannes, fonctions cruciales, sont assurées par la multiplication des hubs en différents points
du réseau. Un référentiel centralisé, synchronisé et distribué, assure la répartition des règles de routage et de transformation à
l’ensemble du système. La montée en charge est gérée intelligemment, avec distribution dynamique des messages en fonction de
la charge de chacun des message brokers.
Application
Application
Application
Message Message
Application Broker Broker
Application
Application
Application
Application
Application
Application Message Application

Broker
Figure 7 – Architecture distribuée multi-hub (source : Software Development Magazine)

De l’EAI à l’intégration étendue
C H A P I T R E
Ce chapitre reprend les couches décrite dans la vue d’ensemble :

• processus ;
• B2B.
Processus : modélisation métier

Définition
Dans le modèle de passerelles point à point décrit précédemment, l’absence d’un point de contrôle centralisé empêche la prise de
recul nécessaire à la mise en œuvre de processus de communication globaux. La charge technique décourage le travail de reverse-
engineering des analystes métier.
27
Dans le modèle EAI, la présence du hub que constitue le message broker fournit un référentiel qui favorise ce travail. Cependant,
comme nous l’avons déjà évoqué, certaines règles de routage sont trop complexes pour être gérées nativement par le message
broker ; nous avons en outre précisé qu’un moteur de workflow pouvait combler ces lacunes.
Reprenons l’exemple de système d’e-business cité au début de ce livre blanc et modifions légèrement le scénario. Dans notre
exemple, les systèmes communicants sont administrés par un message broker. Un internaute commande un produit et cette
information est transmise à un composant métier qui vérifie l’état des stocks. Le produit est disponible, mais cette commande fait
passer la quantité stockée sous le seuil de réapprovisionnement. L’application logistique transmet cette donnée au moteur d’inté-
gration, qui la récupère dans les files d’attente du système. Il la transmet à l’application d’approvisionnement, qui génère une
commande. Cette commande n’est toutefois pas adressée directement à un fournisseur, car l’intervention du responsable des achats
est nécessaire pour sélectionner le fournisseur auquel la commande va être adressée.
Le responsable des achats est prévenu par e-mail de la nécessité de son intervention. Le processus métier est interrompu et ne
reprend que lorsque le responsable des achats a sélectionné le fournisseur et validé la commande. Si le responsable des achats ne
peut répondre dans les 24 heures, la notification est automatiquement routée vers un utilisateur capable de prendre le relais.
Un message broker ne dispose pas des fonctionnalités nécessaires à interrompre un processus, à le reprendre lorsqu’un événement
métier lié survient, ni à envoyer une notification à un utilisateur et à prendre une décision en cas de non-réponse à cette notification.
Seul un moteur de workflow peut répondre efficacement à ce besoin.
Séparation du métier et de la technique

En incorporant une brique de modélisation métier sophistiquée, concrétisée techniquement par un moteur de workflow, les plates-
formes d’intégration séparent la modélisation métier et l’implémentation technique des processus.
EAI De l’intégration à l’e-business / D e l ’ E A I à l ’ i n t é g r a t i o n é t e n d u e
Il est logique de dissocier les deux aspects : lors de la réflexion sur les processus métier, l’architecture technique nécessaire à leur
future exécution ne doit pas interférer. Les interlocuteurs participant à la réflexion sont en effet des analystes métier, et non des
architectes du système d’information.
Inversement, lors de la mise en œuvre technique, les analystes métier ne doivent pas être concernés : peu importe le processus, les
seules réponses à apporter concernent les composants métier, l’extraction des données, leur routage et leur transformation.
Processus métier et processus techniques

Il est important de faire la distinction entre la gestion des processus métier, assurée par un moteur de workflow, et l’automatisation
des processus techniques, que le moteur d’intégration de la plate-forme d’EAI doit savoir traiter.
Gestion du workflow
Son principe consiste à automatiser le routage des informations et des documents d’utilisateur à utilisateur :
• Processus à durée de vie longue, automatisés mais avec la possibilité d’une intervention utilisateur.
• L’état du processus peut être conservé en base de données.
• Des milliers de tâches par heure.
• Des fonctions fortement structurantes pour l’organisation : utilisé pour le traitement d’une déclaration d’assurance, la vérifi-
cation d’un rapport de dépenses ou pour passer les ordres de commande fournisseur.
• Un reporting métier fort.
Automatisation de processus
Son principe consiste à automatiser les processus de production entre applications et systèmes.
• Processus de transport et de contrôle d’information à durée de vie courte, complètement automatisés.
• L’état du processus ne peut être conservé qu’en mémoire centrale.
• Des centaines de messages par seconde.
• Processus rapides, adaptés au Web (B2B et portails).
28 • Des fichiers journaux pour rendre compte de l’activité.
Standardisation
Les travaux du WfMC (Workflow Management Coalition) cherchent à uniformiser la terminologie et à définir des standards pour
élaborer une spécification d’interopérabilité et un langage commun de requêtes et de réponses d’un moteur de workflow. Pour l’EAI,
c’est l’occasion :
• de faire communiquer entre eux des systèmes d’EAI hétérogènes au niveau processus et non plus seulement données ;
• d’affranchir l’échange B2B du cadre dans lequel une entreprise pivot dirige l’échange et le processus métier.
Le WfMC définit également les fonctionnalités que tout moteur de workflow se doit d’implémenter.
Il n’entre pas dans nos intentions de détailler précisément tous les services fournis par un moteur de workflow. Néanmoins, certaines
fonctionnalités typiques doivent être présentes pour répondre aux besoins de l’EAI.
Aiguillage conditionnel
Les résultats liés à une étape d’un processus permettent au moteur de workflow de décider de la suite à donner à l’exécution du
processus, suivant les possibilités définies lors de la modélisation. Cet aiguillage peut personnaliser les processus en fonction des
populations d’acteurs concernées, ce qui laisse entendre la possibilité d’un moteur ouvert, interfaçable avec les services d’annuaire
ou le référentiel des partenaires dans le cadre d’échanges B2B.
Gestion d’alertes et notification automatique

Cette gestion d’alertes doit être intelligente ; elle doit être capable de router la notification vers un autre acteur en cas d’indisponi-
bilité du destinataire initial ou de prendre une décision qui automatise l’étape courante.
Rendez-vous et synchronisation entre les différents processus

Les processus métier ne sont pas totalement indépendants les uns des autres. Certains processus vont se croiser et se synchro-
niser. Par exemple, avant de générer une facture, le système peut s’assurer que le processus de commande et de livraison est
achevé. Comme nous avons pu le constater, certains processus doivent aussi attendre une intervention humaine pour poursuivre
leur séquence.
Configuration, administration et supervision

Avec un outil d’EAI, la modélisation des processus métier est effectuée depuis une interface graphique dédiée au workflow. Lorsque
les analystes métier détectent un changement dans l’environnement, ils peuvent faire évoluer le processus métier correspondant
depuis l’outil de workflow et constater une répercussion rapide de cette modification sur le plan technique. L’administration des
processus métier en est facilitée, de même que le suivi de l’exécution de chacune de leurs instances.
L’automatisation des processus qui résulte de la mise en œuvre d’une plate-forme d’intégration comprime les délais et le coût
d’exécution d’un processus métier. Au-delà de la technologie, et tout en s’appuyant sur l’existant technologique d’une entreprise, les
processus métier vont piloter le système d’information de l’entreprise puis, au fil d’une évolution logique, la communication interen-
treprises.
Couche processus et eAI

La position de cette couche dans le modèle est stratégique pour plusieurs raisons. D’une part, elle représente clairement le cerveau
de la solution, disposant de l’intelligence métier de la plate-forme et parfois, en fonction de la configuration, de l’intelligence métier
de l’entreprise. D’autre part, à la jonction des couches moteur d’intégration et B2B, elle assure l’interface de communication entre
processus privés (internes à l’entreprise) et processus publics (processus normalisés partagés entre partenaires). C’est cette couche
pivot qui permet le passage de l’EAI à l’eAI.
29
De plus, elle améliore la cohérence interne de la plate-forme. Par exemple, l’offre Geneva Integration Suite de Level 8 transforme les
processus en composants métier gérés par le moteur d’intégration, et ces composants sont directement connectés aux données.
Ainsi, des processus aux données, toutes les couches du modèles EAI sont reliées de façon logique pour aboutir à un modèle techni-
quement unifié et cohérent.
B2B : eAI ou l’intégration étendue

Définition
L’EAI fédère le système d’information en rendant ses applications intercommunicantes et en centralisant les mécanismes de cette
communication. L’EAI apparaît ainsi comme une étape préparatoire à l’eAI, en ce sens que l’eAI est l’extension de cette intégration
à l’extérieur de l’entreprise.
Ayant libéré ses propres flux d’information, l’entreprise peut envisager l’échange avec ses partenaires et avec tout organisme public
ou privé. On regroupera sous le terme d’échange business-to-business, ou B2B, les formes normalisées prises par ces échanges,
aboutissant à une transaction au moyen de protocoles de communications standard, légers et conçus pour Internet.
Selon cette définition, l’EDI (échange de données informatisé) apparaît comme une forme d’échange B2B (voir l’encadré « Échanges
sécurisés »). L’objectif de ce livre blanc n’étant pas de traiter de l’EDI, domaine trop vaste pour être couvert ici, nous nous bornerons
à évoquer les nombreux standards et initiatives émergeant hors EDI.
L’objectif est l’établissement de relations stratégiques entre partenaires, la création de chaînes de valeur permettant d’acquérir ou de
conserver un avantage concurrentiel. Ceci implique la création de processus interentreprises automatisés, sécurisés, fiables et en
temps réel, dans lesquels l’intervention humaine sera limitée.
L’échange d’informations est ainsi créateur de richesse de par la réduction du cycle de circulation des données et l’élargissement
des formes de travail collaboratif.
Ouverture du système d’information

L’insertion de l’entreprise dans une chaîne d’échange (son acceptation par un ensemble de partenaires) ne peut s’opérer avec succès
que dans la mesure où elle est capable de traiter l’information efficacement et de façon fluide. Rien ne doit s’opposer à la diffusion
de l’information et à son transfert. L’information ne doit rencontrer aucun goulet d’étranglement.
C’est la raison pour laquelle on parle d’intégration étendue. Si l’entreprise n’a réalisé aucun travail d’intégration préparatoire sur son
propre système d’information, la probabilité de voir les données ralenties dans leur circulation et perturbées dans leur traitement est
importante.
Pour illustrer notre démonstration, reprenons notre système à moyeu et à rayons, piloté cette fois par un moteur de workflow. Ce
système résulte d’un travail d’intégration préalable. Une fois ce travail réalisé, l’entreprise peut fournir au monde extérieur un
ensemble de points d’entrée et de sortie communicants et ouvrir un passage à la communication d’informations vers ce système.
Impact sur les modèles économiques

L’automatisation des opérations entraîne évidemment une réduction substantielle des coûts de transaction, qui sont inférieurs à ceux
d’une transaction EDI. Les économies réalisées grâce à ce type d’échanges attirent les acteurs institutionnels et les grands comptes.
En contrepartie, ils font profiter les mécanismes B2B de leur puissance, en termes de données comme de services : on retrouve ces
acteurs dans les initiatives de conception des langages et des frameworks B2B.
De nouveaux modèles économiques se construisent. Le modèle build-to-order, évoqué dans le premier chapitre de ce livre blanc, en
30 est une bonne illustration. L’entreprise dispose en permanence et en temps réel d’informations sur l’évolution des commandes et
peut aligner sa logistique sur ces informations. La visibilité des stocks s’accroît et les coûts d’inventaire diminuent significativement.
Les échanges B2B ne se limitent pas à des bons de commande. Des boîtes à outil sectorielles se créent. Des initiatives destinées à
promouvoir l’échange d’informations de produits ou de projets voient le jour. Par exemple, un bureau d’études disposera de normes
et de ressources pour distribuer les spécifications d’un nouveau produit à un fabricant. Les délais de fabrication s’amenuisent et le
produit se retrouve plus rapidement sur le marché. Cette accélération des processus répond au niveau de compétitivité exigé par l’e-
business.
Gestion des partenaires
Le référentiel d’intégration doit identifier les multiples partenaires avec lesquels les échanges vont être entrepris, le rôle que chaque
partenaire va jouer dans l’échange et les transactions auxquelles il est susceptible de participer.
Performances
La distribution des données d’une requête à plusieurs dizaines de partenaires et l’agrégation des résultats en temps réel nécessitent une
qualité de service stable, avec un niveau de performances irréprochable.
En effet, l’utilisateur final exigera toujours la disponibilité permanente et rapide des informations. Cela se justifie particulièrement lorsque,
par exemple, l’entreprise désireuse de connaître l’état d’une commande est en France et que son fournisseur est aux États-Unis.
Les capacités de montée en charge et de tolérance aux pannes doivent donc être fortes, l’accroissement du volume des transactions
étant au moins aussi rapide que celui de l’Internet.
Flexibilité et facilité d’intégration

La modularité que procure une plate-forme d’EAI aux applications du système d’information doit se vérifier dans le cadre d’une
démarche d’eAI. Il faut pouvoir intégrer rapidement les changements survenus dans l’environnement professionnel.
Dans ce but, le couplage entre applications doit rester lâche. L’utilisation d’Internet est devenue une évidence, et les échanges sur
HTTP seront donc privilégiés, ce qui désigne de facto XML comme support de structure des données.
Une solution d’intégration doit être fondée sur des standards ouverts, qui garantiront la compatibilité avec d’autres systèmes. On
privilégiera également les systèmes non intrusifs.
Fiabilité
S’insérer dans une chaîne d’échange nécessite un système robuste, sous peine d’en être le maillon faible et de perturber l’efficacité
du transport de l’information.
Sécurité
Les systèmes impliqués dans des échanges B2B contiennent les données de chaque transaction, mais également des données
confidentielles. Les données échangées sont sensibles et les échanges doivent être sécurisés : cryptage des messages transmis avec
X.509, authentification par utilisation de certificats X.509, utilisation de protocoles de sécurité du monde de l’EDI (X.435). Enfin, la
connexion directe à des systèmes partenaires doit s’effacer au profit de l’échange d’informations sur HTTP. Les rôle des standards
du Web est donc déterminant. La définition et l’administration des processus d’agrément d’échange entre les partenaires sont
également très importantes.
Échanges sécurisés
S/MIME
S/MIME (Secure Multipurpose Internet Mail Extensions) est une méthode sécurisée d’envoi d’e-mails utilisant le système de chiffrement
RSA. Intégré aux versions les plus récentes des navigateurs web commercialisés par Microsoft et Netscape, S/MIME a reçu l’aval d’autres
éditeurs de produits de messagerie. S/MIME est le protocole de courrier électronique sécurisé le plus déployé.
PGP/MIME
PGP (Pretty Good Privacy) est un protocole disponible depuis 1991. L’utilisation de PGP a connu un certain succès grâce à son cryptage 31
fort des e-mails et des fichiers. PGP/MIME est une évolution de PGP.
Les deux architectures se différencient par l’authentification :
• S/MIME repose sur les certificats X.509 (une autorité de certification vend un certificat d’identité). S/MIME est orienté vers une adminis-
tration centralisée au niveau d’un référentiel d’entreprise.
• PGP repose sur un système dit de réseau de confiance (on affirme sa confiance en signant les clés publiques de ses amis). Il se fonde sur
une gestion de la politique et des clés par l’utilisateur.
Les plates-formes d’intégration orientées B2B incorporent fréquemment l’un ou l’autre de ces protocoles de sécurisation, voire les deux.
Couche B2B et eAI

La rapidité d’implémentation des solutions sera un critère déterminant. Une interface graphique va se révéler nécessaire pour
parvenir à un bon niveau de productivité. Deux écoles s’opposent quant à la nature des outils susceptibles de répondre au mieux au
besoin.
Les uns, initialement éditeurs d’EAI, partent du constat que le B2B est inutile sans démarche d’intégration EAI préalable. Une plate-
forme capable de gérer les deux démarches se présente donc comme l’outil idéal. Elle offre l’avantage d’être fondée sur des techno-
logies propriétaires issues d’un même éditeur : les deux systèmes communiquent entre eux en conservant de bons niveaux de
performances.
Les autres, éditeurs de solutions B2B, affirment que la démarche d’intégration B2B est une démarche spécifique qu’un outil
généraliste ne peut prétendre adresser efficacement. La spécialisation de leur plate-forme leur permet de fournir davantage de
fonctionnalités et des performances accrues.
L’échange B2B requiert en effet des fonctionnalités que l’échange EAI n’exige pas, comme la gestion des partenaires ou la gestion
de la sécurité. Cependant, rien n’empêche de développer ces fonctionnalités pour la couche B2B d’une plate-forme initialement
dédiée à l’EAI.
Étant donné le lien étroit qui existe dans l’entreprise globale entre ERP, SCM, CRM et e-business, la politique d’intégration doit
également être globale pour être efficace et ne peut être réservée qu’à l’échange B2B. Une plate-forme exclusivement dédiée au B2B
doit donc savoir s’interfacer avec la brique de workflow d’une plate-forme d’EAI en vue d’établir la connexion avec le système d’infor-
mation « interne » de l’entreprise.
À tout besoin d’intégration correspond une ou plusieurs plates-formes ; il convient de déterminer celle qui satisfait le mieux la
demande en fonction de critères prioritaires. Par conséquent, la phase de prototypage est une étape incontournable de tout projet
d’EAI.
Par ailleurs, lorsque la communication interentreprise est normalisée selon des règles communes à un secteur ou à une industrie,
elle peut finalement se dérouler selon les mêmes principes qu’une solution interne : le système reste un système modulaire. On peut
envisager d’élargir son activité avec de nouveaux partenaires ou d’en changer sans remettre en cause l’existant et sans impliquer de
modifications importantes dans la gestion des interfaces avec ses partenaires.
En mettant à disposition un ensemble de services et de procédures d’échanges de données, une entreprise va dévoiler à ses
partenaires une partie de ses mécanismes de traitement de l’information, notamment ceux relatifs aux aspects cruciaux des perfor-
mances et de la sécurité. Nous avons vu que les études sur l’efficacité des systèmes d’information sont devenues monnaie courante
et déterminent la faisabilité d’un partenariat, d’une alliance ou d’une fusion. Les entreprises de l’e-business auront à gérer l’image
de leur système d’information, et ce critère entrera en ligne de compte dans le choix de la mise en œuvre d’un partenariat ou d’une
collaboration.
D’après le cabinet Forrester Research, l’expansion des échanges B2B est légèrement freinée par la relation privilégiée qu’entre-
tiennent les entreprises avec certains partenaires hors de toute considération technologique. Ces habitudes sont d’ores et déjà
bousculées par les besoins de modularité qu’entraînera demain la généralisation des échanges B2B, a fortiori devant l’accroissement
exponentiel du nombre de partenaires interconectés via une e-marketplace.
32
XML et l’eAI
C H A P I T R E
XML et l’eAI
XML, le métalangage de description des données, soutenu par l’ensemble de l’industrie informatique, est appelé à prendre une place
importante sur le marché de l’eAI. Ses avantages intrinsèques le désignent en effet comme une technologie de choix dans ce
domaine : il est capable de résoudre toutes les problématiques d’interopérabilité et sait se greffer à moindre coût sur un existant.
Cette partie reprend un certain nombre d’informations déjà présentées dans ce livre blanc et les regroupe afin d’éclairer les rôles réel
et potentiel tenus par XML dans le monde de l’eAI.
Le chapitre 5 du présent livre blanc, « Marché de l’EAI et offres des éditeurs », montre qu’XML est systématiquement pris en compte
dans une offre d’eAI. S’il est souvent simplement considéré comme un format reconnu par un connecteur applicatif, il est aussi
parfois réservé à des fonctions plus sophistiquées et devient indispensable dès qu’on aborde l’échange B2B.
Nous allons, dans ce chapitre, détailler une architecture parallèle à celle généralement constatée dans les plates-formes d’eAI. Elle
sera illustrée par un exemple tiré d’un cas réel mis en œuvre par les équipes de Cosmosbay.
XML et les six couches du modèle eAI

XML et transport
Les messages extraits des applications peuvent être échangés au format XML et véhiculés sur HTTP – deux standards universels – 33
alors que les MOM reposent généralement sur des technologies propriétaires. L’ensemble est ouvert à d’autres standards, ce qui
prend tout son intérêt dès qu’on traite de sujets tels que la sécurité. Par exemple, dans un échange B2B, les messages XML sur
HTTP peuvent être encryptés avec SSL ou S/MIME et franchir le pare-feu du partenaire sans configuration particulière de celui-ci.
Cependant, le fait que HTTP n’autorise pas l’asynchronisme des échanges semble lui interdire le titre de middleware de l’intégration.
Modérons cependant ce jugement.
Les MOM non standard ne permettent pas aux systèmes de deux partenaires de se connecter simplement. Cette connexion se réalise
sur des protocoles propriétaires et le modèle de connexion est une reproduction entre deux entreprises du modèle d’intégration point
à point entre deux applications.
Il est plus simple d’interconnecter deux entreprises sur un réseau standard supportant un protocole standard, a fortiori quand ceux-
ci sont mondialement accessibles. HTTP, standard de l’Internet, est la solution. Comme en outre il est non intrusif et permet un
couplage faible des systèmes, il devient de facto le middleware standard de l’intégration B2B, et XML, pour les mêmes raisons,
devient le langage de prédilection pour formaliser ces échanges.
Pour des raisons d’homogénéité, l’entreprise peut souhaiter déployer une architecture d’intégration interne dont les technologies
sont identiques à celles de ses échanges B2B, et ainsi généraliser l’utilisation de HTTP comme protocole standard de son système
d’information. C’est une démarche inverse à celle que nous présentons depuis le début de ce livre blanc et que l’on rencontre dans
les entreprises qui ne disposent pas d’un existant technologique fort. Le système d’information est alors conçu comme un système
intégré faisant communiquer les applications ERP, SCM, CRM et Internet.
EAI De l’intégration à l’e-business / X M L e t l ’ e A I
XML et connecteurs
Véhiculer des messages XML sur HTTP implique un premier niveau de transformation des données en XML par les connecteurs
applicatifs. La communication avec le moteur d’intégration est organisée autour de ce format pivot, comme dans la plate-forme
d’intégration Fusion, de Forte.
Organiser l’intégration en interne par des flux XML favorise la flexibilité du système et la simplification des adaptateurs : l’interface
XML est toujours identique. De plus, une partie de l’intelligence applicative est déplacée au sein du connecteur, ce qui le rend
autonome dans un contexte de distribution de la solution. La montée en charge et la tolérance aux pannes peuvent être gérées au
niveau des connecteurs autrement que par multithreading. L’interface XML d’envoi et d’accueil des données peut être réutilisée pour
d’autres besoins d’intégration ou d’autres projets.
Enfin, l’adoption d’un format pivot comme XML pourrait permettre de découpler les briques du modèle EAI et de s’affranchir de la
technologie propre à un vendeur en sélectionnant les adaptateurs les plus performants du marché. En effet, à l’heure actuelle les
adaptateurs ne savent qu’exploiter les technologies de la plate-forme avec laquelle ils sont fournis. Par conséquent, l’extraction de
données au format XML nécessite souvent de développer ses propres connecteurs et de les intégrer à une plate-forme d’intégration
spécifique. L’élaboration de ce type de plate-forme est évoquée plus loin, dans la section « XML et moteur d’intégration : les serveurs
d’applications ».
Certains éditeurs de progiciels proposent néanmoins aujourd’hui des connecteurs XML avec leurs solutions : SAP propose le
Business Connector, et les principaux SGBD du marché (IBM, Informix, Microsoft, Oracle, Sybase) extraient en XML les données
relationnelles stockées à la demande.
XML et composants
Merci de bien vouloir vous reporter à la section « XML, composants métier et workflow ».
XML et moteur d’intégration : les serveurs d’applications

La mise en place d’une plate-forme d’intégration reposant sur XML et sur HTTP implique un développement spécifique fondé sur un
serveur d’applications. Les raisons et les moyens du déploiement d’une telle application sont décrits ci-dessous.
1. Les serveurs d’applications répondent aux limitations des message brokers :
- Le support des transactions est natif pour certains d’entre eux et peut être corrélé avec la session utilisateur, notion absente d’un
message broker.
34
- Dans ce contexte, les questions de montée en charge et de tolérance aux pannes sont prises en charge nativement par le système
et éprouvées depuis de nombreuses années, alors qu’un éditeur d’EAI traditionnel aura dû développer sa propre technologie.
- Une application d’e-business repose forcément sur un serveur d’applications : celui-ci peut devenir le nœud central du système
intégré.
Il faut cependant développer toute la logique de transformation et de routage, alors que le choix d’un message broker n’impose que
le paramétrage.
2. Les serveurs d’applications fonctionnent généralement de manière synchrone par RPC ou ORB pour invoquer des méthodes sur
les composants. Ceux-ci peuvent à leur tour traiter des messages XML sur HTTP. On généralise ainsi les technologies d’intégration
à l’ensemble du système, sans faire de distinction technologique entre intégration interne et intégration étendue. L’exécution
asynchrone de certains traitements peut être spécifiée, notamment pour ceux portant sur des messages XML. Enfin, il est techni-
quement envisageable de s’interfacer avec un MOM pour disposer d’accès asynchrone grâce aux files d’attente. Java Messaging
Service est l’API implémentée pour les serveurs d’applications Java. On trouve aussi MQSeries chez IBM et MSMQ dans le monde
Microsoft.
3. L’architecture repose sur l’exécution de composants administrés par le serveur d’applications. Ceux-ci sont soit des objets métier
qui gèrent l’exécution des processus métier, soit des composants d’accès aux applications, qui jouent alors le rôle de connecteurs.
Dans tous les cas, ils peuvent être facilement distribués, ce qui résout les questions de montée en charge et de tolérance aux pannes
tout en améliorant la granularité de déploiement des traitements.
XML et l’eAI
• Transformation - La transformation des données XML d’une application à l’autre est effectuée au moyen de feuilles de styles
XSL (eXtensible StyleSheet Language) au niveau des connecteurs ou des composants métier. La centralisation du déploiement
rend cette solution particulièrement facile à maintenir et évolutive. On peut de plus mettre ainsi à profit les fortes capacités
d’agrégation d’XML pour établir une communication many-to-many.
• Flexibilité et évolution - La structure des documents XML peut être modifiée sans qu’il faille également modifier la logique
codée dans les composants métier. Par exemple, l’ajout d’une nouvelle balise dans un document XML est transparent pour les
composants existants.
• Administration - Un message XML reste lisible et compréhensible même en dehors de ses applications sources et destina-
taires. On n’aura donc aucune difficulté à l’interpréter.
4. Tous ces éléments ont conduit des éditeurs de serveurs d’applications à proposer une offre dédiée à l’intégration alors qu’ils ne
disposent pas d’une technologie de message broker.
- Oracle propose Oracle Integration Server, combinaison de briques existantes : Oracle 8i pour stocker le référentiel d’intégration,
JServer pour l’exécution de composants métier et JDeveloper pour leur développement, des adaptateurs applicatifs (comme
le connecteur SAP, de webMethods) et un MOM (Oracle Advanced Queuing).
- Microsoft propose SQL Server, le couple ASP/IIS, Visual Studio et MSMQ.
- IBM propose DB2, la plate-forme WebSphere/VisualAge et MQSeries.
- BEA propose la plate-forme WebLogic et Symantec Café, joints à une base de données d’un éditeur tiers. Deux applications
sont plus spécifiquement dédiées à l’intégration : eLink pour l’intégration interne et WebLogic Collaborate pour l’intégration
étendue.
- Et il en existe de nombreux autres…
De leur côté, les éditeurs traditionnels de l’EAI ont cherché à enrichir leur offre d’intégration interne ou étendue par un serveur
d’applications dédié aux applications d’e-business. C’est le cas de Level 8 avec Geneva Enterprise Integrator ou de Mercator avec
Web Integration Broker. Ces offres s’insèrent dans une offre d’intégration globale et répondent à la nécessité de mettre en œuvre des
solutions d’e-business synchrones en « temps réel ».
En effet, les plates-formes d’intégration e-business doivent aujourd’hui répondre aux besoins synchrones comme aux besoins
asynchrones. Serveurs d’applications et message brokers apparaissent ainsi davantage comme des technologies complémentaires
que comme des technologies concurrentes pour le système d’e-business.
5. Les connecteurs applicatifs sont généralement absents des offres reposant sur les serveurs d’applications. Il faut prévoir un
développement spécifique ou s’intéresser aux outils fournis avec les progiciels, comme le Business Connector avec SAP R/3.
Il faut en outre développer le moteur d’intégration, sous forme de référentiel couplé aux composants métier. Il convient de spécifier
35
très finement l’ensemble afin d’obtenir une solution évolutive, capable d’intégrer ultérieurement d’autres applications.
Certaines solutions d’intégration, telles que Roma, de Candle, fournissent une API qui implémente les fonctionnalités d’intégration
depuis des composants COM (en C++ ou en Visual Basic) et Java.
6. Le choix entre plate-forme d’intégration et développement spécifique se fondera principalement sur le rapport besoin d’inté-
gration/coût. Plus nombreuses sont les applications à intégrer, plus nombreux sont les connecteurs à implémenter, et plus élevé est
le montant total du projet d’intégration. On réservera une telle architecture au développement de petits projets d’intégration,
comportant un nombre restreint d’applications à intégrer à court et à moyen terme.
En revanche, si vous souhaitez intégrer plus de quatre applications existantes puis, par la suite, d’autres applications, il est préférable
d’envisager l’utilisation d’une plate-forme éditeur qui pilotera l’ensemble des échanges du système, et, éventuellement, de l’inter-
facer avec les serveurs d’applications existants.
En somme, le choix d’une plate-forme d’intégration éditeur n’est pas lié à la taille de l’entreprise, mais bien au besoin d’intégration.
Un exemple de projet d’intégration fondé sur un serveur d’applications et mené par Cosmosbay est détaillé plus bas. Il faut insister
sur le fait qu’une telle plate-forme n’est pas le « choix du pauvre » ; au contraire, par son respect des standards et l’utilisation de
technologies homogènes pour l’ensemble du système d’information, cette solution se présente comme une solution pérenne,
évolutive et adaptée aux contraintes de réactivité de l’e-business.
XML, composants métier et workflow

Avec l’interaction de composants métier issus des processus métier et capables d’interpréter la sémantique des données reçues, la
plate-forme d’EAI gagne en intelligence et en sophistication.
Les messages XML véhiculent la description des données en même temps que les données elles-mêmes. Chaque message XML est
autosuffisant ; on peut le considérer comme un message métier qui connaît la nature des traitements à effectuer sur les données
qu’il véhicule et qui laisse au moteur d’intégration le soin d’effectuer l’opération. Un moteur de workflow peut être capable d’inter-
préter les messages métier XML et de partager ainsi les données, mais aussi les processus. En effet, s’il sait également exporter en
XML la définition des processus métier qu’il modélise, l’entreprise pourra partager ses processus métier avec ses partenaires pour
mettre en œuvre le réseau neuronal XML.
GE
PME GE
PME GE
GE Entreprise GE
pivot PME GE
PME GE
GE
PME PME PME PME
Le réseau de type moyeu et Le réseau neuronal XML

rayons classique
GE = Grande Entreprise
PME = Petite ou Moyenne Entreprise
Figure 8 – Évolution des relations interentreprises
36
De plus, les capacités d’agrégation d’XML peuvent être exploitées dans le cas d’un rendez-vous entre deux processus, pour envoyer
le message résultant à l’application cible.
Enfin, XML assure la liaison entre les processus publics et privés de l’entreprise par l’utilisation de technologies communes dans la
définition et la mise en œuvre de ces processus. Les partenaires définissent à plusieurs les étapes d’un processus métier inter-
entreprise. Le processus est codé en XML pour en faciliter l’échange et la modélisation via un client XML. C’est le choix retenu par
TIBCO avec l’acquisition de la société Extensibility et l’intégration de ses outils de conception de documents et de structures de
données XML à sa plate-forme ActiveEnterprise.
XML et l’eAI
XML et B2B
XML est le format incontournable dès qu’il est question d’échanges interentreprises. Avec XML, il devient aisé de transmettre des
informations à un partenaire sans en connaître l’existant technologique, sans avoir à s’y adapter techniquement ni à s’y introduire
de façon logicielle. En couplant faiblement les systèmes, la technologie constitue de fait un moteur et non plus un frein à l’extension
des échanges.
L’échange B2B s’organise aujourd’hui autour d’une entreprise pivot, qui sert de relais et pilote les transactions pour un ensemble de
partenaires au moyen d’échanges normalisés par des langages fondés sur XML.
XML, langage privilégié de l’échange B2B

L’industrie informatique connaît une effervescence soutenue depuis quelques temps déjà à cause de la finalisation des langages qui
vont standardiser les échanges interentreprises et implémenter des plates-formes techniques capables de les supporter. Ces
initiatives vont de l’élaboration de langages de normalisation de catalogues ou d’achats (e-procurement) jusqu’à la formalisation des
agréments entre partenaires (avec le langage tpaML, d’IBM) ou de l’EFI (échange de formulaires informatisés).
Le tableau ci-dessous récapitule les initiatives les plus importantes.
Initiative Instigateur Type
BizTalk Microsoft framework XML pour l’ensemble de l’industrie et référentiel de formats d’échange
cXML Ariba Software e-catalog et transactions financières pour les places de marché
ebXML Oasis et UN/Cefact framework XML pour l’ensemble de l’industrie et référentiel de formats d’échange
eCO consortium framework XML pour l’ensemble de l’industrie et référentiel de formats d’échange
IOTP IETF commerce électronique grand public
OBI CommerceNet (consortium) gestion des achats (X.12)
RosettaNet consortium framework XML pour l’ensemble de l’industrie et référentiel de formats d’échange
xCBL Commerce One e-catalog et transactions financières pour les places de marché
tpaML IBM agréments entre partenaires commerciaux 37
XFDL PureEdge formulaires électroniques (EFI)
XFA JetForm formulaires électroniques (EFI)
Cette section présente les principaux organismes moteurs de cette normalisation et les initiatives qu’ils promeuvent. On constate
que la quasi-totalité de ces normes d’échanges pour l’Internet sont des langages conçus à partir d’XML, lui-même conçu pour
l’Internet.
B2B et EDI
Il faut des intérêts communs et une volonté partagée pour parvenir à mettre en œuvre une synergie d’échange interentreprise. Il faut aussi
disposer de normes et de standards pour partager des données décrites dans un vocabulaire symétriquement compréhensible par les
parties impliquées.
Cette idée évoque sans doute des notions familières à certains : elle est le fondement des procédures d’EDI. La complexité et la durée de
déploiement de ces procédures en ont restreint la propagation à des grands comptes. L’EDI concerne à l’heure actuelle 2 % des entreprises ;
c’est peu.
Pour impliquer les PME et les PMI dans ces chaînes d’échange, d’autres normes, plus légères, faciles à implémenter et adaptées à l’Internet,
sont requises. Idéalement, le format pivot de ces normes reposera sur XML. En ce sens, XML n’a pas pour objectif de remplacer l’EDI, mais
de fournir une solution de rechange flexible et complémentaire.
Ainsi, XML va permettre des échanges orientés conversation, alors que l’EDI est mieux adapté au dialogue. Plus léger, XML permet de
réfléchir à l’instauration de frameworks globaux alors que l’EDI définit principalement des standards sectoriels.
Le B2B apparaît donc comme un EDI léger et personnalisable, à vocation universelle.
cXML, d’Ariba Software

La vocation de l’éditeur américain Ariba Software est de fournir des solutions entièrement dédiées au B2B. Son produit phare, Ariba
B2B Commerce Platform, se propose de mettre en relation tous les acteurs d’une chaîne d’échange, notamment par la création d’e-
marketplaces.
cXML (commerce XML) est une initiative fondée sur XML en vue de traiter les échanges de catalogues produits avec les fournis-
seurs et les transactions induites sur Internet. Le consortium qui y travaille est mené par Ariba Software et comprend plus de 80
organisations. Il inclut un schéma pour la définition d’un catalogue de produits ainsi que les formats d’échange des bons de
commande, des confirmations de commande, etc. ; cXML supporte de nombreux types de contenus fournisseur (et donc de DTD).
cXML a été une des premières initiatives à déboucher sur une issue concrète. Il est à présent couramment pris en charge par les
offres B2B. Cosmosbay présente une mise en œuvre de cXML dans son ouvrage XML et Java, aux éditions Eyrolles.
Pour en savoir plus, visitez :
• Ariba Software : http://www.ariba.com ;
• cXML : http://www.cxml.org.
xCBL, de Commerce One

Commerce One (anciennement DistriVision) existe depuis 1994 (depuis 1997 en France) et participe à de nombreuses initiatives
relatives à XML : membre du W3C, de l’IETF (Internet Engineering Task Force), des groupes de travail Oasis (donc eCo et ebXML),
OBI (Open Buying on the Internet), RosettaNet et BizTalk.
Fondateur du global trading web, une volonté d’interconnecter des e-marketplaces pour créer une place de marché globale,
Commerce One a pour vocation de mettre en relation acheteurs et vendeurs.
Commerce One est à l’origine d’un langage d’échange B2B reposant sur XML et nommé xCBL. La spécification actuelle, xCBL 2.0,
permet de créer des documents XML dédiés à l’échange B2B et fournit des passerelles avec les échanges EDI traditionnels. xCBL
est gratuit et disponible sur les référentiels en ligne tels que BizTalk ou xml.org ainsi que sur le référentiel maison, MarketSite.
Commerce One propose BuySite, un logiciel d’e-procurement, qui gère l’émission des bons de commande, MarketSite, technologie
d’e-marketplace qui gère la consolidation des catalogues et les transactions, et MarketBuilder, version allégée de MarketSite
permettant à des communautés spécialisées de construire leurs portails verticaux sans devoir se charger de leur gestion technique.
Enfin, Commerce One travaille actuellement avec Rational Software à la formalisation d’une méthode UML (Unified Modeling
Language) adaptée à l’échange B2B de documents à base de messages XML.
38
• Commerce One : http://www.commerceone.com ;
• MarketSite : http://www.marketsite.net.
OBI, de CommerceNet
Lancé en avril 1994, CommerceNet est un consortium à but non lucratif regroupant aux États-Unis plus de 600 entreprises et organi-
sations qui se proposent de « transformer l’Internet en une place de marché électronique ». Le but est de développer des standards
ouverts pour l’achat sur Internet.
L’initiative de CommerceNet est comparable à celle de Commerce One. Le consortium OBI (Open Buying on the Internet) est le
résultat des travaux de CommerceNet.
Les travaux, débutés en septembre 1997, ont abouti début mai 2000 à la spécification OBI 2.1, fruit du travail conjoint d’acteurs
comme American Express, Barnes and Noble, Lockheed Martin, Microsoft, Netscape et d’un ensemble d’experts des achats et du
commerce en ligne. L’objectif est la réduction du coût des transactions d’achat sur Internet grâce à l’automatisation et à la désinter-
médiation.
XML et l’eAI
OBI définit un simple format de catalogue et un protocole de commandes. Les fonctionnalités incluent :
• une méthodologie pour utiliser des applications EDI avec des systèmes compatibles OBI ;
• des processus d’accès standardisé aux catalogues électroniques ;
• des formats de données standard pour décrire les données des commandes et les transmettre d’un partenaire à l’autre ;
• des mécanismes standard de sécurité, d’authentification et de non-répudiation ;
• le support des transactions internationales en devises.
La version 3.0 intégrera XML dans les bons de commande et les bons de livraison.
• CommerceNet : http://www.commercenet.com ;
• OBI : http://www.openbuy.org.
eCo, de CommerceNet
Le système eCo a été initié en juillet 1998 par CommerceNet. Son objectif est l’établissement d’une plate-forme autorisant l’inter-
opérabilité logicielle, étape indispensable à la mise en œuvre des transactions électroniques.
Les domaines couverts sont :
• les services métier ;
• les termes métier ;
• les services de conformité et de validation ;
• les rôles et les activités dans l’e-commerce ;
• les standards de paiement ;
• les mécanismes de sécurité ;
• le contexte de workflow et de traitement des processus ;
• les types d’informations impliqués dans une transaction.
Les travaux effectués sont incomplets et n’ont pas eu un grand impact sur les entreprises. Ils ont néanmoins le mérite de servir de
base de travail aux groupes de travail ebXML depuis septembre 1999.
ebXML, de l’UN/Cefact et Oasis 39

L’UN/Cefact est une entité des Nations unies dont les directives incluent le développement stratégique et technique du commerce
électronique et de l’e-business.
Oasis (Organization for the Advancement of Structured Information Standards) est quant à lui un consortium à but non lucratif. Son
objectif est la promotion des formats non propriétaires fondés sur tout standard permettant le traitement de l’information structurée,
tels que SGML et XML. Les membres d’Oasis sont des spécialistes de ces technologies. Oasis regroupe un grand nombre d’acteurs :
certains sont « institutionnels » (IBM, Informix, Microsoft, Oracle, SAP, Sun Microsystems), d’autres sont issus du monde de l’EAI
et du B2B (Bluestone, Extricity, Mercator, Netfish) ou du monde de l’EIP ou de la gestion documentaire (ArborText, DataChannel,
Documentum, Sequoia, etc.).
• Oasis : http://www.oasis-PGP/MIME ;
• Référentiel : http://www.xml.org.
Pour minimiser la prolifération des initiatives et fédérer le développement du commerce électronique, l’UN/Cefact et Oasis ont lancé
ebXML (electronic business XML). ebXML est une initiative ouverte et indépendante visant à établir un framework technique et
sémantique global articulé autour du métalangage XML. Les six premiers mois de travaux ont abouti à l’approbation des sujets de
spécifications et à une démonstration de la viabilité du concept (tests de routage des messages ebXML).
Cette initiative permet d’y voir plus clair dans ce monde qui gravite autour d’XML et de la « fusion » XML/EDI. Cent vingt entités ont
porté leur soutien à ce projet, créé en septembre 1999, qui s’est donnée 18 mois pour atteindre ses objectifs.
Applications Integration Technology
UN W3C
ebXML
XML
CEN Steering
Committee
OASIS
Sectors Working
Groups
National Semantic
Repositiories Editors
Bodies
Commerce ISO TC 154 BizTalk,

One BSR etc.
Figure 9 – Groupes de travail autour d’ebXML
ebXML reprend le travail effectué par le framework eCo Architecture, qui concurrence en quelque sorte des projets tels que BizTalk,
mais qui est plus universel car détaché des considérations propriétaires.
ebXML compte favoriser le développement de modèles de documents directement exploitables par l’industrie. L’association annonce
par ailleurs la constitution d’un groupe d’experts internationaux chargés de décliner les spécifications techniques de futurs formats
XML sectoriels. Le public visé va de la TPE (très petite entreprise) à la multinationale.
Les objectifs déclarés sont :
40
• de permettre l’utilisation simple, facile et universelle d’XML pour l’e-business ;
• de faire correspondre la structure et le contenu des éléments des vocabulaires XML définis ;
• de fournir une infrastructure globale, ouverte, interopérable et non propriétaire pour l’échange B2B ;
• de répondre aux besoins métier en termes d’architecture ;
• de spécifier et de fournir une courbe d’apprentissage rapide pour les entreprises des pays en voie de développement ;
• d’éviter d’imposer des prérequis financiers, techniques et applicatifs à ceux qui souhaitent participer, principalement aux petites
entreprises ;
• de faciliter le support multilingue.
Cet énoncé montre une concordance évidente entre des objectifs ambitieux (démarche internationale désireuse d’intégrer tout type
d’acteur) et la présence d’XML.
ebXML vise à englober toutes les initiatives pour définir une architecture globale incluant :
• les messages ;
• les processus ;
• les traitements ;
• des répertoires et des référentiels pour stocker les exigences spécifiques aux industries.
XML et l’eAI
Huit facteurs d’interopérabilité sont ainsi définis :

• processus métier (exécution d’une transaction métier) ;
• sémantique ;
• vocabulaire : connexion des mots à des sens sémantiques ;
• encodage des caractères : utilisation d’Unicode ;
• expression : définition des éléments de structure semblables ;
• sécurité ;
• protocole de transfert de données ;
• réseau.
ebXML est une initiative ouverte, publique et indépendante. Il est encore trop tôt pour déterminer si ebXML remplira tous les
ambitieux objectifs fixés. L’enjeu n’est rien de moins qu’un standard international qui recueillera le soutien de nombreuses
entreprises de par le monde. ebXML est une formidable chance pour le commerce électronique et l’initiative la plus prometteuse en
cours d’élaboration.
Pour en savoir plus, visitez http://www.ebxml.org.
BizTalk, de Microsoft
Avec BizTalk, Microsoft aspire à créer un framework du même type qu’eCo ou qu’ebXML. Ce projet est aussi une démarche visant à
présenter simultanément aux entreprises un framework XML, un référentiel et un logiciel B2B.
La version 2.0 du framework gère la création et la publication des formats d’échange par HTTP et SMTP, soit : les spécifications d’un
format d’enveloppe et de routage de messages XML, la compatibilité avec le protocole SOAP 1.1 (Simple Object Access Protocol)
et Multipart MIME (Multipurpose Internet Mail Extensions).
Le référentiel en ligne centralise les formats XML reconnus par l’industrie. Cette initiative concurrente de xml.org fournit un corpus
d’échange B2B utilisant la technologie XML-Data.
Le prolongement de cette démarche est l’implémentation d’un serveur d’échange B2B, BizTalk Server, dédié au développement, à
l’exécution et à l’administration des processus d’entreprise distribués et qui s’interface au mieux avec l’architecture DNA de
Windows 2000.
41
BizTalk Server propose les éléments suivants :

• Outils graphiques de développement – BizTalk Editor et BizTalk Mapper sont dédiés au développement et à la transformation
des schémas XML et des documents métier.
• Moteur d’échange de documents – Documents à base de formats XML, mais aussi EDI (Edifact et X.12), ainsi que de fichiers
plats.
• Moteur robuste et sécurisé – Sécurité PKI, signatures digitales et encryptage.
• Adaptateurs applicatifs.
BizTalk est soutenu par un ensemble de consortiums et d’initiatives B2B, comme l’OAG, SAP ou Commerce One, qui proposent
principalement des schémas pour le référentiel en ligne. Des utilisateurs finaux se joignent également au projet (Boeing, BP/Amoco)
et participent aux spécifications.
• Microsoft : http://www.microsoft.com ;
• BizTalk : http://www.biztalk.org.
RosettaNet
RosettaNet est un standard destiné à résoudre sur Internet les problèmes liés au manque de régulation de la chaîne logistique par la
standardisation des processus métier et par l’établissement d’échange d’informations et de transactions commerciales automatisées.
TELEPHONE e-APPLICATION
PROCESS METIER PROCESS eBUSINESS
RosettaNet
DIALOGUE PIP
GRAMMAIRE FRAMEWORK
MOTS DICTIONNAIRES
42 ALPHABET HTML XML
SON INTERNET
Echange professionnel Echange professionnel
entre personnes entre systèmes informatiques
Figure 10 – Couches (layers) de RosettaNet
RosettaNet accorde autant d’importance à la définition de standards de données qu’à la définition de standards de processus. Le
RNIF (RosettaNet Implementation Framework) spécifie le cadre d’implémentation des standards de processus et de données.
Les travaux sont orientés vers la définition de dictionnaires commerciaux et techniques. Des propriétés communes sont définies
pour chaque produit (destinées à faciliter leur comparaison financière et technique), pour chaque partenaire et pour les transactions.
Les PIP (Partner Interface Processes) définissent les séquences d’étapes nécessaires pour compléter un processus B2B (le passage
d’un ordre de commande, par exemple). Ils déterminent aussi l’échange d’information et les transactions générées par le franchis-
sement de chacune des étapes d’un processus. Ils définissent enfin les processus publics et les données associées nécessaires pour
conduire des transactions électroniques sur Internet.
RosettaNet utilise UML et OCL (Object Constraint Language) pour définir les processus métier B2B, et XML pour décrire les formats
de données.
XML et l’eAI
En février 2000, RosettaNet a publié des spécifications détaillées pour différents PIP. On trouve par exemple la distribution de
nouvelles informations produit (PIP2A1), la recherche d’informations techniques (PIP2A5) ou la gestion d’ordres de commande
(PIP3A4).
RosettaNet est actuellement mis en œuvre dans le secteur des technologies de l’information (notamment par Dell qui l’a utilisé pour
fédérer toute sa chaîne d’échange fournisseurs) et dans l’industrie des composants électroniques.
RosettaNet se pose ainsi comme l’initiative la plus directement concurrente de ce qui existe aujourd’hui dans le monde de l’EDI.
Pour en savoir plus, visitez http://www.rosettanet.org.
Autres initiatives
AL3 (Automation Level 3) est une initiative conduite par Acord, organisme à but non lucratif chargé de définir des standards dans
le monde de l’assurance.
Swift (Society for Worldwide Interbank Financial Telecommunication) est une des plus célèbres organisations de ce domaine ; elle
définit un standard pour le monde de la banque et de la finance. Quelque 7 000 institutions financières réparties dans 200 pays en
sont membres.
HL7 (Health Level 7) est le protocole standard utilisé par le monde de la santé.
Enfin, l’OAG a publié 122 DTD XML pour différents types de transactions.
En résumé…
Les standards sont des pièces indispensables du puzzle B2B. Cependant, ils sont longs à concevoir et à implémenter. Certains sont
déjà dépassés lorsqu’ils arrivent sur le marché : les entreprises sont obligées d’agir avant qu’ils soient disponibles et constatent
conséquemment l’apparition de nouveaux besoins.
Les standards d’échange doivent donc être flexibles ; le support d’XML conduit justement à cette flexibilité. Les processus doivent
aussi être évolutifs : des référentiels en ligne peuvent permettre de bénéficier rapidement de l’évolution d’un standard. Ils doivent
enfin pouvoir être personnalisés si plusieurs partenaires trouvent un accord dans le cadre de leurs échanges. Il importera alors de
conserver une compatibilité entre le format dérivé et le standard d’origine.
Certaines entreprises pourront ainsi apporter aux standards les améliorations qu’elles jugent nécessaires, conférer un surcroît de
compétitivité à leurs échanges et conserver cet avantage concurrentiel tout en respectant les normes internationales en vigueur.
Une architecture alternative d’EAI bâtie sur XML 43
Cosmosbay a été consulté au début de l’année 2000 pour concevoir, élaborer et réaliser la plate-forme intranet-extranet de l’un de
ses clients. Il s’agissait d’une grande entrerprise du domaine du matériel électrique, dotée d’un grand nombre de systèmes et de
sources de données. Le besoin fort était de réutiliser les informations présentes dans les sources de données suivantes :
• un progiciel de CRM nommé GRC (gestion de la relation client) ;
• un ERP (SAP R/3) ;
• une application spécifique qui gère le catalogue produits.
Ces données doivent pouvoir être consultées, modifiées et enrichies par les collaborateurs du groupe. Le choix d’une interface de
type web (un portail d’entreprise) a été fait. Les données sont ensuite mises en forme à destination des partenaires du groupe (instal-
lateurs, distributeurs, revendeurs) pour obtenir des informations sur les produits et passer des commandes en ligne. Un front-office
d’e-commerce de type extranet a été envisagé, avec l’objectif pour notre client de se poser comme fournisseur privilégié de ses
partenaires.
L’architecture qui a été retenue ne repose pas sur un message broker utilisant un MOM mais sur un serveur d’applications utilisant
HTTP comme middleware. Plusieurs raisons président à ce choix :
• Le petit nombre d’applications à intégrer.

• Un nombre élevé d’échanges asynchrones.
• Les données dont la disponibilité doit être permanente (celles du front-office Internet) sont dupliquées dans une base de
données qui sert de référentiel de synchronisation.
Avant de détailler davantage cette architecture, nous allons l’illustrer par une représentation graphique.
X
R
GRC CONNECTEUR M
E L
F
X
E ERP CONNECTEUR M
R L
E
X
N DEVT CONNECTEUR M
T SPECIF L XML/
I HTTP Serveur W Applications
WORKFLOW Serveur de de E CLIENTES
E transactions Journal
Présentation
B
L Clients
Composant
métier
X
M
FRONT
L
XML/HTTP FRONT OFFICE
X
(SSL) OFFICE e-Commerce
Composant
M
Produits métier L
Pages actives EXTRANET
Composant X
Acteurs métier M /
L
INTRANET
Données Métier Présentation
Figure 11 – Architecture EAI retenue
44 Il s’agit clairement d’une architecture à trois niveaux (3-tiers) avec une problématique d’intégration. Nous allons nous arrêter en
détail sur chacun des éléments qui la composent : les applications front-office, les sources de données, le référentiel de synchroni-
sation et le moteur d’intégration.
Applications front-office
Serveur W Applications
de E CLIENTES
Présentation
B
FRONT
FRONT OFFICE
OFFICE e-Commerce
Pages actives EXTRANET

/
INTRANET
Figure 12 – Front-office
XML et l’eAI
La partie serveur front-office (à gauche) et les applications clientes (à droite) communiquent via Internet et HTTP ; il s’agit d’une
configuration désormais traditionnelle : HTTP y tient la place qu’il occupe au sein de millions de serveurs d’applications de par le
monde.
Dans une logique d’intégration, le front-office Internet est une application comme les autres, au même titre que SAP ou que le
progiciel de gestion de la relation client. Si elle figure à part dans notre schéma d’architecture, c’est parce qu’elle représente l’objectif
dans lequel cette architecture d’intégration a été mise en place et qu’elle illustre parfaitement les raisons qui poussent les entreprises
à se tourner aujourd’hui vers des solutions d’intégration.
Sources de données
On retrouve l’ensemble des sources de données de l’entreprise : le progiciel de gestion de la relation client, l’ERP et le développement
spécifique.
X
R
E GRC CONNECTEUR M
L
F
E
X
R
E ERP CONNECTEUR M
N L
T
I X
E
DEVT CONNECTEUR M
L SPECIF L
Figure 13 – Sources de données
Ces applications sont exécutées soit sur des plates-formes Windows NT, soit sur des plates-formes Sun Solaris. Un serveur HTTP
et un serveur d’applications ont été placés sur chaque plate-forme : IIS sur la plate-forme Microsoft et le couple Apache/JServ sur
la plate-forme Unix. 45
Chaque bloc connecteur de la figure ci-dessus est donc en réalité un composant exécuté et géré par ces serveurs d’applications. Ce
composant connaît la logique de transformation des données qui lui parviennent. Il n’y a donc pas, comme dans le cas d’une plate-
forme d’intégration gérée par un message broker, de traduction des données d’un format natif dans un autre format natif.
Ici, tout format natif est systématiquement converti en XML, format pivot des échanges du système d’information ; ce message XML
est ensuite envoyé au connecteur branché sur l’application destinataire, qui transforme ce format XML en format natif (via une feuille
de styles XSL, par exemple) avant de le transmettre à l’application.
Dans cette architecture, ce sont les connecteurs qui effectuent la transformation. Ils disposent de l’intelligence de transformation,
qui n’est pas centralisée au sein d’un référentiel sur une machine unique. On retrouve ce principe dans les plates-formes d’EAI du
marché qui savent dupliquer et distribuer le référentiel central vers des serveurs distants, comme Roma, de Candle, ou e*Gate, de
STC.
Le connecteur SAP, fourni en standard, est une solution packagée nommée Business Connector qui code sa propre logique de
transformation ; il permet d’économiser du temps de développement sur le projet.
Dans notre architecture, les traitements sont synchrones sur HTTP, mais rien n’interdit d’adjoindre une technologie de files d’attentes
(ou des échanges SMTP) sur nos serveurs d’applications pour obtenir des traitements asynchrones.
Les connecteurs sont des composants capables de gérer deux types de flux de données : XML d’un côté, natif de l’autre. Ces
composants peuvent facilement être distribués sur différentes machines en vue de gérer un autre aspect important : la montée en
charge.
Moteur d’intégration
Si l’architecture des connecteurs est distribuée et possède l’intelligence de transformation, il n’en reste pas moins que nous avons
besoin d’un moteur d’intégration pour orchestrer les échanges entre les différentes applications.
Serveur de
WORKFLOW transactions Journal
X
Composant M
Clients métier L
Composant X
M
Produits métier L
Composant X
M
Acteurs métier L
Figure 14 – Moteur d’intégration
Oracle 8i sert à la fois de base de données pour le référentiel de synchronisation et de moteur d’intégration exécutant des
composants Java chargés de réaliser l’intégration.
Les messages XML en provenance des connecteurs applicatifs déclenchent des événements au sein des composants métier gérés
par JServer. Ces composants alertent le moteur Oracle Workflow du début de la transaction. Le moteur de workflow se charge alors
de piloter la transaction, en répercutant les messages XML dans les applications qui ont besoin de ces données pour poursuivre le
processus métier.
Enfin, un serveur de transactions permet de reprendre une transaction qui a échoué ou de déterminer la cause de son échec.
Référentiel de synchronisation
46 Toutes les données nécessaires au fonctionnement du front-office et déjà présentes dans le système d’information sont dupliquées
dans Oracle 8i ; l’application de front-office fonctionne avec les données qui sont contenues dans ce référentiel, mais jamais
directement avec des données extraites de l’ERP, du CRM ou de l’application spécifique.
Aucun MOM n’apparaît dans notre schéma. Tous les échanges reposent sur des messages XML véhiculés par HTTP. L’ensemble des
échanges est synchrone, ce qui, nous l’avons vu, peut se révéler contraignant dans une logique d’intégration.
Ces choix ne sont pas en contradiction avec la logique d’intégration mais permettent au contraire de s’affranchir des contraintes
inhérentes au Web dans le cadre de la construction d’un système B2B. En effet, des systèmes tels que SAP dans notre cas, mais
aussi tous les mainframes, pour ne citer qu’eux, font l’objet d’opérations de maintenance et de traitements batch à des heures où
les utilisateurs de ces systèmes (les collaborateurs de l’entreprise) ne s’en servent pas. Pendant ces opérations, ces systèmes sont
normalement indisponibles.
Or, un internaute est susceptible de naviguer et d’utiliser l’application à toute heure du jour et de la nuit, y compris le week-end. Le
front-office doit rester disponible en permanence.
Pour répondre à cette nécessité, les données du front-office sont stockées dans une base de données Oracle 8i dédiée. Il apparaît
donc important de synchroniser au plus tôt les données entre les sources, d’où la nature synchrone des échanges et l’utilisation d’un
middleware adapté à ce besoin. L’emploi de HTTP nous permet d’utiliser un middleware unique employant un format de messages
métier unique : XML. Le référentiel Oracle, base de données du front-office Internet, devient également un référentiel de synchroni-
sation.
XML et l’eAI
Le moteur de workflow se trouve aussi investi d’un nouveau rôle. Il ne travaille plus seulement à son niveau d’abstraction habituel
de surveillance de l’exécution des processus courants ; il opère aussi sur une couche plus basse en contrôlant le déroulement des
opérations de synchronisation et leur séquencement. Lorsqu’une opération de synchronisation ne peut être menée à terme, il est
capable de la reprendre ou de notifier l’incident à l’administrateur. Celui-ci peut alors effectuer l’opération manuellement en
interprétant lui-même le message, tâche facilitée si l’opération prend la forme d’un message XML.
47
EAI De l’intégration à l’e-business / M a r c h é d e l ’ E A I e t o f f r e s d e s é d i t e u r s
C H A P I T R E
Marché de l’EAI et offres des éditeurs
Panorama du marché de l’EAI

Quelques chiffres
IBM, le leader, détient 20 % des parts de marché. Les acteurs suivants sont Neon, Mercator, Tibco et webMethods, tous quatre
autour de 10 %.
Les meilleures progressions du premier semestre 2000 sont celles de BEA, GEIS (General Electric Internet System), STC et Vitria.
Plus de 30 % du marché restent cependant détenus par des acteurs figurant hors du top 10. Ceci garantit une compétition forte et
une progression technologique des offres importante.
Aujourd’hui, il n’y a pas de plate-forme d’intégration optimale, mais des plates-formes qui répondent à des besoins d’intégration
divers :
• Intégration de données ou modélisation des processus métier ?
• Volume des données à échanger.
• Nombre et type des applications à intégrer.
• Nécessité d’échanges externes B2B ? Type de ces échanges (support des initiatives XML).
• Site centralisé ou géographiquement réparti (moteur d’intégration conçu pour un système distribué) ?
Les services offerts autour de la technologie (méthodologie, conseil, formation, support technique) ont également une grande
importance.
48
Tendances
Une tendance marquée de ce domaine est la consolidation du marché. La notion d’intégration s’étant considérablement élargie ces
derniers temps, l’enrichissement rapide d’une offre s’effectue par croissance externe plutôt que par de nouveaux développements
techniques.
Les acquisitions récentes d’Active Software par webMethods et d’OnDisplay par Vignette illustrent ces mouvements. Level 8 a
construit la dernière version de son offre en rachetant XIPC, Seers et Template Software. Par le passé, Neon Software a acquis VIE
System, SLI International AG, MicroScript et ConvoyCorporation. Mercator a absorbé en 1999 Braid Systems et Novera.
Cette tendance permet au client de ne pas voir les acteurs se multiplier lors de la mise en œuvre d’un projet global d’intégration. Le
client veut en effet des solutions end-to-end. Le rapprochement des acteurs leur permet de répondre plus rapidement aux attentes
des clients, de maintenir les supports techniques existants et, temporairement, les versions de produits. D’autre part, la constitution
d’acteurs de taille plus importante garantit plus sûrement leur pérennité.
Il est fort probable que ce mouvement général d’alliances, de partenariats et d’acquisitions va se poursuivre. Cette situation permet
aux éditeurs actuellement présents sur le marché de bâtir des offres globales et robustes à l’heure où des acteurs « institutionnels »
disposant de moyens élevés, tels qu’Oracle ou Sun Microsystems (via Forte), font leur entrée.
Enfin, des jeux de partenariats se constituent. Par exemple, Neon s’est allié à BEA, à BroadVision, à Commerce One et à Microsoft
et collabore toujours avec IBM pour le développement de MQIntegrator. D’une manière générale, les partenariats sont nombreux, y
compris entre les acteurs de l’eAI, qui travaillent à faire communiquer leurs plates-formes entre elles.
Les offres
Pour cette étude, nous avons préféré vous présenter les acteurs spécifiques au monde de l’EAI et du B2B plutôt que les solutions
des grands éditeurs « institutionnels » de l’industrie informatique.
Nom de l’éditeur Site web Offre

Candle http://www.candle.com Roma
Constellar http://www.constellar.com Constellar Hub
Level 8 http://www.level8.com Geneva
Mercator Software http://www.mercator.com Mercator
Neon Software http://www.neonsoft.com e-Biz Integrator
STC http://www.stc.com e*Gate
Tibco http://www.tibco.com ActiveEnterprise
Viewlocity http://www.viewlocity.com AMTrix
Vignette-OnDisplay http://www.ondisplay.com eIntegrate
webMethods http://www.webmethods.com ActiveWorks
B2B Integration Server
Nous ne pouvons bien sûr pas présenter tous les acteurs qui émaillent le marché de l’EAI. Certains n’ont pu répondre à temps à nos
questions ; nous intégrerons probablement leur offre dans une prochaine version de ce livre blanc. Nous avons exclu les éditeurs
non représentés en France pour des raisons difficultés de relations clients dans les phases de conseil, de formation et de support
au produit. Nous avons néanmoins tenu à citer ces acteurs pour information, et nous vous invitons à aller à la rencontre de leurs
solutions en visitant leurs sites. Certaines offres seront présentées en détail dans les prochaines versions de ce livre blanc.
Nom de l’éditeur Site web Offre

Bluestone Software http://www.bluestone.com/xml/ XML Server 49
CrossWorlds http://www.crossworlds.com CrossWorlds
Extricity Software http://www.extricity.com Extricity AllianceSeries
IBM http://www-4.ibm.com/software/ts/mqseries MQSeries
Forte http://www.forte.com Fusion, Forte for Java
GEIS http://www.gegxs.com Global eXchange
Netfish http://www.netfish.com XDI
Saga http://www.sagasoftware.com Sagavista
Sopra http://www.sopra.fr Règles du jeu
Vitria Technology http://www.vitria.com BusinessWare
Organisation des fiches produits

La première section est consacrée à une présentation générale de la société et aux coordonnées du siège social, des bureaux français
et du contact. Quelques chiffres ainsi qu’un historique sont fournis.
Le produit d’intégration est ensuite présenté, dans ses grandes lignes d’abord, puis brique par brique en respectant le modèle EAI
que nous avons présenté. Une offre d’EAI est un package riche qui comprend différents outils aux fonctionnalités bien distinctes et
aux finalités bien définies : pour chaque couche, nous indiquons le produit correspondant dans l’offre de l’éditeur. Voici ci-dessous,
à titre d’exemple, le modèle EAI de Candle :
B2B
Processus Roma Workflow Access
Moteur d'intégration Roma Broker
Composants
Données Application Environment Connectors
Transport MQSeries / MSMQ
Figure 15 - Modèle EAI de Candle
Les briques natives de la technologie de l’éditeur figurent en gras, les briques fournies avec la solution mais provenant de techno-
logies tierces sont indiquées en police normale.
Une synthèse identifiant la réponse apportée par l’éditeur sur chacun des grands points techniques identifiés est enfin présentée :
Montée en charge Mécanismes natifs prévus pour faire face à des pics de charge ponctuels ou à des
déplacements de plus longue durée de la charge.
Transactions et moniteurs transactionnels Mécanismes natifs qui permettent de définir des transactions longues ou les
connexions possibles à un moniteur transactionnel.
Administration Outils disponibles pour administrer et superviser la plate-forme d’EAI, les

connexions avec des agents réseaux SNMP (Simple Network Management Protocol).
50 Tolérance aux pannes Mécanismes natifs pour pallier les déficiences du système ou du réseau.
Sécurité Mécanismes de sécurité natifs destinés à protéger les échanges internes et les
échanges B2B.
XML Rôle joué par XML dans la plate-forme d’EAI : simple format de données disposant
de son connecteur, langage commun à l’ensemble du système, etc.
Ouverture Connexions possible de la plate-forme à des outils capables d’en accroître la qualité
de service : agents réseaux SNMP, annuaires LDAP, composants métier existants,
etc.
Portabilité Plates-formes pour lesquelles la solution est disponible.
Productivité de développement Rapidité de mise en œuvre de la solution d’intégration.
Déploiement Rapidité de déploiement de la solution d’intégration et capacité à modifier facilement

cette distribution pour optimiser le fonctionnement.
Formation Type et durée des cursus de formation prévus par l’éditeur.

Candle
Siège social Bureaux français
201, N. Douglas St 13, avenue de la Porte-d’Italie

El Secundo, CA 90245 75013 Paris
Tél. : +1 310 535 3600 Tél. : +33 153 616 000
Fax : +33 153 610 515
Contacts : Jean-Christophe Laplace, MQ Business Developer Manager (jean-christophe-laplace@candle.com).

http://www.candle.com
Présentation de la société
Création
Créée en 1976 par Aubrey Chernick.
Répartition des équipes pour les clients français

Candle est implanté en France depuis 1986 et compte 50 collaborateurs, dont une quinzaine de consultants.
Références
450 clients. Beaucoup de références dans la banque et dans la finance en raison de la multiplication des fusions et des acquisitions.
Historique
Candle est surtout connu dans le monde du mainframe IBM comme éditeur de la suite Omegamon, solution d’aide à l’optimisation
de la disponibilité et de la performance des systèmes. Développement de MQSeries pour Tandem. Accord international en 1998 :
Omegamon est fourni en version bridée avec MQSeries.
Architecture technique du produit

Étant le premier revendeur mondial de MQSeries, Candle s’est servi de sa forte compétence en middlewares (mise en avant comme
critère fondamental d’une intégration d’applications réussie) pour monter dans le train de l’EAI avec la suite Roma. Sortie en 1997,
Roma en est aujourd’hui à la version 3.
Candle a récemment choisi de renommer cette suite CandleNet e-business Platform, tout en précisant qu’elle repose toujours sur la
technologie Roma. Le produit est aujourd’hui essentiellement axé sur une logique d’EAI interne. L’architecture se présente sous
forme d’une business services platform : elle interconnecte des « composants » (les applications) fournissant des services.
51
Sa force principale réside dans son ouverture à un ensemble de standards du marché. Des API permettent de faire de Roma une
plate-forme d’intégration au cœur d’une architecture pilotée par des serveurs d’applications. C’est donc la nature du système d’infor-
mation qui définit la place de Roma et non l’inverse.
Le modèle EAI de Candle
B2B
Processus Roma Workflow Access
Moteur d'intégration Roma Broker
Composants
Données Application Environment Connectors
Transport MQSeries / MSMQ
Figure 16 - Modèle EAI de Candle
B2B
La localisation géographique des applications étant transparente (celles-ci sont déclarées dans un annuaire), il est possible de se
connecter à des applications distantes chez des partenaires.
Roma F/S Access assure une connexion au réseau financier Swift.
Processus : Roma Workflow Access

Avec Roma Broker, définition de BSP (Business Services Processes) pour suivre un ensemble de fonctions. Roma est capable de
s’interfacer avec les moteurs de workflow MQWorkflow d’IBM et Staffware.
Moteur d’intégration : Roma Broker

Roma Broker gère le routage et la transformation. La solution peut être interfacée ou gérée par d’autres message brokers du marché :
ceux de Neon, de Mercator et de Cognitive Systems.
L’annuaire Roma Directory, référentiel LDAP du système, gère les informations sur la composition du système : services métier,
52 composants métier, clients, autobridges (passerelles entre MQ hétérogènes) et BSP. Une application est décrite par un nom logique ;
son emplacement géographique importe peu. Le référentiel global peut être répliqué en local. Toute l’interface graphique d’adminis-
tration et de configuration est développée en Java pour des raisons de portabilité.
L’administration du système est réalisée par CandleNet Application Manager, qui s’occupe de la reprise des transactions, de la
montée en charge, du suivi des performances et de la remontée des erreurs. L’ensemble est accessible depuis une interface
graphique.
CandleNet Broker Access assure la connectivité au message broker MQIntegrator, de Neon et IBM, et à celui de Mercator.
Données : Application Environment Connectors

Les connecteurs applicatifs sont surtout tournés vers le middleware, les mainframes et les progiciels (SAP) :
• SGBD – ODBC, Lotus Notes ;
• ERP – SAP (récupération des iDoc), PeopleSoft ;
• Mainframes – Cobol, CICS, IMS ;

• MOM – MQSeries, MSMQ ;
• ORB – Corba (développement objet et transformation de l’objet en flux de messages MQSeries), Java ;
• Protocoles Internet – XML.
Le SDK Universal Connector permet d’attaquer les API natives des bases de données. Candle travaille activement à l’enrichissement
de son offre de connecteurs « prépackagés ».
Transport : MSMQ et MQSeries

Roma supporte MQSeries et MSMQ et fournit également l’autobridge, une passerelle entre les deux MQ.
53
Synthèse
Montée en charge Définition d’une pondération (cost) sur chacun des BSP pour déterminer sur lequel on équi-
libre. Définition des nombres d’instances minimal et maximal de Business Processes.
Récupération d’alertes de produits de tuning pour agir sur la disponibilité des services en
dynamique, sinon nombre d’instances fixes. Distribution des files d’attente et des connec-
teurs applicatifs.
Transactions et moniteurs transactionnels Pas de gestion de transactions longues, mais sait prévenir par envoi de messages qu’une
transaction n’a pu arriver à terme. En effet, certaines actions ne peuvent subir de rollback
étant donné la nature asynchrone des échanges.
Roma est néanmoins compatible avec les moniteurs transactionnels XA (CICS, Tuxedo) : ce
qui est déjà coordonné le reste, on se repose sur les architectures existantes.
Administration CandleNet Application Manager fournit à l’utilisateur une interface graphique centralisant
tous les services d’administration souhaitables : audit, surveillance et remontée des erreurs.
Candlelight est un freeware qui présente les temps de traitement et de transport des mes-
sages, graphiquement et sous forme de fichiers de tableur.
Tolérance aux pannes La tolérance aux pannes est assurée par les capacités de réplication en local du référentiel
Roma Directory.
Sécurité Fourniture d’une offre de sécurisation MQSeries. Cryptage, authentification, certification

128 bits. InLine Service permet de définir les niveaux de sécurisation sur les BSP.
XML Le Metadata Repository permet de définir les conversions des messages en XML et vice
versa. C’est un data mapper qui définit les formats de conversion. Un parseur intégré valide
les documents au regard de DTD. Cette composante de Roma ne nécessite pas de passer par
un message broker.
Ouverture À noter : la possibilité de s’interfacer avec d’autres message brokers, voire à utiliser comme
message broker unique une technologie non-Candle (MQIntegrator, Neon ou Mercator).
Accès aux API disponibles en C, C++, Java, ActiveX. Roma peut être utilisé comme un com-
posant adressable depuis Visual Basic ou Powerbuilder. Référentiel reposant sur une struc-
ture LDAP. Ouverture aux agents SNMP.
Portabilité Disponible sous MVS, Windows NT et 2000, HP, SUN, AIX, AS/400. L’interface graphique de
configuration et d’administration est développée en Java, donc portable.
Évolutivité Une nouvelle application est facile à référencer dans Roma (localisation physique, type de
54 MOM utilisé, procédures d’audit, de suivi, etc.). Développement de connecteurs par le client
ou par une société tierce.
Productivité de développement Toute la configuration s’opère via une interface graphique. Toute application peut se « plug-
ger » sur les API Roma qui permettent d’envoyer et de recevoir des messages. Le toolkit pro-
cure une économie de 70 % du temps de développement des connecteurs.
Déploiement Référentiel centralisé répliqué automatiquement et connecteurs applicatifs distribués sur les
machines distantes.
Les files d’attente sont réparties. On peut demander au produit de générer automatiquement
des files ou de s’appuyer sur la configuration de files déjà existantes, mais on ne prend pas
en charge la supervision.
Formation La connaissance de MQSeries est un bon prérequis pour démarrer facilement avec le pro-
duit. On peut alors prendre le produit en main en moins de 2 jours.
Un cursus de formation est mis en place en France. L’intégralité du cursus dure 15 jours :
développement, installation, workflow, XML, Object Access, architecture et conception des
applications MQ.
Constellar
1400 Bridge Parkway, Suite 201 Tour Ariane – 33e étage

Redwood Shores, California 94065-1046 5, place de la Pyramide
Tél. : +1 650 631 4800 92088 Paris-la Défense
Tél. : +33 155 681 057
Contact : Sophanie Din, directeur des opérations (sdin@fr.constellar.com).

http://www.constellar.com
Création
Créée en 1995 par Brian Donnelly.

La filiale française s’est installée en janvier 1999. Elle compte aujourd’hui 3 collaborateurs : un collaborateur s’occupe de la partie
commerciale, un autre de l’avant-vente technique et un troisième du conseil. Le support technique est disponible 24 heures sur 24
et 7 jours sur 7.
Références
Plus de 100 clients aux États-Unis et en Europe, dont environ 80 en production.
Présentation du produit
Constellar Hub 3.5e est le produit actuellement distribué en France. Constellar Hub répond à des besoins d’EAI spécifiques, liés à
l’intégration performante de gros volumes de données. Cette intégration est fondée sur une communication many-to-many des
sources de données et sur une planification fine des tâches. L’accent est mis sur la robustesse du produit, sur ses aptitudes à la
montée en charge (6 Go par heure) et sur sa flexibilité, et moins sur une gestion des processus métier. En cela, l’incorporation d’un
moteur de workflow n’est pas à l’ordre du jour, même si l’outil est capable de modéliser des règles métier assez complexes.
Cela se vérifie par une percée dans le domaine de la banque d’affaires (dont les règles de gestion sont par essence très compliquées)
et chez les opérateurs de télécommunications (pour des questions de volume). Les start-up qui ont des contraintes fortes de rapidité
de mise en œuvre et de robustesse trouveront également en Constellar Hub un produit répondant à leur attente. 55
Constellar Hub incorpore un volet décisionnel – Warehouse Builder – qui permet de définir et de reprendre des schémas de data
warehouses et de data marts, avec agrégation complète ou partielle des sources de données, et de les poster vers différents
systèmes décisionnels, dont la liste est fournie ci-dessous, dans la description technique du produit.
Le modèle EAI de Constellar
B2B Transformation Manager
Processus
Moteur d'intégration Transformation Manager
Composants Packages Oracle
Données Metadata Manager + Adapters
Transport
Figure 17 - Modèle EAI de Constellar
B2B : Transformation Manager

Produit natif, pas de connecteur ou de module supplémentaire. Constellar Hub se connecte à distance aux sources de données du
partenaire en accès natif, par l’utilisation de sa console Transformation Manager (décrite dans la section « Moteur d’intégration »).
La connectivité XML sur HTTP permet de proposer un couplage faible sur des systèmes distants.
Processus
Pas de workflow (voir la section « Présentation du produit »).
Moteur d’intégration : Transformation Manager

Transformation Manager permet de constituer des interfaces (couplage logique n-n entre données sources et cibles), les traitements
de transformation des données et les processus de remontée des erreurs de chacune des phases de l’intégration (le cycle de
transformation en définit cinq : grab (collecte), extract, transform, export et send).
Les règles de transformation et les règles de gestion sont stockées dans un référentiel Oracle 7.3.4, 8 ou 8i.
Les données sont systématiquement remontées en base de données avant transformation et, si besoin, agrégées. Les sources
hétérogènes peuvent ainsi être jointes (par jointure relationnelle) et il devient possible, en s’appuyant sur les capacités natives
56
d’Oracle, de traiter de gros volumes de données.
Transformation Manager est une interface graphique qui facilite l’administration grâce au suivi :
• des erreurs (avec conseil de correction et consultation des valeurs de cible) ;
• des tâches qui incorporent les flux de données ;
• des performances.
Grâce au produit LiveInterface, d’IntelliCorp (partenaire de Constellar), Transformation Manager centralise de façon conviviale les
erreurs issues de SAP R/3.
D’une manière générale, le produit centralise toute l’administration, y compris Parallel Server, d’Oracle, ou Warehouse Builder.
Un scheduler (outil de planification) permet ensuite de déterminer les lancements des tâches définies. Il a une partie cliente sous
Windows NT et serveur sous Unix. Le scheduling peut être partitionné sur chacune des phases.
Metadata Manager est un outil de développement qui sert à définir le référentiel de production (règles de transformation et règles
métier). En production, seul Transformation Manager est utilisé quotidiennement.
Composants : packages Oracle

Interfaçage avec des programmes PL/SQL ou Pro*C pour réutiliser des règles métier déjà existantes ou ajouter de nouvelles intelli-
gences applicatives.
Données et applications : Metadata Manager + Adapters

Metadata Manager permet de consulter les catalogues de bases de données ou les repositories des progiciels. Les connecteurs
existants sont non intrusifs. Ils permettent la lecture dynamique des référentiels des progiciels et des bases de données concernées.
Il existe des connecteurs source (extraction de données) et des connecteurs target (cibles).
• SGBD – Interrogation native pour Oracle, via ODBC pour Sybase, Informix et Microsoft.
• ERP – PeopleSoft, Siebel, SAP, Oracle Applications. Pour SAP, une solution développée conjointement par Constellar et
Intellicorp (partenaires technologiques de SAP) sur leur produit LiveInterface gère l’intégration technique et fonctionnelle, avec
gestion des exceptions (remontée des erreurs vers le hub Constellar).
• Mainframes – Reprise des description de données des fichiers « descendus » des mainframes. Capacité d’invoquer des
services distants.
• MOM – MQSeries est interfacé avec les modules Extract et Export. La file MQ est traitée comme un fichier.
• Protocoles Internet – HTTP, FTP, XML.
• Warehouse Builder – Une forme particulière de connecteur Target. Les formats supportés sont les bases relationnelles, les
univers BO, OLAP (Express, Essbase, Powerplay) et ROLAP (Microstrategy).
Transport
Pas de middleware propriétaire : le résultat est envoyé directement à la cible par le protocole natif de celle-ci. D’autre part, un shell
FTP permet de faire communiquer des plates-formes hétérogènes.
57
Synthèse
Montée en charge S’appuie sur les mécanismes de load balancing d’Oracle (parallélisation des trai-
tements, partitionnement), administrables depuis la console.
Transactions et moniteurs transactionnels Pas encore gérés.
Administration Découpage des processus en phases avec gestion des erreurs pour chacune des
phases ; identification des problèmes de performances avec possibilité d’optimi-
sation phase par phase. Toute opération est suivie de bout en bout, de l’acquisi-
tion des données jusqu’à leur livraison. Toutes les erreurs sont centralisées sur la
même console graphique.
Tolérance aux pannes S’appuie sur le hot standby d’Oracle et sur Oracle Parallel Server, mais configu-
rable depuis le Transformation Manager.
Sécurité Pas de sécurisation spécifique du fait de l’emploi des protocoles natifs.
XML Connecteur XML sur HTTP.
Ouverture Le produit se comporte comme une application sur une base Oracle et non comme
un système complet venant fédérer le système d’information. La question de l’ou-
verture du système ne se pose donc pas : un moteur Oracle est ouvert à d’autres
développements.
Portabilité Constellar Hub est disponible sous Unix (Sequent, Digital Tru64, Linux, HP-UX,
AIX, Solaris) et sous Windows NT.
Productivité de développement Démarche hiérarchique depuis la console graphique : déclaration des interfaces,
des transactions, du mapping des sources de données, des flux de sortie, puis
enfin du mapping au niveau attribut. Il est possible de définir des règles métier à
tous les niveaux.
Des assistants (wizards) permettent d’importer les métadictionnaires. Le
GetMetadata Wizard reprend les métadonnées issues de sources Cobol, SGBDR,
case Tools ou iDoc. Il existe des assistants de production d’états. Ces états peu-
vent être enrichis par l’exécution de nouvelles requêtes PL/SQL.
Déploiement Le hub doit être sur la même machine que la base Oracle. Si plusieurs sites dis-
tants sont interconnectés, le hub doit être installé sur chacun des sites. Les règles
de gestion communes à toutes les configurations sont répliquées sur chaque réfé-
58
rentiel distant. Le développement reste centralisé sur une seule plate-forme.
Formation Cursus de 3 jours sur Constellar Hub. Prérequis : Oracle et PL/SQL. La formation
peut avoir lieu sur site.
Level 8
8000 Regency Parkway Centre d’affaires Paris-Bourse

Cary, NC 27511 115, rue Réaumur
Tél. : +1 919 380 5000 75002 Paris
Tél. : +33 155 343 740
Fax : +33 142 332 112
Contact : Laurent Lévy, directeur.

http://www.level8.com
Création
Créée en 1994 par Samuel Somech, architecte de MQSeries, qui a également participé à la conception de MSMQ, et Arik Kilman. En
Bourse depuis 1996.

15 consultants (support technique, développement, formation, études préalables).
Références
Merril Lynch, France Telecom, Michelin, SNCF, AMDOCS…
Historique
Level 8 est créé en 1994 et ses activités couvrent alors principalement la prestation de services autour de MQSeries d’IBM. Début
1998, l’entreprise opère un virage important, avec un plan stratégique sur deux ans concrétisé en quatre phases :
• l’achat de Momentum Software et de son produit de MOM XIPC, brique de base du produit de middleware Falcon MQ ; la vente
à Microsoft d’une partie de la technologie Falcon MQ, à partir de laquelle Microsoft a développé MSMQ, intégrée à
Windows 2000 ;
• le développement de Geneva, un produit destiné à fournir des solutions d’EAI ;
• l’acquisition fin 1999 de Seers Technologies, spécialiste du développement d’applications distribuées, et de Template Software,
disposant de la technologie complémentaire : modélisation métier et moteur de workflow, composantes nécessaires à une offre 59
mature et ouverte sur l’e-business.
Ces acquisitions ont permis à Level 8 d’utiliser l’implantation européenne de Seers et de Template Software pour pénétrer le marché
européen.

L’offre de Level 8 s’appelle Geneva Integration Suite. La solution comprend un message broker, Geneva Integration Broker, et un
MOM, Geneva MQ. Elle s’articule autour des modules Geneva Enterprise Integrator pour l’intégration des processus métier et Geneva
Business Process Automator pour leur automatisation. Geneva Integration Suite est constituée de composants techniques,
d’éditeurs graphiques, et d’outils de développement qui permettent le déploiement d’architectures entièrement distribuées, dédiées
à la mise en place de solution d’intégration et de workflow.
La modélisation métier des processus d’entreprise se concrétise techniquement par leur implémentation sous forme de composants
COM, Corba ou EJB. Enfin, la plate-forme dispose d’un outil pour construire un référentiel client qui sera utilisé par les applications
CRM.
Le modèle EAI de Level 8
B2B
Processus Business Process Automator
Moteur d'intégration Integration Broker
Composants Enterprise Integrator
Données Data Manager
Transport Geneva MQ
Figure 18 - Modèle EAI de Level 8
Processus : Business Process Automator

Geneva Business Process Automator fournit un éditeur graphique pour la définition des processus et un moteur pour leur automa-
tisation. L’éditeur peut être adapté aux besoins des experts métier. Des bibliothèques d’objets permettent de modéliser les activités,
les étapes et les flux. Des processus automatisés ou manuels, internes ou externes peuvent être utilisés. La vue unifiée des
processus métiers en fait une plate-forme évolutive pour développer de nouvelles applications. Leur modélisation pour la mise en
œuvre peut être itérative.
Moteur d’intégration : Integration Broker

Les fonctions d’intégration sont assurées par un message broker, Geneva Integration Broker. Il offre une vue objet des données
provenant de toutes les sources de données, et utilise une technologie distribuée pour l’intégration d’applications, de flux d’infor-
mations, et de données dans un modèle dynamique (structure et état). Il possède un éditeur et un référentiel pour stocker les
transformations à effectuer sur les messages. Ces transformations sont conservées sous forme de métadonnées XML.
Configuration et paramétrage s’opèrent par la console Geneva Entreprise Integrator 2.0, portail des ressources en cours d’utilisation.
Geneva Enterprise Integrator permet de construire un modèle objet opérationnel qui facilite l’intégration des applications avec les
sources de données applicatives. Il permet de construire des passerelles entre les applications web et les autres éléments du
60 système d’information via des composants métier Corba, DCOM et EJB. Le modèle objet opérationnel fournit aux applications un
accès synchrone aux sources de données à travers des proxies et le Data Manager (voir la section « Données »), et accède
directement aux applications. Il est conservé en mémoire résidente.
PMC (Process Monitor Component) est un outil de supervision qui permet la distribution dynamique, et la supervision de l’exécution
d’un processus métier.
Composants : Enterprise Integrator

Geneva Enterprise Integrator 2.0 fournit une passerelle entre les applications web et les autres éléments du système d’information
via des composants métier Corba, DCOM et EJB. Cette couche intermédiaire apporte une touche synchrone au modèle par système
de requêtes-réponses instantanées entre les applications.
Geneva AppBuilder est une suite de développement d’applications objet. Il stocke et gère les définitions des règles et le paramétrage
des transformations de données. Il fournit des fonctions avancées d’analyse.
Données : Data Manager

Data Manager encapsule une mécanique qui permet de composer l’objet métier en temps réel. Le modèle objet relationnel, distri-
buable sur n serveurs, est conservé en mémoire. Data Manager procure un ensemble de proxies qui décrivent le modèle objet aux
outils de développement ou à des utilisateurs finaux. Il permet de superposer des objets métier aux données existantes. Il donne
également la possibilité de développer soi-même des connecteurs en « mappant » l’API de la source ou en reprenant le modèle de
la base de données. Il est en effet possible de consulter une base de données pour obtenir le schéma de la base.
• SGBD – DB2, Sybase, Oracle, ODBC.
• ERP – PeopleSoft, SAP R/3, Oracle Financials.
• Mainframes – CICS, IMS TM, AS/400, MQSeries.
• Protocoles Internet – LDAP, XML, HTTP(S), FTP, SMTP, POP3.
• ORB – DCOM, Corba (Iona).
• Moniteurs transactionnels – Tuxedo.
• Autres – fichiers plats.
Transport : Geneva Message Queuing

Geneva Message Queuing assure le transport de données en mode sécurisé, asynchrone, multi-plateforme et compatible MSMQ. Il
existe aussi une passerelle MQSeries/Geneva MQ. Geneva Message Queuing fournit à la gestion des messages une interopérabilité
sans rupture avec les plates-formes supportées.
61
Synthèse
Montée en charge La montée en charge est assurée par les possibilités des outils Microsoft et le
support d’une architecture distribuée. Geneva Integration Broker est
« multithreadé » et peut traiter simultanément de nombreux flux. Le load
balancing combine l’utilisation du repository central avec les règles définies
sur le message broker.
Transactions et moniteurs transactionnels Avec Geneva IB Transaction Flow, il est possible de supporter les transactions
pour préserver l’intégrité des données lors d’un processus en plusieurs étapes
(des commits et rollbacks globaux sont effectués sur les messages).
Administration Geneva MQ Web Monitor et Geneva Explorer sont des outils de surveillance du
middleware, respectivement à travers un navigateur Web et à travers la
console de gestion (MMC) de Microsoft. Geneva Explorer permet de
configurer les adaptateurs, les transformations et le routage.
Tolérance aux pannes Les outils Microsoft fournissent les fonctionnalités de load balancing et de
dynamic clustering (Microsoft Transaction Server, Microsoft Cluster Server et
SQL Server).
Sécurité RSA et DES.
XML L’utilisation d’XML est possible à tous les niveaux : Geneva Integration Broker
supporte XML en natif et les composants du système d’EAI peuvent dialoguer
entre eux en XML. C’est une facilité très appréciable et qui offre une grande
souplesse.
Ouverture Il est possible de communiquer avec des plates-formes non Windows

suivantes : Solaris (sparc et intel), HP-UX, AIX, Unix, Linux, VMS (vax et
alpha), OS400 et VMS.
L’approche composant permet d’étendre les fonctionnalités du message
broker avec des composants COM.
Geneva supporte également SNMP pour pouvoir s’intégrer dans des outils tels
que Tivoli, Unicenter ou HP OpenView. Portabilité Windows NT et 2000.
Geneva MQ et un certain nombre d’outils liés à l’intégration au niveau métier
62 sont également disponibles pour Unix (Enterprise Integrator, Business
Process Automator).
Productivité de développement L’approche objet et le support des outils de développement Microsoft (Visual
Studio et COM) font de Geneva Integration Suite une plate-forme efficace pour
le développement.
Déploiement Le modèle est distribuable.
Formation Non communiqué.

Mercator Software
Mercator Software Mercator Software France

45 Danbury Road 42, avenue Montaigne
Wilton, Connecticut 06897 – USA 75008 Paris – France
Tél. : +1 203 761 8600 Tél. : +33 156 899 999
Fax : +33 156 899 989
Contact : Sylvie Lalanne, directeur commercial Europe du Sud.

http://www.mercator.com
Création
Créée en 1985 sous le nom de TSI International Software. Constatant l’impact du nom de son produit, Mercator, la société a adopté
le nom de Mercator Software au début de l’année 2000. En Bourse depuis 1997.

Créée en 1998, la filiale française compte plus de 10 collaborateurs employés en France, dont un vice-président Europe du Sud, un
directeur commercial Europe du Sud et 3 ingénieurs d’affaires, un directeur technique et 3 consultants senior.
Le support international comprend trois niveaux : le premier est en France, le deuxième est le service de hotline européen, basé à
Londres, et le troisième est le centre de recherche et développement, en Floride.
Références
Plus de 5 000 clients utilisent les produits Mercator ; parmi eux figurent Alcatel, Alstom, American Express, BASF, British Airways,
City Bank, Coca Cola, Décathlon, Deutsche Bank, Deutsche Telekom, Federal Express, Hoechst, IBM, Microsoft, Nestlé, Philips,
Prudential, Sara Lee, Société Générale, Union Gas.
Historique
Mercator s’est tourné vers le secteur de l’EAI dès 1992. En 1999, Mercator a racheté Braid, spécialiste de l’EAI pour le secteur
financier, et Novera, spécialiste de l’intégration des solutions web. Grâce à cette croissance externe et à un fort développement
interne, Mercator est aujourd’hui un des leaders de l’intégration A2A, B2B et C2B (respectivement application-to-application, 63
business-to-business et consumer-to-business).
Présentation du produit
La gamme comprend trois solutions : Mercator Commerce Broker (B2B), Mercator Enterprise Broker (EAI) et Mercator Web Broker
(B2C), qui répondent chacun à des besoins spécifiques. L’architecture de transformation repose néanmoins sur une plate-forme et
des composants uniques.
Les couches processus et moteur d’intégration sont étroitement liées. Ainsi, System Editor, qui sert à modéliser les processus, gère
également la distribution des messages.
Le modèle EAI de Mercator
B2B Mercator Commerce Broker
Processus Integration Flow Designer
Moteur d'intégration Mercator Integration Server
Composants Mercator Web Broker
Données Mercator Type Designer + Adapters
Transport
Figure 19 - Modèle EAI de Mercator
B2B : Mercator Commerce Broker

Mercator Commerce Broker représente l’offre complète : A2A, B2B et C2B. Pour le A2A, Mercator Enterprise Broker répond aux
besoins d’intégration d’applications d’entreprise. Pour le B2B, Mercator Commerce Manager inclut la gestion des partenaires et la
configuration des communications, la gestion des messages en termes de spécification des transactions, de coordination des
processus et de spécification fonctionnelle des confirmations.
La solution C2B, Mercator Web Broker, permet d’exposer au Web les processus métier sous forme de composants servlets et EJB
représentant les données relatives à un document (soumission d’un ordre de commande) ou à un service (disponibilité de produit,
statut d’une commande), selon une communication synchrone ou asynchrone.
La sécurité est assurée par certificats digitaux X.509, le cryptage SSL et le contrôle d’accès à travers un annuaire LDAP standard.
Processus : Integration Flow Designer

L’Integration Flow Designer est l’outil graphique de conception des flux et permet de gérer la configuration via la distribution des
composants sur les plates-formes adéquates.
Le Mercator Event Server, disponible sur une multitude de plates-formes, sert à gérer les flux et prend en compte le déclenchement
d’événements. Il dispose de fonctionnalités telles que l’attente et la synchronisation d’événements et que la validation des flux en
64 termes de cohérence des sources et des destinations définies. Mercator Event Server fait appel au moteur d’intégration. Une console
de monitoring permet le suivi des processus. Une intégration avec des outils d’entreprise est possible.
Moteur d’intégration : Mercator Integration Server

Le moteur d’intégration gère l’exécution des processus à travers ses composants (Map). Les outils de configuration du moteur
d’intégration comprennent un environnement de développement, Author System. Le Mercator Design Studio est l’environnement
graphique de conception des processus (Integration Flow Designer), de ses composants (Map Designer) et données (Type
Designer). Le Map Designer gère la définition des règles de transformation et de routage. Son fonctionnement repose sur le principe
du many-to-many et any-to-any en une seule étape.
Composants : Mercator Web Broker

Avec le rachat de Novera, Mercator a enrichi sa gamme avec les produits Mercator Web Broker et Web Integrator, qui sont désormais
intégrés à l’architecture unique Mercator. Ils permettent de concevoir des composants web réutilisables qui répondent aux normes
EJB et Corba, puis de les publier et de les enregistrer du côté serveur d’applications Web.
Données : Type Designer + Adapters

Type Designer est l’outil graphique de définition des métadonnées. À travers les adaptateurs, le Type Designer permet de se
connecter aux sources de données et d’importer les métadonnées. Le Type Designer sait découvrir les catalogues des bases de
données relationnelles du marché. L’import des métadonnées est possible pour :
• SGBD – Oracle, SQL Server, DB2, Sybase, ODBC.
• ERP – SAP (ALE, BAPI, BDC, DMI, EDI), PeopleSoft (Message Agent API, Open Query Interface, EDI), Siebel.
• MOM – BEA Tuxedo, IBM MQSeries, MSMQ, Oracle Advanced Queue et TIB/Rendezvous.
• Protocoles Internet – HTTP, HTTPS, LDAP, FTP, SMTP, MAPI.
• Autres – copybooks Cobol.
Les données sources sont récupérées, transformées et acheminées vers les destinataires en mode fil de l’eau ou batch. Les
adaptateurs prennent en charge la capture des erreurs, la journalisation et le reporting. Le développement d’adaptateurs est
possible.
Transport
Des MOM du marché sont utilisés pour transporter les données.
65
Synthèse
Montée en charge La montée en charge s’opère par la multiplication des serveurs d’intégration.
Transactions et moniteurs transactionnels BEA Tuxedo peut invoquer Tuxedo Transformation Server (inclus dans
Mercator Enterprise Development Kit), qui fait appel au moteur d’intégration.
Mercator Integration Server peut appeler un service Tuxedo à travers son
adaptateur Tuxedo.
Sur IBM OS/390, une transaction CICS peut appeler le moteur d’intégration
Mercator.
Administration Des outils de monitoring sont fournis, et l’intégration avec les outils d’entre-
prise est possible. L’absence d’une base de données système garantit l’agilité
(indépendance, portabilité, évolutivité) et minimise le besoin de paramétrage
et de tuning de la solution.
Tolérance aux pannes La multiplication des serveurs d’intégration permet de pallier la défection de
l’un d’eux le cas échéant.
Sécurité Les échanges B2B sont sécurisés selon les mécanismes traditionnels (X.509,
SSL, ACL).
XML XML est reconnu et supporté pour l’échange B2B et toutes les transformations
d’un format XML en un format non-XML (et vice versa) sont possibles. Les
standards reconnus sont X.12, Edifact, HL7, Swift et les BOD, de l’OAG.
Ouverture L’intégration avec IBM Tivoli, BMC Patrol et HP OpenView est supportée. La
couche transport est dédiée à de nombreux middlewares du marché :
MQSeries, BEA MessageQ et Tuxedo, MSMQ, Candle Roma, etc.
Portabilité Le client de conception, de développement et de configuration tourne sur les

plates-formes Microsoft. Le serveur d’intégration est disponible sur 22 plates-
formes (Windows NT, AIX, Solaris, HP-UX, Compaq, mainframes IBM, etc.).
Productivité de développement Mercator utilise un langage de paramétrage comparable à un tableur et ne

génère pas de code.
Déploiement L’outil graphique Information Flow Designer permet de gérer le déploiement et

la distribution à partir d’une interface centralisée.
66 Formation Le support de Mercator aux clients inclut des prestations de conseil et de
formation, d’assistance technique au projet d’intégration et une hotline
régionale.
Neon (New Era of Networks)
6550 Greenwood Plaza Blvd Tour Ariane

Englewood, CO 80111 – USA 5, place de la Pyramide
Tél. : +1 800 815 6366 92088 Paris-la Défense
Tél. : +33 1 55 68 10 95
Fax : +33 1 55 68 12 38
Contact : Denis Pagniez, responsable commercial (denis.pagniez@neonsoft.com).

http://www.neonsoft.com
Créée par Rick Adam (Goldman Sachs) en 1993 ; 1 000 collaborateurs, dont 250 en recherche et développement.

Les bureaux français sont implantés depuis 1999. Ils couvrent l’Europe de l’Ouest et du Sud. Les prévisions sont de 20 collabora-
teurs fin 2000. Le support technique 24 heures sur 24 et 7 jours sur 7 est réparti sur 3 centres mondiaux.
Références
Plus de 2 500 références et une forte politique de partenariat : SAP, PeopleSoft, Microsoft, IBM, Oracle, Sun Microsystems,
BroadVision, Commerce One…

e-Biz Integrator a demandé 2 à 3 ans de mise en œuvre. Neon a déposé trois algorithmes sur des technologies achetées depuis par
IBM, BEA et Sun Microsystems.
e-Biz Integrator propose des solutions départementales (banque sur Internet) ou d’entreprise sur toutes plates-formes.
L’offre d’EAI et d’e-business de Neon, Neon e-Biz Integrator 2.1, comprend en standard les éléments suivants :
• Neon Enterprise ProcessExecutive, le gestionnaire de processus métier ;
• NEONRules et NEONFormatter, les moteurs de règles et de formats ;
• les adaptateurs XML et EDI ; 67
• NeonWeb ;
• Neon e-ADK, le kit de développement d’adaptateurs.
e-Biz 2000 est une solution intégrée pour environnement Windows seulement. Il est très employé dans le domaine de la santé. Il est
réduit par rapport à e-Biz Integrator mais s’appuie sur les capacités de l’architecture Microsoft et adopte un mode de configuration
graphique très convivial et intégré pour l’outil de monitoring.
Le modèle EAI de Neon
B2B
Processus Enterprise Process Executive
Moteur d'intégration Neon Rules / Neon Formatter
Composants
Données Adapters
Transport EMQ, MQSeries
Figure 20 - Modèle EAI de Neon
B2B
Neon ne propose pas de plate-forme B2B à proprement parler, mais un ensemble d’adaptateurs applicatifs dédiés à des applications
B2B ou B2C : adaptateurs XML, EDI et Web fournis en standard avec e-Biz Integrator, adaptateurs Acord, HL7, Swift et Commerce
One.
Processus : Enterprise ProcessExecutive

Neon Enterprise ProcessExecutive (EPE) permet de définir, de gérer et de surveiller les processus métier qui impliquent plusieurs
applications (y compris les transactions longues). EPE permet de synchroniser des événements asynchrones issus de ces applica-
tions. Il sert également à automatiser des processus qui reposent sur les services de plusieurs applications unitaires.
EPE est intégré à e-Biz Integrator. Son utilisation est optionnelle (vis-à-vis du message broker Rules et Format sur MQSeries).
EPE possède des fonctions de timeout. Pour un emploi d’ordonnanceur, les processus de Neon (les adaptateurs d’acquisition, divers
daemons, le Rulesengine d’e-Biz Integrator…) sont souvent démarrés par un scheduler (outil de planification) du marché (ou par le
crontab sous Unix).
Moteur d’intégration : NEONRules et NEONFormatter

NEONRules et NEONFormatter sont des constituants d’e-Biz Integrator ; ils remplissent les fonctionnalités suivantes :
68
• NEONRules est le moteur de routage. Son algorithme breveté est spécialement conçu pour monter en charge avec le nombre
de règles. Les règles sont orientées « contenu » car une granularité très fine est requise. Les règles de routage sont définies
par simple glisser-déplacer dans l’interface graphique NEONRules.
• NEONFormatter est le moteur de transformation ; il effectue également l’analyse et la validation des données des messages
entrants. L’interface graphique permet la modélisation graphique de la transformation. Celle-ci suit les règles métier prédéfinies
à l’aide de l’interface homme-machine NEONFormat. Ce moteur supporte tout type de message (délimité, variable, groupes de
répétition imbriqués, etc.). NEONFormatter est l’outil qui valide les données des messages entrants, puis transforme et enrichit
leur contenu.
L’originalité de NEONFormatter tient au concept de découplage à l’intérieur même de la solution d’EAI, qui permet d’associer dynami-
quement à un seul format de message entrant plusieurs formats de messages sortants et d’éviter ainsi une définition de mapping
statique souvent laborieuse.
e-Biz Integrator incorpore la configuration et l’administration graphique. Aucun code n’est généré. Les référentiel est stocké dans
une base Oracle, Sybase, DB2 ou MS SQL Server. L’utilisation de métadonnées facilite le changement de plate-forme.
Grâce au concept de building blocks, tous les éléments constituant les règles de validation, de transformation et d’enrichissement
sont très réutilisables : une règle métier définie pour valider un format de date peut ensuite être associée à une multitude de champs
dans d’autres mappings.
NEONRules et NEONFormatter sont entièrement déclaratifs : ils ne produisent pas de code source. Les règles et les formats sont des
métadonnées sauvegardées dans un SGBDR du marché (Oracle, Sybase, DB2 ou MS SQL).
NEONTrack contrôle les messages lors de leur entrée ou de leur sortie de l’environnement e-Biz Integrator. Il suit les transactions et
traite l’archivage et la recherche des messages. Il détermine l’état transactionnel des messages : en cours, échoué ou achevé, puis
les stocke dans une base de données. Le programme contrôle la base de données et affiche de l’information sur son statut au moyen
d’une interface utilisateur graphique. L’outil Crystal Report, livré en standard, permet de générer des rapports complets.
Données : Adapters
Tous les adaptateurs Neon sont bidirectionnels et peuvent être employés d’une manière distribuée. Ils récupèrent les formats des
données des applications et les insèrent dans le référentiel NEONRules & Format. Par exemple, l’adaptateur NEONadapter for SAP
est capable de charger les formats d’iDoc et/ou BAPI SAP dans NEONRules & Format.
• SGBD – ODBC ; la prochaine version prévoit des connecteurs directs aux bases de données.
• ERP – SAP, PeopleSoft, Oracle Applications, JDEdwards.
• CRM – Siebel, BroadVision.
• SCM – i2 Technology.
• MOM – NEONadapter for Protocols permet la communication entre MOM hétérogènes ; la prochaine version permettra l’accès
direct à MSMQ, à Oracle AQ, à Tuxedo/Q, etc.
• Autres : formats et protocoles financiers – Swift, FIX, Oasys Global, Stelink, Chaps, etc.
• Autres : progiciels bancaires – Reuters, Bloomberg, Autex, Sungard Devon, Sungard Panorama, Kondor+, Summit, Infinity,
OLF, Fenics, Atlas, Royal Blue, Murex, Currency+, Cognotec, Cobra, The Box, intelliSTOR, intelliTRAC.
• Réalisés à la demande – Clarify, Trilogy, Vignette, Symbols, OpenLink Financial, Dodge, Limits, Arrow, Global Oasys, Baan,
Sun GL, MFG/PRO, BisGen, Logility, Maximo, BSCS, Ariba, Gerber WebPDM, etc.
Neon e-ADK est une boîte à outils permettant le développement rapide d’adaptateurs non fournis par Neon.
L’offre est complétée par les accélérateurs (ensemble de règles de transformations prédéfinies entre deux applications, par exemple
entre Commerce One et SAP).
69
Transport : EMQ, MQSeries
Le middleware maison est Neon EMQ, mais e-Biz Integrator s’appuie également sur MQSeries, d’IBM.
Synthèse
Montée en charge Une instance converse directement avec une application. Le load balancing est
géré par la duplication des instances sur une même machine ou sur des
machines différentes. L’algorithme de NEONRules prévoit la montée en charge
au fur et à mesure de l’accroissement du nombre de règles.
Transactions et moniteurs transactionnels Gère les transactions longues et courtes grâce à Enterprise ProcessExecutive.
Il est possible d’auditer une transaction pour visualiser. Neon se repose sur la
gestion transactionnelle de MQSeries : transaction par propagation. Il existe
Neon CICS sur mainframe IBM.
Administration Les trois applications NEONRules, NEONFormatter et NEONTrack procurent

l’ensemble des fonctionnalités d’administration souhaitées via une interface
graphique.
Tolérance aux pannes Distribution des instances.
Sécurité Le moteur de règles et de formats peut appeler une routine externe pour
décrypter un message afin de le traiter et de le recrypter en sortie.
XML Adaptateur livré en standard avec e-Biz Integrator.
Ouverture NEONRules & Format a une API. Il est possible de gérer ce moteur de façon
externe. De plus, le référentiel peut être abrité par les différentes bases de
données des grands éditeurs du marché.
Appel de routines externes en C++ pour intégrer des composants métier
externes à l’intérieur du moteur de règles et de format.
Portabilité Sun Solaris, HP-UX, AIX, MVS et Windows NT 4SP5 et 2000. Pas de code
généré, tout est dans une base de données relationnelles : solution d’impor-
tation-exportation.
Productivité de développement Pratiquement pas de code à écrire.
Déploiement NEONRules & Format peut être administré à distance. La configuration est
paramétrable en fonction des nécessités d’optimisation.
Formation Cursus sur tous les produits. Offre de formation packagée qui couvre l’inté-
gralité de l’offre produit. Formations à e-Biz 2000, à NEONTrack, formation
spécifique très courte sur les adaptateurs. Couvre 70 % des fonctionnalités du
70 produit.
STC (Software Technology Corporation)

404 East Hunington Drive 23, rue Balzac
Monrovia, CA 91016 75008 Paris
Tél. : +1 626 471 6000 Tél. : +33 1 53 53 67 79
Fax : +33 1 53 53 68 29
Contact : Stéphane Foucault (sfoucault@stc.com).

http://www.stc.com
Création
Créée en 1991 par Jim Demetriades, régulièrement amené à traiter des problématiques d’intégration et conscient du gain apporté
par une plate-forme capable de normaliser cette intégration.

Les équipes sont réparties en deux pôles : Paris (équipes commerciales et techniques : avant-vente et consultants) et Angleterre
(recherche et développement, support technique francophone).
Références
Quelque 1 600 sites en production chez des grands comptes, représentant plus de 30 000 applications intégrées.
Historique
À l’origine, le produit s’appelait DataGate et résolvait une problématique d’intégration à laquelle le secteur hospitalier américain a été
historiquement très sensible. Il y a deux ans, 80 % des clients de STC étaient des professionnels de la santé. La répartition s’est
inversée et aujourd’hui, grâce à sa nouvelle offre, e*Gate, STC réalise plus de 75 % de son chiffre d’affaires en dehors de ce secteur.
e*Gate propose une architecture entièrement distribuable qui couvre l’ensemble des couches du modèle EAI.

La solution e*Gate repose sur une architecture de type network centric (orientée réseau) gérée par un unique référentiel centralisé, 71
multi-plate-forme et propriétaire. Sa spécificité est la génération de composants métier pour les opérations portant sur les données
(dont la transformation), entièrement distribuable au travers du système d’information de l’entreprise. Cette architecture permet
notamment une granularité de distribution par composants assez fine pour gérer la montée en charge ou la tolérance aux pannes.
Parti d’un modèle EAI de première génération (le produit est l’un des plus anciens du marché), e*Gate a évolué vers une architecture
eAI avec l’adjonction récente de nouveaux modules et s’ouvre aujourd’hui à l’échange interentreprise, renommé en eBI (e-business
Integration) chez STC. Enfin, poursuivant une démarche d’intégration CRM forte, e*Gate incorpore désormais un outil de consti-
tution de référentiels clients, e*Index.
STC e*Gate 4.0 a été élu produit de l’année 2000 par EAI Journal.
(http://www.eaijournal.com/awards2000/egate.asp).
Le modèle EAI de STC e*Gate 4
B2B E*Xchange Integrator
Processus Business Process Manager
Moteur d'intégration Collaboration / Topologie
Composants Business Object Broker (BOB)
Données e*Ways / Communication Client
Transport Intelligent Queues
Figure 21 - Modèle EAI de STC e*Gate 4
B2B : e*Xchange Integrator

ASC X.12, Edifact, BizTalk et RosettaNet sont pris en compte. En ce qui concerne ce dernier, l’ensemble des processus et des
transactions des PIP (Partners Interface Processes) sont implémentés.
Toute instance de processus peut être supervisée en cours d’exécution ou après, afin de connaître son état, la durée de l’exécution
et de détecter les goulets d’étranglement (matériel), des tendances, etc.
Les profils et les protocoles des partenaires sont gérés par l’ePartner Manager. Les données sont sécurisées par l’eSecurity Manager
(cryptage S/MIME et SSL, authentification, intégrité et non-répudiation).
Processus : eBusiness Process Manager

L’eBusiness Process Manager permet aux consultants métier et aux utilisateurs finaux de réaliser la modélisation graphique des
Business Process (règles métier) des flux, puis de générer et configurer les composants sous-jacents de l’application (les e*Ways,
les BOB et les IQ) en s’affranchissant de la mise en œuvre technique du processus. Si le processus est modifié, les objets métier
sont de nouveau générés.
Ce module gère également les processus métier B2B.
72
Moteur d’intégration : Collaboration et Topologie
Une Collaboration détermine la gestion technique des processus métier définis dans l’eBusiness Process Manager. Ce module définit
la structure des échanges entre les différentes étapes d’un processus, ainsi que le schéma de transformation d’un message en un
autre. Le routage des messages, les notifications et l’invocation d’API externes sont également implémentables. Concrètement, une
Collaboration se présente comme un éditeur graphique qui génère par glisser-déposer des scripts basés sur un L4G.
L’écran de Topologie propose une vision physique du système d’information en tant que réseau composé de machines physiques et
permet de gérer la distribution et la configuration de la solution (optimisation à des fins de montée en charge).
Composants : BOB (Business Object Brokers)

Les BOB sont des services métier qui communiquent avec les files d’attente (IQ) et qui incluent un ou plusieurs traitements
(Collaboration) sur les données. Le BOB mappe techniquement la logique métier multiétapes définie au sein de l’eBusiness Process
Manager. Le BOB peut être vu comme un connecteur applicatif (e*Way) interne, destiné à ne communiquer qu’avec les files d’attente
du système d’information (les IQ).
Pour des raisons de montée en charge et de tuning du système, des BOB identiques peuvent être déployés à différents endroits
physiques du réseau afin, par exemple, de paralléliser les traitements. Ces composants métier peuvent communiquer entre eux et
les tâches peuvent donc être sérialisées. Enfin, le BOB – comme tous les autres service de la solution – dispose localement des
informations du référentiel le concernant, d’où une certaine autonomie et une tolérance aux pannes.
Adaptateurs : e*Ways
Les e*Ways (connecteurs) sont des composants de communication intelligents présentés sous forme packagée pour permettre une
connexion rapide aux applications existantes.
Les connecteurs (e*Ways) sont bidirectionnels et multithreads. Plusieurs types d’e*Ways sont proposés dans l’offre (plus de 55
e*Ways sont disponibles au moment où nous rédigeons ce texte et 100 à 150 le seront d’ici à fin 2000) ; parmi eux figurent :
• SGBD – Natifs pour Oracle et Sybase, ODBC. Ces composants sont nommés DART (Data Access Retrieval Technology). L’idée
est de représenter graphiquement la structure des tables ou des vues relationnelles sous forme d’arbres, puis de les remplir
par les enregistrements.
• ERP – SAP, PeopleSoft, Siebel, BroadVision, Vantive, Clarify.
• i*Bridge : Intelligent Bridges packagés – SAP vers PeopleSoft, BroadVision vers SAP, BV/Siebel.
• MOM – Oracle AQ, IBM MQSeries, MSMQ, Sybase IQ, Tibco.
• Protocoles Internet – TCP/IP, FTP, batch, HTTP (Apache, IIS, WebSphere), HTTPS, SMTP.
Deux modes de fonctionnement sont possibles : événementiel ou batch, mais aussi synchrone ou asynchrone en fonction de l’appli-
catif à intégrer.
STC fournit une boîte à outils, l’e*Way Extension Kit, pour développer ses propres e*Ways (L4G, C et C++ ou Java).
Le développement de connecteurs spécifiques requiert une prestation de service, qui peut être assurée par STC. La durée d’un tel
développement peut varier d’une demi-journée à 10 jours en fonction de la complexité de l’application à intégrer. STC peut ensuite
juger intéressant d’industrialiser ce développement en créant un e*Way : développement d’une interface utilisateur, rédaction d’une
documentation et mise en place d’un support technique.
73
Transport : Intelligent Queues

La non-perte et la garantie de délivrance unique des informations sont assurées par un stockage persistant dans un format crypté.
D’autres mécanismes tels que le buffering, le contrôle de routage, l’envoi d’accusés de réception et l’audit des événements métier
viennent enrichir les services fournis par ces Intelligent Queues.
74
Synthèse
Montée en charge La solution est conçue pour permettre de distribuer des composants (IQ, BOB,
e*Way) en tout point physique du réseau. Les dupliquer en vue de répartir les
traitements garantit de bonnes capacités de montée en charge du produit.
Enfin, les composants sont multiprocess et multithreads.
Transactions et moniteurs transactionnels Le produit n’incorpore pas encore de fonctionnalités transactionnelles natives.
Il est néanmoins possible de l’interfacer avec un moniteur transactionnel par
le développement d’un connecteur spécifique ou par l’exploitation d’une
e*Way existante.
Administration La solution dispose d’outils de suivi qui permettent de mettre en évidence des
goulets d’étranglement et des tendances générales d’utilisation des processus
afin d’entreprendre une politique de duplication et de distribution optimale.
e*Gate Monitor est une console de surveillance et e*Gate Alert Agent un
gestionnaire d’alertes.
Tolérance aux pannes La possibilité de dupliquer les composants lors de leur distribution permet de
faire face à des incidents tels qu’une rupture de connexion réseau. De plus, les
BOB peuvent répliquer en local la partie du référentiel concernant leur
fonctionnement (transformation et routage).
Sécurité Les IQ garantissent la diffusion unique d’un message et sa non-perte.
L’eSecurity Manager est un outil dédié à la sécurité B2B : intégrité, cryptage,
authentification de la source et non-répudiation.
XML XML est un des nombreux formats d’échange possibles entre les différentes
structures de message, pour lequel STC fournit le XML DTD Converter. Mais
aussi : librairies de structures RosettaNet et BizTalk.
Ouverture « e*Gate architecture is net-centric, not platform centric. » Les e*Ways, les
BOB et les IQ sont distribuables sur un grand nombre de plates-formes. Accès
à des API externes.
La solution e*Gate est ouverte aux agents réseau SNMP comme IBM Tivoli ou
HP OpenView.
Utilisation de C et C++, Java, Visual Basic, etc.
Portabilité Référentiel disponible pour un grand nombre de plates-formes :
Windows NT 4/2000 (Intel/Alpha), différents Unix (AIX, Solaris, HP-UX, Linux)
et OS/390.
Productivité de développement Il n’y a pas de développement au sens strict du terme. La modélisation métier
et technique ainsi que le déploiement physique s’opèrent à l’aide des interfaces
graphiques de l’eBusiness Process Manager et de Collaboration, modules 75
communicants et centralisés sur le référentiel unique.
Déploiement Facilement réalisable par le biais de l’interface graphique. La phase de
déploiement est ainsi déconnectée de la phase de conception métier et de la
phase de développement. Les IQ sont en mode publish and subscribe
dynamique.
La granularité du déploiement est très fine car on distribue des composants
métier et non des hubs.
Le nombre de files d’attente à déployer sur le système est, par exemple,
fonction de l’éloignement physique des traitements à intégrer, des volumes,
etc. C’est une des voies possibles d’optimisation des performances du
système d’information via la plate-forme d’EAI.
Formation Deux cursus de formation de 3 jours chacun : e*Gate Basic et e*Gate
Advanced. STC propose également un ensemble de cours spécifiques aux
e*Ways, à e*Xchange, à l’Alert Agent, à l’e*Index, etc.
Les équipes deviendront ensuite rapidement autonomes et seront en mesure
d’intégrer de nouvelles applications.
Tibco Software
3165 Porter Drive 70, avenue Charles-de-Gaulle

Palo Alto, CA 94304 USA 92058 Paris-la Défense
Tél. : +1 650 846 1000 Tél. : +33 158 135 560
Fax : +1 650 846 1005 Fax : +33 147 788 620
Contact : Stéphanie Gault, EuroTandem.

http://www.tibco.com
Création
Créée en 1984 par Vivek Ranadive sous le nom de Teknekron et rachetée en 1993 par Reuters. Introduite au Nasdaq en 1999 :
Reuters est actionnaire majoritaire, suivi de Cisco (6 à 7 %) et de Sun Microsystems (5 %). L’entreprise compte 800 collaborateurs.

Filiale française depuis 3 ans, 20 collaborateurs (vente et conseil) ; 38 bureaux dans le monde entier.
Références
Secteur de la finance avec plus des 300 institutions à travers le monde ; secteur de la fabrication high-tech (80 % de chip processing
– Intel, Hitachi). Position dominante dans le secteur de l’énergie en Asie, en Australie et en Europe. Concentration au Royaume-Uni
et en Europe centrale. Quelques références : Nasdaq, Ericsson, Telecom Italia, Hitachi, Pirelli, Adidas, Delta Airlines, Philips Medical
Systems, Yahoo!, EDF Trading, GDF Trading.
Historique
En 1995, le monde de la finance s’intéressait de près au multicast et au messaging. Reuters scinde Teknekron, dont le métier initial
était de construire des bus logiciels plug and play, en deux entités : Tibco (The Information Bus Company) Software, dont les métiers
seront la technologie et la vente de produits, et Tibco Finance, qui implémentera des solutions pour les marchés financiers.
Aujourd’hui, Tibco Software et Cisco, actionnaire minoritaire, travaillent à la création d’un protocole IP-multicast appelé Pragamatical
Generic Multicast (en cours de standardisation), qui utilise la technologie Tibco. Cette technologie est utilisée sur Cisco IOS 12.1
(qui utilise TIB/Rendezvous et TIB/Hawk – voir ci-dessous) et fera partie de la prochaine version de Solaris.
76
Tibco Software a acquis en juillet 2000 la société Extensibility, spécialisée dans le développement d’outils de modélisation et de
développement XML.

Longtemps tourné vers l’intégration EAI, Tibco Software fournit aujourd’hui une infrastructure d’e-business complète, avec l’appa-
rition récente de produits d’EIP et de B2B. L’offre s’adresse autant aux entreprises Brique et Mortier qu’aux dot-com. Les trois
briques de la solution sont :
• ActiveEnterprise pour l’intégration EAI ;
• ActivePortal pour l’EIP ;
• ActiveExchange pour l’intégration B2B ;
• Extensibility.
Le premier client, Goldman & Sachs, a permis de créer une place de marché financière virtuelle pour les courtiers. Tibco Software
a alors ciblé 80 % du marché financier, équipant des places de marché telles que le Nasdaq ou la City.
Le modèle EAI de Tibco
B2B TIBCO ActiveExchange
TIB/InConcert
Processus TIB/Integration Manager
Moteur d'intégration TIB/Message Broker
Composants
Données TIB/Adapters
Transport TIB/Rendez-vous
Figure 22 - Modèle EAI de Tibco
B2B : ActiveExchange
La gamme de produits ActiveExchange est conçue pour l’implémentation d’e-marketplaces horizontales (comme mySAP, de SAP) et
verticales, mais aussi pour l’échange de données entre serveurs. Elle comprend trois outils : TIB/BusinessConnect,
TIB/BusinessPartner et TIB/BusinessExpress.
TIB/BusinessConnect est le hub ; il comprend un outil graphique de définition des processus, un moteur d’automatisation de leur
exécution et un système de gestion des partenaires. TIB/BusinessPartner peut être distribué à des partenaires ne disposant pas
d’outil B2B dédié afin qu’ils puissent se connecter à une plate-forme TIB/BusinessConnect ou à toute autre plate-forme supportée
par les adaptateurs. L’outil différencie les processus publics (B2B) et les processus privés (d’entreprise). TIB/BusinessExpress
permet à tout partenaire d’accéder à TIB/BusinessConnect par l’intermédiaire d’un navigateur HTML.
Les messages sont transmis en XML et respectent les standards RosettaNet, cXML, BizTalk et OAG. Ils peuvent être délivrés avec
TIB/Rendezvous ou sur HTTP, FTP et SMTP. Une connectivité EDI est possible.
Processus : TIB/InConcert et TIB/IntegrationManager

Racheté en 1999, TIB/InConcert a 10 ans et plus de 700 références : il s’agit donc d’un produit mature. Une interface graphique
permet de modéliser et de prototyper les processus mettant en œuvre des interactions humaines, et il est possible de suivre le
déroulement des processus en temps réel.
77
Soulignons d’une part l’existence de processus métier types, fournis en standard et qui permettent de prototyper rapidement une
solution, et d’autre part la possibilité de concevoir des modèles de processus. TIB/InConcert autorise la modification dynamique d’un
processus lors de son déroulement.
TIB/IntegrationManager est un outil d’automatisation de processus. Il sert à modéliser et à coordonner des transactions courtes et
longues sur des applications intégrées par TIB/Rendezvous, Corba et EJB, et d’automatiser les processus B2B. L’écriture de lignes
de code est limitée et les temps de déploiement réduits. Des mécanismes de tolérance de panne et de load balancing sont également
proposés.
Les processus métier sont décrits au format XML. Ils peuvent ainsi être partagés entre entreprises (via un client Extensibility, par
exemple) dans des procédures type groupware pour élaborer les processus finaux qui auront l’agrément de chaque partenaire
intervenant dans l’échange.
Moteur d’intégration : TIB/MessageBroker – monitoring : TIB/Hawk

TIB/MessageBroker transforme les données fournies par TIB/Rendezvous au moyen de règles définies par une interface graphique.
TIB/MessageBroker assure un routage intelligent des messages par analyse de leur contenu. Les métadonnées peuvent être extraites
du référentiel TIB/Repository au format XML.
Il est important de noter qu’un message broker dédié est optionnel dans cette configuration. En fonction du besoin d’intégration
manifesté par le système d’information, il peut être plus judicieux de conecter un petit message broker sur les adaptateurs
applicatifs, à l’écoute des messages circulant sur le bus.
TIB/Hawk fournit une vue centralisée des applications distribuées et des systèmes à travers toute l’entreprise et permet de les
surveiller. Des traitements automatisés peuvent être planifiés (batch, agents) et la réparation d’incidents peut être effectuée à
distance.
TIB/Hawk sert également à mesurer les performances des bases de données Oracle, Sybase et SQL Server, à se connecter à des
consoles CA UniCenter et Tivoli, et fournit une passerelle SNMP.
TIB/Hawk peut surveiller l’activité des outils B2B ou d’un adaptateur et décider de lancer de nouvelles instances pour faire face à un
pic de charge. La technologie est complètement distribuée.
Données : TIB/Adapters
Les adaptateurs ne nécessitent aucun développement. Voici la liste des adaptateurs fournis par Tibco :
• SGBD – DB2, MS SQL Server, Informix, Oracle, Sybase, ODBC.
• ERP – Baan, Oracle Applications, Clarify, i2 Technology, JDEdwards, Siebel, Vantive, PeopleSoft, SAP.
• MOM – MSMQ, MQSeries, Oracle AQ.
• ORB – COM, Corba.
• B2B – Ariba, Calico, Selectica (gestion de la configuration pour e-marketPlaces).
• EDI – adaptateurs GEIS.
• Protocoles Internet – HTTP, HTTPS, FTP, Secure FTP, SMTP et S/MIME.
• Adaptateurs verticaux – Plus de 50 adaptateurs pour le domaine bancaire ; des adaptateurs pour le monde high-tech, l’énergie
et les télécommunications.
• Autres – Fax, GSM.
TIB/Adapter SDK permet à l’entreprise de développer ses propres adaptateurs. Tibco Software peut effectuer des prestations de
développement ou solliciter des partenaires pour des adaptateurs spécifiques.
Transport : TIB/Rendezvous
TIB/Rendezvous est en version 6 et a derrière lui 15 ans d’expérience. TIB/Rendezvous est un MOM supportant des modèles de
communication multiples tels que le publish and subscribe, le request-reply ou le broadcast request-reply, ainsi que des niveaux de
78 qualité de service différents comme le broadcast fiable (reliable broadcast), le multicast fiable (reliable multicast), la délivrance de
messages certifiés (guaranteed messaging) et le messaging transactionnel.
TIB/Rendezvous utilise une technologie brevetée TIB d’adressage par sujet. Un message est publié une seule fois sur le réseau et
comprend un « sujet » dans son en-tête (subject based addressing). Les applications abonnées à ce sujet reçoivent automati-
quement le message. Cette technologie permet de réduire le trafic réseau, rend la localisation des applications entièrement transpa-
rente et permet un niveau de modularisation du système d’information extrêmemnt élevé.
Synthèse
Montée en charge TIB/IntegrationManager, TIB/Hawk et TIB/Rendezvous (API) se multiplient

pour gérer cet aspect. L’architecture est totalement distribuable.
Transactions et moniteurs transactionnels TIB/IntegrationManager permet de définir des transactions courtes et longues,
interapplicatives et interpartenaires. TIB/Rendezvous TX permet d’exécuter de
multiples opérations comme une seule unité d’œuvre.
Administration La plate-forme est intégralement administrable par des outils graphiques, qui
surveillent à la fois l’exécution des processus et des transactions, les perfor-
mances du système et l’activité réseau. La plate-forme d’administration de
TIB/Rendezvous peut être fondée sur un formulaire HTML.
Tolérance aux pannes TIB/IntegrationManager, TIB/Hawk et TIB/Rendezvous (API) permettent un

redémarrage immédiat suite à des erreurs inattendues, ainsi que la distribution
de certaines tâches avec des micro-agents pour pallier d’éventuelles interrup-
tions réseau.
Sécurité Signature digitale des documents par PCKS#7, transport et document

encryptés. Sécurité (encryptage 56 et 128 bits SSL), encryptage X.509,
signature digitale, non-répudiation et fonctionnalité d’audit sur les transactions.
XML Les métadonnées du référentiel peuvent être extraites en XML. Les documents
d’échange B2B en XML sur HTTP sont « parsés » à l’entrée et à la sortie pour
validation et transformés si nécessaire.
Ouverture TIB/InConcert, le moteur de workflow, s’interface facilement avec les

composants COM et Java et inclut un support LDAP pour Netscape Directory
Server 3.0 et supérieur. TIB/Hawk fournit une passerelle SNMP.
Portabilité L’interface graphique de TIB/MessageBroker et TIB/BusinessConnect sont

entièrement développés en Java. TIB/Rendezvous est disponible pour
Windows, Unix et mainframes OS/390. Hawk est disponible sous NT, Unix,
Linux et VMS.
Productivité de développement Un ensemble d’outils graphiques permet de traiter séparément la partie métier
et la partie technique sans développement.
Déploiement L’architecture de TIB/Rendezvous est totalement distribuée.

79
Formation Le cursus complet dure 11 jours et comprend un tronc commun et une spécia-
lisation.
Le tronc commun dure 7 jours et comprend les modules : introduction à Tibco
ActiveEnterprise, concepts de TIB/Rendezvous, installation et administration
de TIB/Rendezvous, concepts et configuration de TIB/MessageBroker,
administration avec TIB/Hawk.
La spécialisation dure 4 ou 5 jours et concerne soit le B2B (formation à
ActiveExchange et à ActivePortal), soit le workflow (formation à TIB/InConcert
et à TIB/IntegrationManager).
Viewlocity
Siège social Filiale française
Viewlocity Viewlocity SA
3475 Piedmont Road 16, rue Kléber
Suite 1700 92442 Issy-les-Moulineaux
Atlanta, GA 30305 Tél. : +33 145 299 426
Fax : +33 145 299 412
Contact : Denis Laurent, directeur général adjoint, directeur des partenaires et des alliances EMEA.
http://www.viewlocity.com
Création
La société suédoise Frontec, créée en 1981 par Greg Cronin, compte 300 collaborateurs de par le monde. Ses métiers sont le conseil
technique et organisationnel. Viewlocity est un spin-off du département AMT de Frontec.

La filiale française est créée en 1997. Dix collaborateurs en France (4 profils techniques, 4 commerciaux, 2 administratifs).
Références
Quelque 3 500 sites dans le monde (40 clients) dont 180 sites équipés en France.
Historique
Batteries Venture a investi 10 millions de dollar dans le département AMT pour créer et développer Viewlocity.

Le produit phare est AMTRix : il est riche de fonctionnalités en infrastructure et doté d’un message broker. Mais plus l’outil est
ouvert, moins il est ergonomique. AMTrix est donc un produit puissant mais avec une interface ingrate.
AMTrix se positionne comme intégrateur de la chaîne d’approvisionnement et de commande, pour permettre aux applications du
système d’information de s’appuyer sur de l’e-commerce.
80
Ainsi, pour Volvo, le volume des échanges est de 60 millions de messages par mois, avec, pour les messages de synchronisation
de chaînes de production, une contrainte de temps de traitement de bout en bout, intégrant l’acquis applicatif, d’un dixième de
seconde.
Le modèle EAI de Viewlocity
B2B AMTrix
Processus Business Process Manager
Moteur d'intégration Data Mapper & Monitor
Composants
Données Connecteurs
Transport
Figure 23 - Modèle EAI de Viewlocity
B2B : AMTrix
AMTrix dispose d’un référentiel complet des formats d’échanges EDI internationaux et est ouvert aux standards fondés sur XML.
SmartSync assure la synchronisation et l’automatisation des flux d’e-business sur architecture distribuée.
La sécurité s’opère de la façon suivante :
• Grâce à X.435, protocole très sécurisé (développé en Suède), orienté vers les flux EDI.
• Grâce à HTTPS et à S/MIME, orientés vers les flux web, pour transporter des flux de messages Edifact.
• Le produit garantit un acheminement confidentiel des données avec un haut niveau de sécurité et de traçabilité.
Viewlocity fait partie du groupe de travail RosettaNet et intègre ce framework, ainsi que BizTalk, à son produit AMTrix. Le connecteur
XML permet d’implémenter les PIP RosettaNet des applications de gestion logistique.
Processus : Business Process Manager

Business Process Manager sert à réaliser une modélisation graphique du workflow au sein de l’entreprise étendue et à mettre en
œuvre le paramétrage nécessaire aux traitements associés.
Moteur d’intégration : Datamapper et Monitor 81
À travers l’AGL associé à AMTrix, composé du Metadata Browser et de Datamapper, AMTrix permet de mettre en œuvre l’accès aux
données applicatives des progiciels de gestion intégrés aussi bien qu’à celles des applications héritées.
L’outil de transformation des formats, Datamapper, en assure également le contrôle. Son intégration avec le routeur AMTrix permet
d’effectuer – à l’aide du L4G semi-compilé et portable de la plate-forme AMTrix, Message Builder – des opérations de routage
complexe any-to-any s’appuyant sur l’enveloppe des échanges et sur le contenu des données échangées.
Grâce à son poste client de supervision, Monitor, AMTrix permet de tracer l’intégralité des échanges. Signalons sa capacité de mettre
en œuvre des dispositifs d’alerte et de gestion des exceptions à travers des remontées SNMP vers des consoles de supervision ou
à travers les connecteurs de messagerie, SMS et fax.
Données
Les connecteurs disponibles sont :
• SGBD – Oracle, DB2/400, Sybase, SQL Server.
• ERP – SAP (iDoc), JDEdwards (Zfiles), QAS.
• MOM – MQSeries.
• ORB – Corba.
• Protocoles Internet – HTTP (XML, Edifact), FTP, SMTP.
• Autres – X.400, X.420, X.435.
Un atelier de développement de connecteurs permet à chaque entreprise d’élaborer ses propres adaptateurs.
Synthèse
Montée en charge AMTrix permet, avec une configuration système adaptée, de résoudre une
problématique d’échange de flux dans un environnement temps réel.
Transactions et moniteurs transactionnels Grâce à sa plate-forme de développement de connecteurs (CDP), AMTrix est à
même d’intégrer les blocs d’échange manipulés par les API des moniteurs
transactionnels. Ceci n’est cependant pas une offre standard à ce jour.
Administration À travers son poste client de supervision, Monitor, AMTrix permet de

paramétrer et de tracer l’intégralité des échanges, tant en termes de communi-
cations qu’en termes de transformation et de manipulation des données.
Tolérance aux pannes AMTrix peut être exploité dans des configurations à tolérance aux pannes à
travers la mise en œuvre de clusters et d’outils de bascule automatique tels
que HP MC Service Guard.
Sécurité AMTrix sait gérer la confidentialité des données par le biais de certificats à clé
publique, dans les protocoles X.435, HTTPS (certificats à clé publique),
S/MIME.
XML Plate-forme de développement CDP : le connecteur est fondé sur XML. Tout
type de DTD est lu, ainsi que XDR. Metadata Browser sait lire ces documents
et en permet le mapping et le routage.
Ouverture Interfaçage sur des outils comme HP MC Service Guard pour la tolérance aux
82 pannes. Mise en œuvre de dispositifs d’alerte par remontée SNMP ou au
niveau métier à travers les connecteurs de messagerie, SMS et fax.
Portabilité Disponible sur les plates-formes Unix, Windows NT et AS/400. AMTrix utilise
Message Builder, langage pseudo-compilé multi-plate-forme.
Productivité de développement Utilisation de Message Builder.
Déploiement La durée de mise en œuvre d’une solution fondée sur AMTrix est de l’ordre de
quelques jours.
Formation La première base de formation dure 5 jours et permet d’acquérir les concepts
de base de l’exploitation d’AMTrix et de l’emploie de Datamapper.
Des cycles complémentaires sont prévus afin d’approfondir les fonctionnalités
de Datamapper et de Message Builder, son langage associé, aussi bien que la
mise en œuvre de services de communications complexes tels que X.400.
Vignette-OnDisplay
OnDisplay
12667 Alcosta Blvd. Suite 250 130, avenue de l’Europe

San Ramon, CA 94583 13127 Vitrolles
Tél. : +1 925 355 3200 Le Cristal Tél. : +33 442 103 515
Fax : +33 442 103 513
Contact : Eric Gavoty, general manager Europe du Sud

http://www.ondisplay.com
Vignette
901 S. Mo Pac Expy Vignette France

Bldg. 3 23, rue Balzac
Austin, TX 78746-5776 75008 Paris
Tél. : +1 512 306 4300 Tél. : +33 153 536 813
Fax : +33 153 536 853
Création
Créée en 1996 par Mark Pine (ex-directeur exécutif de Sybase) et Trung Yung (directeur technique d’OpenMarket), OnDisplay
emploie actuellement 400 collaborateurs.

Depuis décembre 1999, OnDisplay s’est installée à Vitrolles pour couvrir le marché de l’Europe du Sud. L’agence compte 5 collabo-
rateurs.
83
Références
Commerce & Distribution (Shopping.com), Voyage & Tourisme (Sabre, Travelocity). Positionnement fort en dot-com sur les
marchés nord-américains. La grosse poussée actuelle est dans le B2B pour aller sur des marchés de brick and mortar. Deux cents
références.
Historique
La partie EAI vient d’Oberon, société acquise par OnDisplay en décembre 1999.

La stratégie d’éditeur d’outils d’infrastructure logicielle pour les portails et les places de marché d’OnDisplay couvre la mise en place
de frameworks B2B en partenariat avec des groupements comme Harbinger, Ariba et Commerce One.
Le récent rachat par Vignette apporte la composante computer-to-consumer. Pour ces deux sociétés ayant 10 % de leurs clients en
commun, il était plus logique de converger que d’évoluer vers une situation de concurrence.
Leur gamme de produit s’appelle CenterStage. L’offre est composée de briques distinctes formant un tout unifié et cohérent mais
dont les modules peuvent être acquis séparément. Ces modules sont :
• eContent, le produit phare, tourné vers les portails et les places de marché. Il fonctionne par création d’agents intelligents.
• eIntegrate, qui est l’offre d’EAI. OnDisplay a intégré la technologie d’Oberon.
• eBizXchange, qui est la couche B2B de la solution.
Le modèle EAI de Vignette-OnDisplay
B2B XML Connect - eBizExchange
Processus eIntegrate
Moteur d'intégration eIntegrate
Composants
Données Building Blocks
Transport
Figure 24 - Modèle EAI de Vignette - OnDisplay
B2B : XML Connect – eBizXchange

eBizXchange XML Server effectue la transformation et l’agrégation des formats XML, EDI, texte structuré, ODBC et JDBC afin de
gérer des transactions avec d’autres sites. Des agents vont aller chercher des informations sur un site et éventuellement procéder
aux transactions et aux transformations nécessaires selon les règles établies. Ces agents sont créés avec l’Agent Builder. Trois
moteurs d’échange peuvent être utilisés :
• Agent Engine – Moteur monothread en mode batch.
• Agent Server – Moteur multithread en mode temps réel.
• XML Server – Moteur de gestion de transactions avec moteur de règles (ContentBroker).
Une version simplifiée du XML Server (sans EAI) est disponible gratuitement : XML Connect. XML Connect est un protocole qui sert
84
à connecter deux systèmes ; il est intégré dans les applications de certains clients de Vignette-On-Display qui, comme Harbinger,
l’utilisent pour connecter leurs hubs avec des traders. L’application transporte des informations dans une enveloppe XML en mode
sécurisé avec accusés de réception.
Processus
Pas de moteur de workflow à proprement parler mais une possibilité de définir des processus, via la modélisation graphique de liens
et d’enchaînements, entre les Building Blocks modélisés dans eIntegrate.
Moteur d’intégration : eIntegrate

Un outil permet de définir les Building Blocks, éléments de base qui spécifient chacun une étape dans un processus et le travail de
transformation à accomplir. Le mapping de transformation se fait graphiquement dans la console, par glisser-déposer.
Il est possible de paramétrer eIntegrate « à la volée » : traçage des événements et débogage graphique, intégration à des outils de
gestion de version, etc. Les tests sont facilités par le débogage avancé, graphique et éventuellement à distance. La compatibilité avec
SNMP assure l’intégration aux outils de gestion réseau.
Les Building Blocks sont déployés en tant que JAR, JavaBeans ou EXE (sous Windows). Avec un peu de travail, on peut aussi
déployer des archives Java CAB, des objets COM client ou serveur, ActiveX, des servlets Java, etc. L’environnement de déploiement
est CenterStage, un serveur d’applications indépendant d’OnDisplay (serveur EJB, Sun Java 2, etc.).
Données : Building Blocks

Là aussi, l’unité de base est le Building Block. Certains Building Blocks sont prépackagés :
• SGBD – JDBC, ODBC.
• ERP – SAP, JDEdwards, PeopleSoft.
• CRM – Siebel.
• MOM – MQSeries, MSMQ, Oracle AQ.
• ORB – COM, Corba (Iona Orbix), Java (bean client, bean server).
• Protocoles Internet – HTTP, FTP.
• Autres – Gestion de projet (Primavera Project Planner, MS Project), B2B (Extricity), Lotus Notes, Microsoft Office.
OnDisplay, ou un intégrateur qualifié sur le produit eIntegrate, peut effectuer des prestations de services pour le développement de
Building Blocks.
Pour la création d’agents, l’Agent Builder permet de spécifier les données d’une base de données, d’un fichier XML, d’un format EDI
ou d’un fichier HTML (en ligne ou non). Les transformations se font visuellement, par glisser-déposer de la source vers la
destination. Ces agents sont la base de la plupart des applications de la ligne CenterStage. Le Building Block paramétré est ensuite
récupéré dans eIntegrate, prêt à être inséré à une chaîne de processus. Les agents XML sont « mappés » sur des DTD.
Synthèse
Montée en charge Agent Server gère la montée en charge. Le système est ouvert pour dédier ce
volet aux applications du système d’information.
Transactions et moniteurs transactionnels Définition de règles d’activation et de désactivation. Mécanismes de routage
conditionnels.
Administration Définition visuelle des traitements à effectuer en cas d’erreur.
Génération de fichiers et génération d’un événement lançant un nouveau
processus.
Actions de substitution.
Suivi pas à pas de l’exécution d’un événement en mode débogage.
Tolérance aux pannes La tolérance aux pannes s’appuie sur les mécanismes propres aux plates-
formes de déploiement sur lesquelles la solution s’exécute.
Sécurité Prise en compte des mécanismes de sécurité standard (cryptographie SSL,
certificats, non-répudiation).
XML eBizXchange, XML Connect et Agent Builder utilisent beaucoup la technologie 85
XML.
Ouverture Grande ouverture de la solution avec des possibilités de déploiements dans
des environnements très variés et au choix de l’utilisateur.
Portabilité Le système de développement des agents tourne sous NT, mais le système de
production existe pour NT et pour Unix AIX, HP-UX et Solaris. Il existe une
version Linux d’eIntegrate.
Productivité de développement Grâce aux interfaces graphiques, il est très facile de recréer un agent en cas de
modification d’une source de données. Le système de développement tourne
sous NT.
Déploiement L’Agent Server permet de configurer les agents (JAR). Architecture distribuée.
Mise en mémoire et précompilation des agents pour optimiser les perfor-
mances d’exécution du JavaScript.
Formation eContent et eBizXchange : 3 jours
eIntegrate : 2 à 3 jours + 1 journée de conseil lié au contexte réel du client.
webMethods
3930 Pender Drive 75008 Paris

Fairfax, VA 22030 54, avenue Hoche Tél. : +33 156 605 859
Contact : Rémy Dubois, directeur France.

http://www.webmethods.com
Nous avions prévu de présenter ActiveWorks, la solution d’EAI d’Active Software. Le rachat, en juin 2000, d’ActiveSoftware par
webMethods apporte une solution B2B reconnue et crée une plate-forme complète couvrant toutes les couches du modèle EAI sous
l’« enseigne » unique de webMethods.
Présentation
Création
Créée en 1996. Implantation internationale. Plus de 750 collaborateurs. Une équipe de Recherche et Développement de 220 collabo-
rateurs.

Une dizaine de collaborateurs en France, répartis entre commerciaux, consultants avant-vente et consultants techniques.
Références
Près de 500 clients pour webMethods, plus de 300 références pour Active Software.
Historique
Travaillant sur les spécifications du modèle Corba pour le compte de l’OMG, Jim Green et Rafael Bracho constatent que les techno-
logies objet s’avèrent peu efficaces pour communiquer en asynchrone avec un existant. Ils proposent un Extended-Corba, refusé par
l’OMG, ce qui les conduit à développer un prototype pour concrétiser leur vision. Celui-ci est financé par le Java Funds, fonds
d’investissement de la Silicon Valley auquel participent IBM, Oracle, Sun Microsystems, KPMG, etc. Ce prototype est la première
version de ce qui deviendra le produit phare d’Active Software : la suite ActiveWorks, élue produit de l’année 1999 par DataMation.
Dédiée à l’intégration EAI, elle est aujourd’hui renommée webMethods Enterprise.
De son côté, webMethods s’intéresse depuis sa création en 1996 aux échanges B2B et justifie aujourd’hui d’une solide expérience
autour des e-marketplaces, organisées autour de la solution webMethods B2B Server, comme celles de Dell (25 000 acheteurs) et
86 d’Ariba (30 000 fournisseurs). Son connecteur B2B pour SAP R/3 est utilisé par Oracle pour sa suite Oracle Applications et pour OIS
(Oracle Integration Server), et son Business Connector (invocation de fonctions SAP via HTTP et SMTP et retour des données au
format XML) équipe aujourd’hui SAP R/3 en standard.
D’une façon générale, webMethods croit énormément à la propagation des standards XML à la conception desquels il participe ;
webMethods est ainsi directement impliqué dans le groupe de travail ebXML.
webMethods fournit aussi deux niveaux complémentaires de service : Trading Network (monitoring et audit des échanges entre
partenaires) et B2B.com, un portail dédié aux échanges B2B, à partir duquel une entreprise est en mesure d’inclure rapidement un
partenaire potentiel à son réseau d’échange (téléchargement des adaptateurs applicatifs requis, mise en relation avec des intégra-
teurs qualifiés…).
Enfin, l’intégration de webMethods Enterprise et de webMethods B2B sera effective au premier trimestre 2001, via l’utilisation d’ un
référentiel et d’un environnement de développement communs.
Le modèle EAI de webMethods
B2B WebMehods B2B Server
Processus Visual Integrator / Integration Process
webMethods Enterprise
Moteur d'intégration Information Broker
Composants Agents / Designer
Données Intelligent Adapters
Transport Information Broker
Figure 25 - Modèle EAI de webMethods
B2B : WebMethods B2B Server

webMethods B2B fournit une architecture autonome pour l’intégration étendue, avec une forte compétence autour des e-market-
places. La communication est organisée par une entreprise pivot, utilisant webMethods B2B, connectée à ses partenaires via
webMethods B2B for Partners.
Les standards supportés sont :
• Protocoles : HTTP, FTP, SMTP
• Langages : OBI, xCBL, cXML, fpML (langage financier)
• Frameworks : RosettaNet, BizTalk
• Un grand nombre de protocoles EDI (UCS, VICS, EANCOM…)
Toutes les connexions clientes sont sécurisées via un mécanisme d’identification par mots de passe, par cryptage SSL, par certificats
digitaux X.509 et par listes ACL pour chaque service B2B. Un connecteur MQ permet à la solution de se connecter sur toute plate-
forme d’EAI existante.
webMethods B2B est un gestionnaire de services (100 % Java) qui communique avec le hub EAI par le biais des files d’attente en
mode publish and subscribe. La modélisation des processus est autonome grâce au B2B Pipeline Editor.
87
Processus : Visual Integrator et Integration Process

L’utilisateur définit un ensemble d’Integration Components, qui sont autant d’actions élémentaires sur des données (création d’un
client, par exemple). Ces Integration Components sont ensuite liés entre eux pour former une chaîne logique d’actions, appelée
Integration Process. Ces enchaînements sont graphiquement modélisés à l’aide du module Visual Integrator.
ActiveWorks propose son propre moteur de workflow mais sait aussi s’interfacer avec plusieurs moteurs de workflow existants et
les laisser piloter le système.
Application : Information Broker

Information Broker est le cœur du système ; il reçoit les événements provenant des connecteurs applicatifs. Il gère les files d’attente
de messages d’événements. Des API sont disponibles pour configurer, gérer et surveiller les activités du système.
Composants : Agents et Designer

Les Agents sont des programmes spécifiques et propriétaires offrant des possibilités de développement diverses (portions de code
spécifiques en Java, langage de règles en anglais). ActiveWorks sait les reconnaître et les intégrer, préservant performances, stabilité
et sécurité. Les Agents savent également s’interfacer avec des composants externes et fournissent ainsi des réponses personna-
lisées à l’interception d’événements.
Le module optionnel ActiveWorks Designer permet de simplifier l’intégration en fournissant une passerelle entre métier et technique,
en transformant, via une modélisation UML, les processus métier en squelettes de code Java.
Données : Intelligent Adapters

Active Software dispose d’une cinquantaine de connecteurs, bidirectionnels et « multithreadés ».
Event Type Editor est un outil graphique convivial de paramétrage et de configuration des connecteurs applicatifs. Ils parcourent les
catalogues des bases de données et les référentiels des progiciels afin de procurer à l’utilisateur des modèles de données analysés.
L’utilisateur définit une enveloppe de message en choisissant graphiquement les champs ou les propriétés qu’il souhaite incorporer.
Les utilisateurs d’ActiveWorks peuvent écrire leurs propres adaptateurs pour les applications spécifiques.
Transport : Information Broker

Information Broker gère ses propres files d’attente en utilisant en mode publish and subscribe et reply-request.
88
Synthèse
Montée en charge La montée en charge se traite de façon traditionnelle, en deux points : d’une
part par une configuration matérielle appropriée et par la répartition géogra-
phique, d’autre part au niveau des connecteurs, ceux-ci étant
« multithreadés ». Une configuration multi-hub peut être mise en place sans
compliquer l’administration : les brokers sont logiquement liés entre eux, et
toute modification du broker principal est répercutée sur les brokers liés.
Tout service B2B de webMethods B2B est « multithreadé », limitant la charge
machine.
Transactions et moniteurs transactionnels La multiplication des brokers de part et d’autre d’un point réseau sensible peut
permettre au système de continuer à fonctionner même en cas de rupture
réseau.
Application Transaction Coordinator permet de définir graphiquement des
transactions longues avec conservation du contexte dans des bases de
données Oracle ou Microsoft et rollbacks globaux sur l’ensemble de chaque
transaction. Active Integration Monitor affiche le contenu des transactions et
permet de les reprendre dans l’état dans lequel elles étaient lors de leur
interruption.
Administration Les outils disponibles pour administrer et superviser la plate-forme d’EAI, les
connexions avec des agents réseaux SNMP (Simple Network Management
Protocol).
Tolérance aux pannes Les Information Brokers et les Intelligent Adapters peuvent être placés en
clusters.
Sécurité Signature digitale pour les enveloppes de messages, certificats digitaux à base
de clé, cryptage SSL géré au niveau des connecteurs applicatifs. Information
Broker peut rejeter toute production d’événement non autorisé provenant d’un
Dynamic Adapter (Client Grouping).
ActiveWorks garantit la délivrance des messages au destinataire.
XML La communication B2B est essentiellement XML. La communication B2B est
essentiellement XML.
XML est aussi un des formats pris en charge par les Intelligent Adapters. Le
Data Transformation Agent est capable de transformer des données non-XML
(comme des données EDI) en données XML.
Ouverture webMethods Enterprise fournit des connecteurs applicatifs pour moteurs de
workflow externes. Les Agents peuvent s’interfacer avec des composants 89
externes.
WebMethods B2B Server est ouvert à LDAP et à NIS (Network Information
Service).
Portabilité ActiveWorks est disponible sur plates-formes Windows NT, Sun Solaris, HP-
UX, Irix, Digital Unix et Compaq Tru64.
Productivité de développement ActiveWorks propose un grand nombre d’outils dotés d’une interface
graphique conviviale qui permet un paramétrage fin en limitant la production
de lignes de code. Certains éléments, comme Integration Components, sont
réutilisables au travers de plusieurs Integration Processes.
Le module optionnel Designer est intéressant mais nécessite des applications
externes (Visio Professionnel 5.0).
Déploiement Rapidité de déploiement de la solution d’intégration et capacité à modifier
facilement cette distribution pour optimiser le fonctionnement.
Formation Cursus de formation de 4 à 5 jours, en France et en français.
EAI De l’intégration à l’e-business / C o n c l u s i o n
C H A P I T R E
Conclusion
En France, les produits d’EAI inspirent encore une certaine méfiance, ce qui ralentit leur implantation, alors que d’autres pays européens,
comme l’Italie, semblent les adopter plus largement. Étant donné l’envergure des besoins couverts par l’EAI et le B2B, ces produits vont
inévitablement s’imposer à moyen terme en France et l’EAI va devenir un marché extrêmement important dans les prochaines années.
Pour favoriser l’acceptation des plates-formes d’EAI, la démarche de développement consistant en une personnalisation des
fonctionnalités apportées par une plate-forme éditeur offre un compromis qui concilie la robustesse de ces outils avec les besoins
de « sur mesure » des premiers projets d’intégration.
En effet, il peut être intéressant de réaliser un projet d’intégration interne afin de consolider son propre système d’information et
d’être ensuite en mesure de s’insérer efficacement à une chaîne d’échange interentreprises. Comme les plates-formes d’EAI du
marché sont aujourd’hui des offres matures et fiables, on peut donc investir sans risque. Les bénéfices sont immédiats, entraînant
un retour sur investissement réel et rapide, même si le coût d’un projet EAI est généralement élevé et sa mise en œuvre complexe.
Le monde de l’échange B2B est à l’heure actuelle en pleine consolidation. Comment arbitrer au mieux la confrontation entre des
technologies en cours de maturation et le besoin d’implémenter une solution d’e-business, outil désormais indispensable en matière
d’avantage concurrentiel ?
Il est déjà possible de se tourner vers des plates-formes capables d’implémenter sans risque des solutions fondées sur des langages
stables, comme cXML, xCBL, etc., pour lesquels il existe de vrais retours d’expérience.
Ceux qui mettront dès aujourd’hui en œuvre une politique d’e-business bénéficieront d’un avantage certain sur leurs concurrents,
avance qu’ils pourront conserver car, comme l’affirme Sam Laufer, vice-président d’une compagnie tournée depuis 2 ans vers le
B2B : « Nous avons compris que l’Internet changerait radicalement les modes de distribution et qu’il fallait s’employer à en faire
notre force plutôt que d’attendre qu’il devienne notre faiblesse. »
Pour en savoir plus, vous pouvez consulter :
http://www.eaijournal.com
Un ensemble d’articles rédigés par des consultants ou des éditeurs de solutions, des interviews, des fiches produits : une mine
d’informations.
90 http://www.intelligenteai.com
Le portail du groupe CMP.
http://eai.ittoolbox.com/
Un portail riche des informations les plus récentes.
http://b2b.ebizq.net/
http://eai.ebizq.net/
http://www.messageq.com/
Trois facettes d’un site riche en articles rédigés par des consultants ou des éditeurs de solutions d’EAI, d’eAI et de B2B.
Créé en 1988, Cosmosbay est un groupe de conseil en
e-business et de mise en œuvre de e-services. Sa
mission est d’accompagner les entreprises dans la
définition et la réalisation de leurs solutions métiers
pour le e-business.
Trois pôles d’activités complémentaires constituent son
offre globale : Cosmosbay consulting (stratégie & organi-
sation), Cosmosbay agency (communication & design) et
Cosmosbay systems (technologie & ingénierie).
Cosmosbay maîtrise l’ensemble des problématiques de
la chaîne de valeur électronique : gestion de la chaîne
logistique (Supply Chain Management), intégration
d’applications d’entreprise (Enterprise Integration
Application), gestion de la connaissance (Knowledge
Management) et gestion de la relation client (Customer
Relationship Management).
Cosmosbay est également un groupe français reconnu
pour son expertise des technologies du web, notamment
XML et Java.
C o n t a c t
PARIS LYON MARSEILLE
10, rue du Faubourg Poissonnière 84, rue du 1 er mars 1943 Bâtiment William Carr
75010 Paris 69625 Villeurbanne Cedex 263, Boulevard Michelet
Tél : +33 1 53 24 67 80 Tél : +33 4 72 65 21 00 13009 Marseille
Fax : +33 1 53 24 67 89 Fax : +33 4 78 85 58 24 Tél : +33 4 91 77 07 91
Web : www.cosmosbay.com • E-mail : info@cosmosbay.com

COSMOBAY - Livre Blanc Eai - Tres Complet

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

COSMOBAY - Livre Blanc Eai - Tres Complet

Transféré par

Droits d'auteur :

Formats disponibles

EAI

François Rivard Novembre 2000

Table des matières

1 VUE D’ENSEMBLE : LE SYSTÈME D’INFORMATION E-BUSINESS 7

Fédérer, unifier, s’adapter ..................................................................................................................................................................................................... 8

Mettre en œuvre un système intégré ................................................................................................................................................................................... 9

Domaines d’application ......................................................................................................................................................................................................... 11

De l’intégration à l’e-business ............................................................................................................................................................................................. 13

Transport : un middleware pour les données ..................................................................................................................................................................... 16

Données : les adaptateurs applicatifs ................................................................................................................................................................................. 19

Composants : appliquer la logique d’entreprise ............................................................................................................................................................... 21

Moteur d’intégration : le cœur du système d’e-business ................................................................................................................................................ 23

3 DE L’EAI À L’INTÉGRATION ÉTENDUE 27

Processus : modélisation métier .......................................................................................................................................................................................... 27

B2B : eAI ou l’intégration étendue ....................................................................................................................................................................................... 29

XML et les six couches du modèle eAI ............................................................................................................................................................................... 33

XML, langage privilégié de l’échange B2B ........................................................................................................................................................................ 37

Une architecture alternative d’EAI bâtie sur XML ............................................................................................................................................................. 43

Sources de données ..................................................................................................................................................................................................................... 45

5 MARCHÉ DE L’EAI ET OFFRES DES ÉDITEURS 48

Panorama du marché de l’EAI ............................................................................................................................................................................................... 48

Mercator Software ................................................................................................................................................................................................................... 63

Neon (New Era of Networks) .................................................................................................................................................................................................. 67

STC (Software Technology Corporation) .............................................................................................................................................................................. 71

Tibco Software .......................................................................................................................................................................................................................... 76

Fédérer, unifier, s’adapter

Mettre en œuvre un système intégré

Recréer un système d’information intégré

Généraliser les passerelles interapplicatives

Figure 1 – Système « spaghetti »

Fédérer les systèmes

SCM ERP CRM E-commerce

Figure 2 – Système d’e-business hub-and-spokes (à moyeu et à rayons)

Gestion de la chaîne logistique

Gestion de la relation client

Figure 4 - Modèle eAI

Ce chapitre reprend les couches décrites dans la vue d’ensemble :

Middleware asynchrone : les MOM

Figure 5 – Modèle publish and subscribe

Middlewares synchrones : les ORB et HTTP

Couche plate-forme et EAI

Données : les adaptateurs applicatifs

Typologie des adaptateurs

Couche données et EAI

De l’adaptateur « léger » à l’adaptateur « riche »

De l’adaptateur « riche » statique à l’adaptateur intelligent

Composants : appliquer la logique d’entreprise

OAGI (Open Application Group, Inc.)

Moteur d’intégration : le cœur du système d’e-business

Configuration, administration et supervision

Ouverture aux fonctions d’annuaires

Technologies : les message brokers

Couche moteur d’intégration et EAI

Figure 6 – Architecture hub-and-spoke (source : Software Development Magazine)

Application Message Application

Figure 7 – Architecture distribuée multi-hub (source : Software Development Magazine)

De l’EAI à l’intégration étendue

Ce chapitre reprend les couches décrite dans la vue d’ensemble :

Processus : modélisation métier

Séparation du métier et de la technique

Processus métier et processus techniques

28 • Des fichiers journaux pour rendre compte de l’activité.

Gestion d’alertes et notification automatique