cosmobay - livre blanc eai - tres complet

E A IDe l ’ i n tég ra t i on à l ’ e -bus iness

François Rivard

consultant senior

Tél : +33 1 53 24 67 80

[email protected]

Jean-Christophe Bernadac

directeur technique

Tél : +33 4 72 65 21 00

[email protected]

François Knab

vice-président

Tél : +33 1 53 24 67 80

[email protected]

Avec le concours

de François Bourcier

Novembre 2000

E A IDe l ’ i n tég ra t i on à l ’ e -bus iness

4

E A I D e l ’ i n t é g r a t i o n à l ’ e - b u s i n e s s / T a b l e d e s m a t i è r e s

Table des matièresTable des matières ................................................................................................................................................................................................... 4

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

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

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

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

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

1

2

3

4

5

T a b l e d e s m a t i è r e s

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

Moteur d’intégration ..................................................................................................................................................................................................................... 46

Référentiel de synchronisation .................................................................................................................................................................................................... 46

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



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

CONCLUSION 90

5

6

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 proprebase de données et sachant exploiter le confort procuré par un réseau local. Les réponses apportées aux besoins de l’entreprise enmatière de système d’information et de traitement des données étaient en partie guidées par les possibilités technologiquesdisponibles 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, deslé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égligeablede 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 indispensablede maintenir un existant opérationnel tout en amorçant la transition vers une consolidation des données. Les acteurs disposentainsi d’informations fédérées d’aide à la décision assurant la cohérence d’une stratégie partenariale et accompagnant ladé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, CustomerRelationship 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 lagarantie 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 aprouvé 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 desprojets, liée au modèle économique d’Internet, et le besoin de mettre rapidement en application une politique d’e-businessné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 cessystè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 nouveaudéfi permanent lancé à l’entreprise. Toute modification du contexte économique et concurrentiel doit être absorbée sereinement parle système d’information de l’entreprise. Les travaux d’adaptation et d’évolution ne doivent entraîner aucune instabilité, mêmetemporaire, car le facteur Internet impose la disponibilité permanente des systèmes de commerce électronique.

1C H A P I T R E

7

V u e d ’ e n s e m b l e

Vue d’ensemble Le système d ’ informat ion e-business

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 logiqued’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 œuvredans les projets d’intégration répondent à ces exigences et s’appuient aujourd’hui, pour étendre l’intégration aux partenaires del’entreprise, sur l’apport des technologies d’Internet, notamment de leur champion : XML (eXtensible Markup Language).

Fédérer, unifier, s’adapterLes 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 entreelles.

• 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 cettedé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 enligne par un internaute, les opérateurs du site reçoivent l’information par e-mail et éditent un bon de commande papier. Ce bon decommande est transmis par courrier interne au responsable logistique, qui vérifie l’état des stocks au moyen de l’interface de sonprogiciel de gestion intégré (ERP). Constatant l’indisponibilité du produit, il décide de s’adresser à son fournisseur par le biais dulogiciel d’approvisionnement spécifique qu’il utilise depuis plusieurs années. Le fournisseur transmet la date de réception du produitaux 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é ledé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 lesengagements 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èmed’information est indispensable pour doter Brique et Mortier d’une infrastructure informatique capable d’accompagner sa stratégiee-business.

Envisageons maintenant un système dans lequel les applications sont interconnectées. L’arrivée d’une commande en provenance dusite Internet déclenche un processus métier pilotant l’interrogation de l’application logistique pour vérifier la disponibilité desproduits, 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 alorsinformé 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 rapportdélais-coût est ainsi optimisé. Enfin, chaque fournisseur doit pouvoir informer le site marchand de la disponibilité de ses produitset de ses offres promotionnelles pour agencer au mieux le catalogue en ligne proposé aux internautes. L’automatisation complètereste une hypothèse de travail car dans la pratique, une intervention humaine demeure indispensable en certains points du processusde 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’achatsintégrés peut réduire de 85 % les coûts habituellement liés à ces opérations.

8

E A I D e l ’ i n t é g r a t i o n à l ’ e - b u s i n e s s / V u e d ’ e n s e m b l e

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équencesimportantes sur les coûts et les délais. Face aux changements permanents et aux fortes contraintes du marché, la refonte d’unsystème d’information se justifie en général plus par son obsolescence que par le seul besoin d’intégration. Cette logique mènenaturellement à la mise en œuvre de progiciels qui sont intégrés par essence et qui disposent d’ouvertures sur les technologiesInternet 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étierofferts, 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éfinisdans 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 flexiblesusceptible, 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é desapplications mises en œuvre en vue d’en assurer la pérennité.

Généraliser les passerelles interapplicativesLes 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 etparfois de faisabilité technique. Dans de nombreux cas, le résultat final de cette démarche est une écrasante complexité et une totaleopacité. Les projets sont difficiles à terminer, puis à maintenir. La solution apportée freine les possibilités d’intégration de nouvellesfonctionnalités ou de remplacement des briques existantes.

Le Gartner Group qualifie ce type de solution de système « spaghetti ».

9


Applicationslégataires

Applicationsspé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. Enrevanche, 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évelopperpour aboutir à un système complètement communicant est n (n – 1). Pour 6 applications, il faut donc 30 passerelles… De plus, leremplacement d’une application par une nouvelle version ou par une application d’un autre éditeur risque fort de rendre la passerelleobsolète ou d’entraîner des travaux de maintenance complexes et coûteux : l’équipe de développement initiale n’est plus forcémentdisponible 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 changementconsacrent jusqu’à 40 % de leur budget informatique annuel au remodelage des flux d’informations entre leurs différents systèmeset applications. Le chantier d’intégration est donc un poste important du budget informatique des entreprises ; sa bonne utilisationdoit privilégier la flexibilité et la pérennité du système intégré.

Fédérer les systèmesPré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 existantesd’une entreprise et d’échanger des informations de l’une à l’autre. Ces outils autorisent la mise en application d’une démarche defé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 architecturemodulaire dans laquelle les applications peuvent être modifiées séparément sans impact sur le système existant. La démarche d’EAIpermet de mettre le client au centre du système d’information en lui fournissant l’ensemble des fonctionnalités et des données dontil a besoin en temps et en heure. On parle d’architecture hub-and-spokes (à moyeu et à rayons) ou d’architecture soleil.

1 0


Applicationslégataires

Applicationsspécifiques

SCM ERP

Applications packagées

CRM E-commerce

Solutiond'EAI

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

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éspar ces outils dans la mise en œuvre du système d’e-business (fluidification des échanges d’information, modélisation desprocessus métier, flexibilité et réactivité au changement) et l’évolutivité de ces plates-formes dans le cadre de l’intégration denouvelles applications garantissent un retour sur investissement très rapide – en général après quelques mois d’exploitation. Lesplates-formes d’EAI conduisent également à une industrialisation des processus de conception, de développement et de déploiementdes 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’applicationLes 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 sastraté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’uneapproche globale qui couvre tous les aspects logistiques de l’entreprise, depuis la planification des ressources jusqu’à la livraisondes produits, en passant par les prévisions, la conception et la fabrication.

Ce type de besoin concerne tout particulièrement les entreprises dont la croissance s’est effectuée par fusions ou acquisitions et quine 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 meilleurcontrôle du processus global de production. Cette démarche conduit naturellement à une meilleure productivité, à une réduction descoû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 lademande. L’organisation doit bien sûr refléter ce modèle de flexibilité pour en garantir l’efficacité et assurer la satisfaction du clientfinal 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 relationclient. Le projet d’intégration répond alors pleinement à une problématique globale d’entreprise.

Gestion de la relation clientLa 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 lesdonné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. Eneffet, le système CRM, situé à la croisée de domaines tels que la vente, le marketing et le support client, est un consommateur avided’informations consolidées. En aval, il peut également s’intégrer avec les applications de facturation et de comptabilité ou avec dessystèmes décisionnels.

1 1


Cette démarche d’intégration des informations client élargit le potentiel de personnalisation des services offerts. Ce potentiel semanifeste lors de l’extension des activités de l’entreprise sur Internet. La personnalisation du contenu et des services est unestratégie payante en matière de fidélisation des clients ; cette démarche rend possible la collecte d’un ensemble d’informationsindispensables à la connaissance du profil des internautes visitant le site. Cette application devient en effet un point de contactprivilé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 ontune appréhension « physique » du client qu’une application Internet ne peut pas avoir. L’application Internet doit comporter desmé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 etdes 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 desrè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érentielclient, indispensable aux applications CRM et point central des applications d’e-business construites sur le nouveau système.

e-marketplacesUne place de marché est un point de liaison central destiné à réunir des centaines d’acheteurs et de vendeurs. Sur Internet, le conceptde 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 etconvergent aujourd’hui vers un certain nombre d’initiatives de normalisation. Ce nouveau modèle économique impose la prise encompte 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 defacturation é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 dese 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 (EnterpriseInformation 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 estune place de marché reliant les acteurs des industries informatique et électronique fondée sur B2B Commerce Platform, d’AribaSoftware, 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 seconnectent à 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 entreapplications, 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).

1 2


De l’intégration à l’e-businessParmi 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 cellequi 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 œuvrede 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 aussila plus apte à assurer leur pérennité face aux besoins d’évolution. Cette réactivité couvre la possibilité d’accueillir facilement denouvelles 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 richesseet 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’uneorganisation, 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.

• L’extraction d’informations depuis les applications et l’insertion de nouvelles informations dans ces applications – Cetteopé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. Ilsenrichissent 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.

1 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 messageplacé 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 lesrouter vers l’application destinataire. Les composants peuvent être sollicités pour vérifier certaines règles métier et influencer lecomportement 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 dumarché. 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’uneplate-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 nouveauxmodèles économiques créés et promus par Internet et ses technologies (TCP/IP, SMTP, HTTP, FTP, XML, etc.). Cette deuxièmegé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étierde l’entreprise.

• Une infrastructure d’échange B2B – Elle permet aux entreprises de communiquer.

Le moteur de workflow complète le travail des composants dans l’organisation de la logique métier. Concrètement, les processusmétier modélisés au sein du moteur de workflow sont implémentés par ces composants. Leur exécution s’enrichit de mécanismesde 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 dansdes langages normalisés construits sur XML. Cet échange s’intègre dans un processus métier workflow, lui-même normalisé par lestravaux 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.

1 4


B2B

EAI eAI

Processus


Composants

Données

Transport

Figure 4 - Modèle eAI

Ce modèle complet a été initialement introduit par le Hurwitz Group, cabinet de conseil de Boston. On constate que les servicesinitiaux du modèle EAI sont toujours présents et constituent les fondations du modèle étendu. Des fonctionnalités complémentairessont intégrées, mais le mode de fonctionnement de la plate-forme est inchangé. La flexibilité est toujours présente ; elle s’étend auxpartenaires 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 (lemiddleware, les connecteurs, etc.) côtoient des éléments d’un haut niveau d’abstraction (modélisation des processus métier) pouraligner 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 versl’eAI.

1 5


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

• transport ;

• données ;

• composants ;

• moteur d’intégration.

Transport : un middleware pour les données

DéfinitionLes services de transport assurent la livraison des données aux applications via le moteur d’intégration, tout comme l’appareilcirculatoire 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 lesmiddlewares hétérogènes présents dans l’entreprise. L’intégration s’opère ainsi à tous les niveaux : applications, données etmiddlewares.

Fonctionnalités et technologiesLe middleware de l’EAI par excellence est asynchrone. Il est constitué de files d’attente de messages (message queues). Cessolutions sont regroupées sous la dénomination de MOM (Message Oriented Middleware). La plus connue est sans contesteMQSeries, d’IBM ; Microsoft propose MSMQ, sa propre solution. Les MOM sont une couche de transport et ont besoin pourfonctionner d’un outil d’administration des messages transportés : le message broker. Dans une solution d’EAI, ce dernier tient lerô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 etau 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 deré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’applicationdestinataire, 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 destechnologies complémentaires qu’une plate-forme d’EAI doit savoir intégrer et faire communiquer avec le système de MOM surlequel elle repose.

1 6

E A I D e l ’ i n t é g r a t i o n à l ’ e - b u s i n e s s / L e m o d è l e E A I

2C H A P I T R E

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 fluxinterapplicatifs reposant sur une logique asynchrone : le message est envoyé sans que le processus émetteur attende unequelconque 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é duré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 depriorité.

• Gestion événementielle – La réception d’un message, ou sa délivrance, sont des événements dont la réalisation peut endé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édiairegé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. 1 7

L e m o d è l e E A I

Topic

Subject, Channel

Publisher

Agent

Agent

Rules

Subscriptions

subscribe

registrer

receive notification/message

Subscriber

Figure 5 – Modèle publish and subscribe

Middlewares synchrones : les ORB et HTTPLes ORBLes ORB peuvent être considérés comme une évolution structurée des mécanismes de RPC (Remote Procedure Calls). Dans lesdeux cas, le principe est l’invocation synchrone de fonctions applicatives sur des serveurs distants. A la suite de l’appel, le clientattend 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 autonomesdoivent continuer à s’exécuter indépendamment les unes des autres. Rendre le système intercommunicant ne signifie pas le rendreinterdé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 requispar 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 allonsbriè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 desrequêtes, localise le composant appelé et retourne le résultat de l’appel. Un référentiel (interface repository) est nécessaire pourconnaître les interfaces de tous les composants disponibles. Les ORB sont conçus pour être utilisés dans des projets utilisant unevéritable approche orientée objet.

Les implémentations d’ORB disponibles sur le marché sont Corba (Common Object Request Broker Architecture), de l’OMG (ObjectManagement Group), DCOM (Distributed Component Object Model), de Microsoft et les EJB (Enterprise JavaBeans), de SunMicrosystems.

• Corba – L’OMG, groupement de plusieurs centaines de membres, a défini dans les années 90 un standard pour le monde desORB : 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 communicationinter-ORB. Ce protocole a ensuite été étendu à des ORB ne s’alignant pas sur Corba, comme RMI (Remote MethodInvocation), 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 protocoleORPC (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 tiersfournissent des services COM sur différentes plates-formes. Les services offerts par DCOM sont plus limités que ceuxproposé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étierEJB 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 decommuniquer 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.0vise à combler ces lacunes.

1 8


HTTP Nous avons évoqué les raisons pour lesquelles un middleware synchrone paraît inadapté à une architecture d’intégration. HTTPsemble 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 semblelui 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 chezles partenaires. De plus, HTTP est un standard véhiculé par un autre standard, le réseau Internet, qui permet d’élargir facilement lagamme 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. Cemiddleware se superpose à celui utilisé en interne par la plate-forme d’intégration : le message provenant d’un partenaire esttransmis à 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 dessystèmes d’e-business « temps réel » entièrement fondés sur un protocole synchrone.

Couche plate-forme et EAIAujourd’hui, le middleware prédominant dans les offres d’EAI du marché est bien le MOM ; le couple MOM/message broker est lenoyau 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 desingénieurs ayant précédemment participé aux spécifications ou au développement de solutions de message queuing parmi les plusrenommées (citons MQSeries et MSMQ). De par leur rôle et leur position, ils ont su saisir toute l’importance de cette technologie etles développements qu’elle était susceptible de susciter et de supporter. Leur approche est qualifiée de bottom-up.

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, deTIB/Rendezvous, de Tibco, ou des Intelligent Queues, de STC. Les offres d’EAI utilisent généralement un message broker qui abesoin de ce type d’infrastructure, qui garantit un bon niveau de performances sur son architecture propre. Lorsque l’éditeur nepropose pas de solution, la plate-forme est généralement conçue pour reposer sur un des MOM du marché, parmi lesquels figurenten 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 pourautant de leur unique activité) ont aussi évolué vers l’ouverture de leurs solutions à l’intégration d’applications. IBM a pu s’yconsacrer 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éfinitionLes 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ûtslié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éed’un message, étape d’un processus métier) et les diriger vers l’application destinataire. Les connecteurs assurent la communicationentre 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 lessources 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.

1 9


2 0


Fonctionnalités et technologiesLes connecteurs doivent être des systèmes non intrusifs (on n’introduit pas de portions de codes dans les systèmes sources oucibles).

Ils peuvent fournir des services complémentaires tels que la gestion des exceptions ou des mécanismes de remontée d’erreurs. Ilsdoivent 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 adaptateursIl 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écifiquesIl y a, dans une entreprise, un ensemble d’applications spécifiques légataires pour lesquelles il ne peut exister d’adaptateur standardsur le marché. Pour cette raison, les éditeurs fournissent généralement avec leur plate-forme un kit de développement. Il guide lamise en œuvre de connecteurs et masque une partie de la complexité technique propriétaire, notamment la communication avec lesfiles d’attente.

Les kits de développement (SDK, Software Development Kit), la documentation sur les API existantes et la formation dessinent lapanoplie du développeur de connecteurs. Il est donc important, lors de la recherche d’une plate-forme d’EAI, de vérifier si desformations 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 cesmissions à des intégrateurs partenaires.

Couche données et EAILa 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 entredeux offres. En effet, la technologie des connecteurs a énormément évolué depuis les débuts de l’EAI. Nous allons en tracer un brefhistorique 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âchecompliqué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 uneinterface graphique pour connecter les systèmes sans recourir à la programmation. Ces adaptateurs fournissent également unequalité de service supérieure, comme la prise en compte d’une partie de la montée en charge par multithreading statique oudynamique.

De l’adaptateur « riche » statique à l’adaptateur intelligentLa première génération d’adaptateurs, légers ou riches, est celle des adaptateurs statiques, qui demandent systématiquement uneconfiguration manuelle. Par exemple, dans le cas d’une base de données, l’adaptateur a besoin d’être informé manuellement de lacomposition des tables et de leurs attributs. Si les informations de configuration ne sont pas correctes, le système ne fonctionnerapas. Par conséquent, si le schéma de la base de données change, aucun mécanisme intelligent ne saura mettre automatiquement laconfiguration à jour.

Les adaptateurs intelligents, connecteurs applicatifs de deuxième génération, apportent la réponse à cette problématique. Ils savents’autoconfigurer en consultant les référentiels des applications auxquelles ils se connectent (tables système dans les bases dedonné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 ladescription des tables existantes et de leur structure (nom et types des attributs). Toute modification de la composition de la baseest 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. Lesadaptateurs 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-formeFusion, 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 deviennentun ensemble de technologies sophistiquées et prêtes à l’emploi au service d’un type d’application. Une console graphique deconfiguration restitue le résultat des processus d’introspection effectués par les connecteurs. Dans le cas d’un ERP, le connecteurremonte 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’entrepriseLe 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’unréférentiel de logique métier adapté à l’entreprise. Cette logique doit être implémentée dans des composants, auxquels le moteurs’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 vainterroger 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 proposerune remise dont le taux est lié à ce montant. On constate qu’une extraction complémentaire de données est demandée au moteurd’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 esttransmis 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é (connecteurCorba, 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 outilsde 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 êtregénérés à partir des processus métier définis dans le workflow, pour devenir la représentation technique de ces processus.

2 1


2 2


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 pratiqueset 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écifieexhaustivement 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, à traverseux, 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 ;

• mise au point de normes pour décrire les flux entre les composants logiciels métier, définissant l’interopérabilité pour la synchronisationde 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é descomposants 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 deBOD (Business Object Documents) entre ces interfaces virtuelles.

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

DéfinitionLe 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 routageet 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égrationest 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 formatutilisé par l’application de destination (fonctionnalités de transformation) et à les transmettre à cette application (fonctionnalités deroutage).

TransformationLes applications du système d’information ont des modèles de données différents. Les données de l’application A ne sont pasdirectement 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 Datede 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 chaqueapplication et sait comment transformer les informations pour assurer la correspondance entre les modèles de données. C’est leprocessus 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 nouvellesapplications s’ajoutent aux précédentes. La facilité d’évolution d’une plate-forme d’EAI vers l’intégration de nouvelles applicationsdoit être étudiée avec soins lors du choix d’une plate-forme. La richesse des outils de configuration et de l’interface graphique àdisposition de l’utilisateur doit être qualifiée avec soin.

RoutageL’intelligence de routage est complémentaire de l’intelligence de transformation. Toute plate-forme d’EAI inclut un référentiel desmé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 à laquelleil 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 dansle cas d’une intégration incrémentale (remplacement progressif d’une application par une autre application fonctionnellementéquivalente ou plus évoluée).

FonctionnalitésLe moteur d’intégration, point central du système, complète ses fonctionnalités de transformation et de routage par les servicesd’administration et de surveillance énumérés ci-après.

Configuration, administration et supervisionLes plates-formes d’EAI proposent habituellement trois types d’outils pour insérer la plate-forme au sein du système d’informationet 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 applicationsexistantes, de créer les schémas de correspondance entre les structures de données et les transformations de ces données.

2 3


2 4


• Des outils capables de tracer les échanges de messages, de suivre le déroulement des processus et d’élaborer des rapportsd’activités. Il est indispensable de savoir si les processus se sont correctement achevés et de connaître la durée de leurexé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’unprocessus non achevé. Enfin, il est nécessaire de disposer de rapports sur les performances de la plate-forme et du systèmeet 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 encharge (déplacement des charges et pics de charge), la tolérance aux pannes, les goulets d’étranglements, les ruptures deconnexions réseau, etc. Des outils capables de modifier facilement la répartition des éléments du système et la distribution à distancede ses composants ou des message brokers (architecture multi-hub) vont permettre de pratiquer cette optimisation facilement et àdistance.

Stockage de messagesLe but est d’assurer la persistance des messages non transmis : garantie de la non-perte et de la diffusion de l’information, gestionde l’intégrité des messages, archivage, journaux de fonctionnement et audit des volumes traités.

RéférentielRé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’exploitationd’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 etpersonnaliser la transformation.

Technologies : les message brokersLes message brokers mettent en relation des entités sources et des entités destinataires via un échange de messages entre elles. Ilintè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 formentaujourd’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 unhub centralisé. Il utilise les technologies de files d’attente pour traiter les messages en provenance des différentes applications dusystème. Il est le nœud centralisateur ; il apporte sa valeur ajoutée au contenu et à la structure des messages avant de les diffuseraux applications cibles.

Les connecteurs applicatifs et le système des files d’attente permettent au message broker de s’affranchir de la technologie desapplications auxquelles il transmet des données. En contrepartie, les applications émettrices envoient des messages sans se soucierde la technologie de l’application cible, ni même de celle du message broker. Le couplage lâche entre le message broker et lesapplications du système d’information qui résulte de la mise en œuvre de ces technologies procure un avantage indéniable à cettearchitecture.

Aucun aménagement lié à l’intégration n’est nécessaire dans les applications sources : le développement est réalisé visuellementdepuis 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 andsubscribe.

Les applications publient (publish) des messages sur les files d’attente du MOM gérées par le message broker. Celui-ci transformeles messages et les place sur d’autres files d’attente, où d’autres applications abonnées (subscribe) à ces files les récupèrent. Chaquefile d’attente est caractérisée par un sujet (par exemple, enterprise.erp.logistique).

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ésenced’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 impliquedes architectures performantes, robustes et capables de traiter de gros volumes de données. Elle requiert aussi des fonctionnalitéscomme le support des transactions, l’intégration de processus métier sophistiqués aux règles de routage complexes ou l’ouvertureaux 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 ungestionnaire de transactions sachant communiquer avec le message broker, mais cette possibilité intéressante aura obligatoirementun 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 certainesrègles de routage. Le niveau de sophistication exigé n’est pas forcément atteint. Cette raison a poussé l’EAI à intégrer une véritablebrique de workflow et à la rendre communicante avec le message broker. La complexité des processus d’entreprise à modéliserdé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 unensemble plus vaste.

La plate-forme d’intégration doit incorporer un ensemble de fonctions d’ouverture à des éléments extérieurs qui élargiront sonspectre 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(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 ».

2 5


2 6


Couche moteur d’intégration et EAIRappelons que les architectures d’EAI utilisant un message broker et fonctionnant selon le mode que nous avons décrit sontqualifiées d’architectures hub-and-spoke. Les applications sont connectées à un nœud central, qui concentre les flux. Ce hubcontient 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.

L’architecture hub-and-spoke autorise une administration centralisée et simplifiée. Le nœud central est le point de connexionphysique et le routeur des échanges. Cette architecture supporte des systèmes flexibles auxquels il est aisé d’intégrer de nouvellesapplications. L’intégration entre elles d’applications déjà connectées au hub peut être rapidement mise en œuvre et celles-ci peuventse 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 pointsdu 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 dela charge de chacun des message brokers.

Application

Application

Application

Application

Application

Application

Application

MessageBroker

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

Application

Application Application Application

Application

Application

Application

Application

Application

Application

Application

Application

Application

Application

Application

MessageBroker

MessageBroker

MessageBroker

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

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

• processus ;

• B2B.

Processus : modélisation métier

DéfinitionDans 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 derecul 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.

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 messagebroker ; 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 notreexemple, les systèmes communicants sont administrés par un message broker. Un internaute commande un produit et cetteinformation est transmise à un composant métier qui vérifie l’état des stocks. Le produit est disponible, mais cette commande faitpasser 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 unecommande. Cette commande n’est toutefois pas adressée directement à un fournisseur, car l’intervention du responsable des achatsest 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 nereprend que lorsque le responsable des achats a sélectionné le fournisseur et validé la commande. Si le responsable des achats nepeut 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énementmé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 techniqueEn 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.

3C H A P I T R E

2 7

D e l ’ E A I à l ’ i n t é g r a t i o n é t e n d u e

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

2 8

E A I D e l ’ i n t é g r a t i o n à l ’ e - b u s i n e s s / 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 à leurfuture exécution ne doit pas interférer. Les interlocuteurs participant à la réflexion sont en effet des analystes métier, et non desarchitectes 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, lesseules réponses à apporter concernent les composants métier, l’extraction des données, leur routage et leur transformation.

Processus métier et processus techniquesIl est important de faire la distinction entre la gestion des processus métier, assurée par un moteur de workflow, et l’automatisationdes processus techniques, que le moteur d’intégration de la plate-forme d’EAI doit savoir traiter.

Gestion du workflowSon 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 processusSon 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).

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

StandardisationLes 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.

Fonctionnalités et technologiesIl n’entre pas dans nos intentions de détailler précisément tous les services fournis par un moteur de workflow. Néanmoins, certainesfonctionnalités typiques doivent être présentes pour répondre aux besoins de l’EAI.

Aiguillage conditionnelLes résultats liés à une étape d’un processus permettent au moteur de workflow de décider de la suite à donner à l’exécution duprocessus, suivant les possibilités définies lors de la modélisation. Cet aiguillage peut personnaliser les processus en fonction despopulations d’acteurs concernées, ce qui laisse entendre la possibilité d’un moteur ouvert, interfaçable avec les services d’annuaireou le référentiel des partenaires dans le cadre d’échanges B2B.

Gestion d’alertes et notification automatiqueCette 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 processusLes 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 estachevé. Comme nous avons pu le constater, certains processus doivent aussi attendre une intervention humaine pour poursuivreleur séquence.

Configuration, administration et supervisionAvec un outil d’EAI, la modélisation des processus métier est effectuée depuis une interface graphique dédiée au workflow. Lorsqueles analystes métier détectent un changement dans l’environnement, ils peuvent faire évoluer le processus métier correspondantdepuis l’outil de workflow et constater une répercussion rapide de cette modification sur le plan technique. L’administration desprocessus 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ûtd’exécution d’un processus métier. Au-delà de la technologie, et tout en s’appuyant sur l’existant technologique d’une entreprise, lesprocessus 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 eAILa position de cette couche dans le modèle est stratégique pour plusieurs raisons. D’une part, elle représente clairement le cerveaude la solution, disposant de l’intelligence métier de la plate-forme et parfois, en fonction de la configuration, de l’intelligence métierde l’entreprise. D’autre part, à la jonction des couches moteur d’intégration et B2B, elle assure l’interface de communication entreprocessus privés (internes à l’entreprise) et processus publics (processus normalisés partagés entre partenaires). C’est cette couchepivot qui permet le passage de l’EAI à l’eAI.

De plus, elle améliore la cohérence interne de la plate-forme. Par exemple, l’offre Geneva Integration Suite de Level 8 transforme lesprocessus 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éfinitionL’EAI fédère le système d’information en rendant ses applications intercommunicantes et en centralisant les mécanismes de cettecommunication. 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 publicou 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.

2 9


3 0


Selon cette définition, l’EDI (échange de données informatisé) apparaît comme une forme d’échange B2B (voir l’encadré « Échangessé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 deconserver un avantage concurrentiel. Ceci implique la création de processus interentreprises automatisés, sécurisés, fiables et entemps 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’élargissementdes formes de travail collaboratif.

Ouverture du système d’informationL’insertion de l’entreprise dans une chaîne d’échange (son acceptation par un ensemble de partenaires) ne peut s’opérer avec succèsque dans la mesure où elle est capable de traiter l’information efficacement et de façon fluide. Rien ne doit s’opposer à la diffusionde 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 sonpropre système d’information, la probabilité de voir les données ralenties dans leur circulation et perturbées dans leur traitement estimportante.

Pour illustrer notre démonstration, reprenons notre système à moyeu et à rayons, piloté cette fois par un moteur de workflow. Cesystè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 unensemble 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 économiquesL’automatisation des opérations entraîne évidemment une réduction substantielle des coûts de transaction, qui sont inférieurs à ceuxd’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 cesacteurs 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, enest une bonne illustration. L’entreprise dispose en permanence et en temps réel d’informations sur l’évolution des commandes etpeut 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 normeset de ressources pour distribuer les spécifications d’un nouveau produit à un fabricant. Les délais de fabrication s’amenuisent et leproduit 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.

Fonctionnalités et technologies

Gestion des partenairesLe référentiel d’intégration doit identifier les multiples partenaires avec lesquels les échanges vont être entrepris, le rôle que chaquepartenaire va jouer dans l’échange et les transactions auxquelles il est susceptible de participer.

PerformancesLa 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 unequalité 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égrationLa modularité que procure une plate-forme d’EAI aux applications du système d’information doit se vérifier dans le cadre d’unedé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 surHTTP 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. Onprivilé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éesconfidentielles. Les données échangées sont sensibles et les échanges doivent être sécurisés : cryptage des messages transmis avecX.509, authentification par utilisation de certificats X.509, utilisation de protocoles de sécurité du monde de l’EDI (X.435). Enfin, laconnexion directe à des systèmes partenaires doit s’effacer au profit de l’échange d’informations sur HTTP. Les rôle des standardsdu 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 chiffrementRSA. 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 cryptagefort 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 surune 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 eAILa rapidité d’implémentation des solutions sera un critère déterminant. Une interface graphique va se révéler nécessaire pourparvenir à un bon niveau de productivité. Deux écoles s’opposent quant à la nature des outils susceptibles de répondre au mieux aubesoin.

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 deperformances.

Les autres, éditeurs de solutions B2B, affirment que la démarche d’intégration B2B est une démarche spécifique qu’un outilgénéraliste ne peut prétendre adresser efficacement. La spécialisation de leur plate-forme leur permet de fournir davantage defonctionnalité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 gestionde la sécurité. Cependant, rien n’empêche de développer ces fonctionnalités pour la couche B2B d’une plate-forme initialementdédiée à l’EAI.

3 1


3 2


É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 B2Bdoit 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 lademande en fonction de critères prioritaires. Par conséquent, la phase de prototypage est une étape incontournable de tout projetd’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 peutenvisager d’élargir son activité avec de nouveaux partenaires ou d’en changer sans remettre en cause l’existant et sans impliquer demodifications 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 à sespartenaires 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 couranteet déterminent la faisabilité d’un partenariat, d’une alliance ou d’une fusion. Les entreprises de l’e-business auront à gérer l’imagede 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’unecollaboration.

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’accroissementexponentiel du nombre de partenaires interconectés via une e-marketplace.

XML, le métalangage de description des données, soutenu par l’ensemble de l’industrie informatique, est appelé à prendre une placeimportante sur le marché de l’eAI. Ses avantages intrinsèques le désignent en effet comme une technologie de choix dans cedomaine : 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éelet 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 comptedans une offre d’eAI. S’il est souvent simplement considéré comme un format reconnu par un connecteur applicatif, il est aussiparfois 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. Ellesera 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 transportLes messages extraits des applications peuvent être échangés au format XML et véhiculés sur HTTP – deux standards universels –alors que les MOM reposent généralement sur des technologies propriétaires. L’ensemble est ouvert à d’autres standards, ce quiprend 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 surHTTP 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éalisesur 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 uncouplage 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 technologiessont identiques à celles de ses échanges B2B, et ainsi généraliser l’utilisation de HTTP comme protocole standard de son systèmed’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 dansles entreprises qui ne disposent pas d’un existant technologique fort. Le système d’information est alors conçu comme un systèmeintégré faisant communiquer les applications ERP, SCM, CRM et Internet.

4C H A P I T R E

3 3

X M L e t l ’ e A I

XML et l’eAI

3 4

E A I D e l ’ i n t é g r a t i o n à l ’ e - b u s i n e s s / X M L e t l ’ e A I

XML et connecteursVéhiculer des messages XML sur HTTP implique un premier niveau de transformation des données en XML par les connecteursapplicatifs. La communication avec le moteur d’intégration est organisée autour de ce format pivot, comme dans la plate-formed’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’interfaceXML est toujours identique. De plus, une partie de l’intelligence applicative est déplacée au sein du connecteur, ce qui le rendautonome dans un contexte de distribution de la solution. La montée en charge et la tolérance aux pannes peuvent être gérées auniveau des connecteurs autrement que par multithreading. L’interface XML d’envoi et d’accueil des données peut être réutilisée pourd’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 latechnologie propre à un vendeur en sélectionnant les adaptateurs les plus performants du marché. En effet, à l’heure actuelle lesadaptateurs ne savent qu’exploiter les technologies de la plate-forme avec laquelle ils sont fournis. Par conséquent, l’extraction dedonnées au format XML nécessite souvent de développer ses propres connecteurs et de les intégrer à une plate-forme d’intégrationspécifique. L’élaboration de ce type de plate-forme est évoquée plus loin, dans la section « XML et moteur d’intégration : les serveursd’applications ».

Certains éditeurs de progiciels proposent néanmoins aujourd’hui des connecteurs XML avec leurs solutions : SAP propose leBusiness Connector, et les principaux SGBD du marché (IBM, Informix, Microsoft, Oracle, Sybase) extraient en XML les donnéesrelationnelles stockées à la demande.

XML et composantsMerci de bien vouloir vous reporter à la section « XML, composants métier et workflow ».

XML et moteur d’intégration : les serveurs d’applicationsLa mise en place d’une plate-forme d’intégration reposant sur XML et sur HTTP implique un développement spécifique fondé sur unserveur 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’unmessage broker.

- Dans ce contexte, les questions de montée en charge et de tolérance aux pannes sont prises en charge nativement par le systèmeet é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èmeintégré.

Il faut cependant développer toute la logique de transformation et de routage, alors que le choix d’un message broker n’impose quele paramétrage.

2. Les serveurs d’applications fonctionnent généralement de manière synchrone par RPC ou ORB pour invoquer des méthodes surles 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écutionasynchrone 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 MessagingService est l’API implémentée pour les serveurs d’applications Java. On trouve aussi MQSeries chez IBM et MSMQ dans le mondeMicrosoft.

3. L’architecture repose sur l’exécution de composants administrés par le serveur d’applications. Ceux-ci sont soit des objets métierqui 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 pannestout en améliorant la granularité de déploiement des traitements.

• Transformation - La transformation des données XML d’une application à l’autre est effectuée au moyen de feuilles de stylesXSL (eXtensible StyleSheet Language) au niveau des connecteurs ou des composants métier. La centralisation du déploiementrend cette solution particulièrement facile à maintenir et évolutive. On peut de plus mettre ainsi à profit les fortes capacitésd’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 logiquecodée dans les composants métier. Par exemple, l’ajout d’une nouvelle balise dans un document XML est transparent pour lescomposants 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 nedisposent 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 (commele 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 applicationssont 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 serveurd’applications dédié aux applications d’e-business. C’est le cas de Level 8 avec Geneva Enterprise Integrator ou de Mercator avecWeb Integration Broker. Ces offres s’insèrent dans une offre d’intégration globale et répondent à la nécessité de mettre en œuvre dessolutions 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 besoinsasynchrones. Serveurs d’applications et message brokers apparaissent ainsi davantage comme des technologies complémentairesque 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 undé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écifiertrè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égrationdepuis 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é estle 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érabled’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 insistersur le fait qu’une telle plate-forme n’est pas le « choix du pauvre » ; au contraire, par son respect des standards et l’utilisation detechnologies 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.

3 5


3 6


XML, composants métier et workflowAvec l’interaction de composants métier issus des processus métier et capables d’interpréter la sémantique des données reçues, laplate-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 estautosuffisant ; on peut le considérer comme un message métier qui connaît la nature des traitements à effectuer sur les donnéesqu’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 enXML la définition des processus métier qu’il modélise, l’entreprise pourra partager ses processus métier avec ses partenaires pourmettre en œuvre le réseau neuronal XML.

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 envoyerle 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 ladé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 parTIBCO avec l’acquisition de la société Extensibility et l’intégration de ses outils de conception de documents et de structures dedonnées XML à sa plate-forme ActiveEnterprise.

Entreprisepivot

GE

GE

GE

GE

GEPME

PME

PME

PME

PME PME PME PME

GE

GE

GE

Le réseau de type moyeu et rayons classique

Le réseau neuronal XML

GE = Grande EntreprisePME = Petite ou Moyenne Entreprise

Figure 8 – Évolution des relations interentreprises

XML et B2BXML est le format incontournable dès qu’il est question d’échanges interentreprises. Avec XML, il devient aisé de transmettre desinformations à un partenaire sans en connaître l’existant technologique, sans avoir à s’y adapter techniquement ni à s’y introduirede façon logicielle. En couplant faiblement les systèmes, la technologie constitue de fait un moteur et non plus un frein à l’extensiondes échanges.

L’échange B2B s’organise aujourd’hui autour d’une entreprise pivot, qui sert de relais et pilote les transactions pour un ensemble departenaires au moyen d’échanges normalisés par des langages fondés sur XML.

XML, langage privilégié de l’échange B2BL’industrie informatique connaît une effervescence soutenue depuis quelques temps déjà à cause de la finalisation des langages quivont standardiser les échanges interentreprises et implémenter des plates-formes techniques capables de les supporter. Cesinitiatives vont de l’élaboration de langages de normalisation de catalogues ou d’achats (e-procurement) jusqu’à la formalisation desagré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

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 constateque la quasi-totalité de ces normes d’échanges pour l’Internet sont des langages conçus à partir d’XML, lui-même conçu pourl’Internet.

B2B et EDIIl faut des intérêts communs et une volonté partagée pour parvenir à mettre en œuvre une synergie d’échange interentreprise. Il faut aussidisposer de normes et de standards pour partager des données décrites dans un vocabulaire symétriquement compréhensible par lesparties 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 dedé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, maisde 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 deré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.

3 7


3 8


cXML, d’Ariba SoftwareLa vocation de l’éditeur américain Ariba Software est de fournir des solutions entièrement dédiées au B2B. Son produit phare, AribaB2B 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 80organisations. Il inclut un schéma pour la définition d’un catalogue de produits ainsi que les formats d’échange des bons decommande, 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 lesoffres 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 OneCommerce One (anciennement DistriVision) existe depuis 1994 (depuis 1997 en France) et participe à de nombreuses initiativesrelatives à 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. xCBLest 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, technologied’e-marketplace qui gère la consolidation des catalogues et les transactions, et MarketBuilder, version allégée de MarketSitepermettant à 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 ModelingLanguage) adaptée à l’échange B2B de documents à base de messages XML.


• Commerce One : http://www.commerceone.com ;

• MarketSite : http://www.marketsite.net.

OBI, de CommerceNetLancé 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 standardsouverts pour l’achat sur Internet.

L’initiative de CommerceNet est comparable à celle de Commerce One. Le consortium OBI (Open Buying on the Internet) est leré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’acteurscomme American Express, Barnes and Noble, Lockheed Martin, Microsoft, Netscape et d’un ensemble d’experts des achats et ducommerce 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.

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 CommerceNetLe 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 debase de travail aux groupes de travail ebXML depuis septembre 1999.

ebXML, de l’UN/Cefact et OasisL’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. Sonobjectif 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’EAIet 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 etsémantique global articulé autour du métalangage XML. Les six premiers mois de travaux ont abouti à l’approbation des sujets despécifications et à une démonstration de la viabilité du concept (tests de routage des messages ebXML).

3 9


4 0


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 ontporté leur soutien à ce projet, créé en septembre 1999, qui s’est donnée 18 mois pour atteindre ses objectifs.

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 annoncepar ailleurs la constitution d’un groupe d’experts internationaux chargés de décliner les spécifications techniques de futurs formatsXML sectoriels. Le public visé va de la TPE (très petite entreprise) à la multinationale.

Les objectifs déclarés sont :

• 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 petitesentreprises ;

• de faciliter le support multilingue.

Cet énoncé montre une concordance évidente entre des objectifs ambitieux (démarche internationale désireuse d’intégrer tout typed’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.

Applications Integration Technology

UN

CEN

Sectors

NationalBodies

ebXML

OASIS

SemanticRepositiories

W3C

XMLSteering

Committee

WorkingGroups

Editors

CommerceOne

ISO TC 154BSR

BizTalk,etc.

Figure 9 – Groupes de travail autour d’ebXML

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 lesambitieux objectifs fixés. L’enjeu n’est rien de moins qu’un standard international qui recueillera le soutien de nombreusesentreprises de par le monde. ebXML est une formidable chance pour le commerce électronique et l’initiative la plus prometteuse encours d’élaboration.

Pour en savoir plus, visitez http://www.ebxml.org.

BizTalk, de MicrosoftAvec 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’unformat 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 corpusd’é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 deWindows 2000.

4 1


4 2


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 transformationdes 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 fichiersplats.

• 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 proposentprincipalement 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.

RosettaNetRosettaNet est un standard destiné à résoudre sur Internet les problèmes liés au manque de régulation de la chaîne logistique par lastandardisation des processus métier et par l’établissement d’échange d’informations et de transactions commerciales automatisées.

RosettaNet accorde autant d’importance à la définition de standards de données qu’à la définition de standards de processus. LeRNIF (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éfiniespour 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 passaged’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 pourconduire 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 formatsde données.

Echange professionnelentre personnes

Echange professionnelentre systèmes informatiques

TELEPHONE

PROCESS METIER

DIALOGUE

GRAMMAIRE

MOTS

ALPHABET

SON

e-APPLICATION

PROCESS eBUSINESS

PIP

FRAMEWORK

DICTIONNAIRES

HTML XML

INTERNET

Ro

se

tt

aN

et

Figure 10 – Couches (layers) de RosettaNet

En février 2000, RosettaNet a publié des spécifications détaillées pour différents PIP. On trouve par exemple la distribution denouvelles 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é pourfé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 initiativesAL3 (Automation Level 3) est une initiative conduite par Acord, organisme à but non lucratif chargé de définir des standards dansle monde de l’assurance.

Swift (Society for Worldwide Interbank Financial Telecommunication) est une des plus célèbres organisations de ce domaine ; elledéfinit un standard pour le monde de la banque et de la finance. Quelque 7 000 institutions financières réparties dans 200 pays ensont 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 sontdéjà dépassés lorsqu’ils arrivent sur le marché : les entreprises sont obligées d’agir avant qu’ils soient disponibles et constatentconséquemment l’apparition de nouveaux besoins.

Les standards d’échange doivent donc être flexibles ; le support d’XML conduit justement à cette flexibilité. Les processus doiventaussi être évolutifs : des référentiels en ligne peuvent permettre de bénéficier rapidement de l’évolution d’un standard. Ils doiventenfin pouvoir être personnalisés si plusieurs partenaires trouvent un accord dans le cadre de leurs échanges. Il importera alors deconserver 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 decompétitivité à leurs échanges et conserver cet avantage concurrentiel tout en respectant les normes internationales en vigueur.

Une architecture alternative d’EAI bâtie sur XMLCosmosbay 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 deses clients. Il s’agissait d’une grande entrerprise du domaine du matériel électrique, dotée d’un grand nombre de systèmes et desources 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 detype 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-officed’e-commerce de type extranet a été envisagé, avec l’objectif pour notre client de se poser comme fournisseur privilégié de sespartenaires.

L’architecture qui a été retenue ne repose pas sur un message broker utilisant un MOM mais sur un serveur d’applications utilisantHTTP comme middleware. Plusieurs raisons président à ce choix :

4 3


• 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 dedonné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.

Il s’agit clairement d’une architecture à trois niveaux (3-tiers) avec une problématique d’intégration. Nous allons nous arrêter endé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

4 4


GRCREFERENTIEL

ERP

DEVTSPECIF

WORKFLOW

CONNECTEUR

CONNECTEUR

XML/HTTP

(SSL)

CONNECTEUR

Clients

Produits

Données Métier Présentation

Acteurs

Composantmétier

Serveur de transactions Journal

Composantmétier

XML

XML

XML

Composantmétier

XML

XML

XML XML/

HTTP Serveurde

Présentation

FRONTOFFICE

Pages actives

ApplicationsCLIENTES

FRONTOFFICE

e-Commerce

EXTRANET/

INTRANET

W

E

B

Figure 11 – Architecture EAI retenue

Serveurde

Présentation

FRONTOFFICE

Pages actives

ApplicationsCLIENTES

FRONTOFFICE

e-Commerce

EXTRANET/

INTRANET

W

E

B

Figure 12 – Front-office

La partie serveur front-office (à gauche) et les applications clientes (à droite) communiquent via Internet et HTTP ; il s’agit d’uneconfiguration désormais traditionnelle : HTTP y tient la place qu’il occupe au sein de millions de serveurs d’applications de par lemonde.

Dans une logique d’intégration, le front-office Internet est une application comme les autres, au même titre que SAP ou que leprogiciel de gestion de la relation client. Si elle figure à part dans notre schéma d’architecture, c’est parce qu’elle représente l’objectifdans 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éesOn retrouve l’ensemble des sources de données de l’entreprise : le progiciel de gestion de la relation client, l’ERP et le développementspécifique.

Ces applications sont exécutées soit sur des plates-formes Windows NT, soit sur des plates-formes Sun Solaris. Un serveur HTTPet un serveur d’applications ont été placés sur chaque plate-forme : IIS sur la plate-forme Microsoft et le couple Apache/JServ surla plate-forme Unix.

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. Cecomposant 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 XMLest ensuite envoyé au connecteur branché sur l’application destinataire, qui transforme ce format XML en format natif (via une feuillede 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 dumarché qui savent dupliquer et distribuer le référentiel central vers des serveurs distants, comme Roma, de Candle, ou e*Gate, deSTC.

Le connecteur SAP, fourni en standard, est une solution packagée nommée Business Connector qui code sa propre logique detransformation ; 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. Cescomposants peuvent facilement être distribués sur différentes machines en vue de gérer un autre aspect important : la montée encharge.

4 5


GRCREFERENTIEL

ERP

DEVTSPECIF

CONNECTEUR

CONNECTEUR

CONNECTEUR

XML

XML

XML

Figure 13 – Sources de données

4 6


Moteur d’intégrationSi l’architecture des connecteurs est distribuée et possède l’intelligence de transformation, il n’en reste pas moins que nous avonsbesoin d’un moteur d’intégration pour orchestrer les échanges entre les différentes applications.

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 descomposants 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éspar JServer. Ces composants alertent le moteur Oracle Workflow du début de la transaction. Le moteur de workflow se charge alorsde piloter la transaction, en répercutant les messages XML dans les applications qui ont besoin de ces données pour poursuivre leprocessus 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 synchronisationToutes les données nécessaires au fonctionnement du front-office et déjà présentes dans le système d’information sont dupliquéesdans Oracle 8i ; l’application de front-office fonctionne avec les données qui sont contenues dans ce référentiel, mais jamaisdirectement 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 contraintesinhé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, maisaussi 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 sontnormalement 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. Lefront-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îtdonc important de synchroniser au plus tôt les données entre les sources, d’où la nature synchrone des échanges et l’utilisation d’unmiddleware adapté à ce besoin. L’emploi de HTTP nous permet d’utiliser un middleware unique employant un format de messagesmé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.

WORKFLOW

Clients

Produits

Acteurs

Composantmétier

Serveur de transactions Journal

Composantmétier

XML

XML

XML

Composantmétier

Figure 14 – Moteur d’intégration

Le moteur de workflow se trouve aussi investi d’un nouveau rôle. Il ne travaille plus seulement à son niveau d’abstraction habituelde surveillance de l’exécution des processus courants ; il opère aussi sur une couche plus basse en contrôlant le déroulement desopérations de synchronisation et leur séquencement. Lorsqu’une opération de synchronisation ne peut être menée à terme, il estcapable de la reprendre ou de notifier l’incident à l’administrateur. Celui-ci peut alors effectuer l’opération manuellement eninterprétant lui-même le message, tâche facilitée si l’opération prend la forme d’un message XML.

4 7


4 8

E A I D e l ’ i n t é g r a t i o n à l ’ e - b u s i n e s s / 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

Panorama du marché de l’EAI

Quelques chiffresIBM, le leader, détient 20 % des parts de marché. Les acteurs suivants sont Neon, Mercator, Tibco et webMethods, tous quatreautour 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 etune 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égrationdivers :

• 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 grandeimportance.

TendancesUne tendance marquée de ce domaine est la consolidation du marché. La notion d’intégration s’étant considérablement élargie cesderniers temps, l’enrichissement rapide d’une offre s’effectue par croissance externe plutôt que par de nouveaux développementstechniques.

Les acquisitions récentes d’Active Software par webMethods et d’OnDisplay par Vignette illustrent ces mouvements. Level 8 aconstruit la dernière version de son offre en rachetant XIPC, Seers et Template Software. Par le passé, Neon Software a acquis VIESystem, 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. Leclient veut en effet des solutions end-to-end. Le rapprochement des acteurs leur permet de répondre plus rapidement aux attentesdes clients, de maintenir les supports techniques existants et, temporairement, les versions de produits. D’autre part, la constitutiond’acteurs de taille plus importante garantit plus sûrement leur pérennité.

5C H A P I T R E

Marché de l’EAI et offres des éditeurs

Il est fort probable que ce mouvement général d’alliances, de partenariats et d’acquisitions va se poursuivre. Cette situation permetaux é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 à Microsoftet collabore toujours avec IBM pour le développement de MQIntegrator. D’une manière générale, les partenariats sont nombreux, ycompris entre les acteurs de l’eAI, qui travaillent à faire communiquer leurs plates-formes entre elles.

Les offresPour 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 solutionsdes 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 ActiveWorksB2B 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 à nosquestions ; nous intégrerons probablement leur offre dans une prochaine version de ce livre blanc. Nous avons exclu les éditeursnon représentés en France pour des raisons difficultés de relations clients dans les phases de conseil, de formation et de supportau produit. Nous avons néanmoins tenu à citer ces acteurs pour information, et nous vous invitons à aller à la rencontre de leurssolutions 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

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 produitsLa 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çaiset du contact. Quelques chiffres ainsi qu’un historique sont fournis.

4 9

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

5 0


Le produit d’intégration est ensuite présenté, dans ses grandes lignes d’abord, puis brique par brique en respectant le modèle EAIque nous avons présenté. Une offre d’EAI est un package riche qui comprend différents outils aux fonctionnalités bien distinctes etaux 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 :

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 à desdé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 lesconnexions possibles à un moniteur transactionnel.

Administration Outils disponibles pour administrer et superviser la plate-forme d’EAI, lesconnexions avec des agents réseaux SNMP (Simple Network Management Protocol).

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 disposantde 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 facilementcette distribution pour optimiser le fonctionnement.

Formation Type et durée des cursus de formation prévus par l’éditeur.

B2B

Processus


Composants

Données

Transport

Roma Workflow Access

Roma Broker

Application Environment Connectors

MQSeries / MSMQ

Figure 15 - Modèle EAI de Candle

CandleSiè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 ([email protected]).

http://www.candle.com

Présentation de la société

CréationCréée en 1976 par Aubrey Chernick.

Répartition des équipes pour les clients françaisCandle est implanté en France depuis 1986 et compte 50 collaborateurs, dont une quinzaine de consultants.

Références450 clients. Beaucoup de références dans la banque et dans la finance en raison de la multiplication des fusions et des acquisitions.

HistoriqueCandle est surtout connu dans le monde du mainframe IBM comme éditeur de la suite Omegamon, solution d’aide à l’optimisationde 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 commecritè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 latechnologie Roma. Le produit est aujourd’hui essentiellement axé sur une logique d’EAI interne. L’architecture se présente sousforme d’une business services platform : elle interconnecte des « composants » (les applications) fournissant des services.

Sa force principale réside dans son ouverture à un ensemble de standards du marché. Des API permettent de faire de Roma uneplate-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.

5 1


5 2


Le modèle EAI de Candle

B2BLa localisation géographique des applications étant transparente (celles-ci sont déclarées dans un annuaire), il est possible de seconnecter à des applications distantes chez des partenaires.

Roma F/S Access assure une connexion au réseau financier Swift.

Processus : Roma Workflow AccessAvec Roma Broker, définition de BSP (Business Services Processes) pour suivre un ensemble de fonctions. Roma est capable des’interfacer avec les moteurs de workflow MQWorkflow d’IBM et Staffware.

Moteur d’intégration : Roma BrokerRoma 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,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 lamontée en charge, du suivi des performances et de la remontée des erreurs. L’ensemble est accessible depuis une interfacegraphique.

CandleNet Broker Access assure la connectivité au message broker MQIntegrator, de Neon et IBM, et à celui de Mercator.

Données : Application Environment ConnectorsLes 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 ;

B2B

Processus


Composants

Données

Transport

Roma Workflow Access

Roma Broker

Application Environment Connectors

MQSeries / MSMQ

Figure 16 - Modèle EAI de Candle

• 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’enrichissementde son offre de connecteurs « prépackagés ».

Transport : MSMQ et MQSeriesRoma supporte MQSeries et MSMQ et fournit également l’autobridge, une passerelle entre les deux MQ.

5 3


5 4


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 endynamique, 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’unetransaction 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) : cequi est déjà coordonné le reste, on se repose sur les architectures existantes.

Administration CandleNet Application Manager fournit à l’utilisateur une interface graphique centralisanttous 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érentielRoma Directory.

Sécurité Fourniture d’une offre de sécurisation MQSeries. Cryptage, authentification, certification128 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 viceversa. C’est un data mapper qui définit les formats de conversion. Un parseur intégré valideles documents au regard de DTD. Cette composante de Roma ne nécessite pas de passer parun message broker.

Ouverture À noter : la possibilité de s’interfacer avec d’autres message brokers, voire à utiliser commemessage 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 deconfiguration 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 deMOM utilisé, procédures d’audit, de suivi, etc.). Développement de connecteurs par le clientou 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 lesmachines distantes.

Les files d’attente sont réparties. On peut demander au produit de générer automatiquementdes files ou de s’appuyer sur la configuration de files déjà existantes, mais on ne prend pasen 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 desapplications MQ.

Constellar

Siège social Bureaux français

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 ([email protected]).

http://www.constellar.com


CréationCréée en 1995 par Brian Donnelly.

Répartition des équipes pour les clients françaisLa filiale française s’est installée en janvier 1999. Elle compte aujourd’hui 3 collaborateurs : un collaborateur s’occupe de la partiecommerciale, un autre de l’avant-vente technique et un troisième du conseil. Le support technique est disponible 24 heures sur 24et 7 jours sur 7.

RéférencesPlus de 100 clients aux États-Unis et en Europe, dont environ 80 en production.

Présentation du produitConstellar 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 dessources de données et sur une planification fine des tâches. L’accent est mis sur la robustesse du produit, sur ses aptitudes à lamonté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’unmoteur 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.

Constellar Hub incorpore un volet décisionnel – Warehouse Builder – qui permet de définir et de reprendre des schémas de datawarehouses et de data marts, avec agrégation complète ou partielle des sources de données, et de les poster vers différentssystèmes décisionnels, dont la liste est fournie ci-dessous, dans la description technique du produit.

5 5


5 6


Le modèle EAI de Constellar

B2B : Transformation ManagerProduit natif, pas de connecteur ou de module supplémentaire. Constellar Hub se connecte à distance aux sources de données dupartenaire 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.

ProcessusPas de workflow (voir la section « Présentation du produit »).

Moteur d’intégration : Transformation ManagerTransformation Manager permet de constituer des interfaces (couplage logique n-n entre données sources et cibles), les traitementsde transformation des données et les processus de remontée des erreurs de chacune des phases de l’intégration (le cycle detransformation 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 sourceshétérogènes peuvent ainsi être jointes (par jointure relationnelle) et il devient possible, en s’appuyant sur les capacités nativesd’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 leserreurs 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.

B2B Transformation Manager

Processus


Composants

Données

Transport

Transformation Manager

Packages Oracle

Metadata Manager + Adapters

Figure 17 - Modèle EAI de Constellar

Un scheduler (outil de planification) permet ensuite de déterminer les lancements des tâches définies. Il a une partie cliente sousWindows 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èglesmétier). En production, seul Transformation Manager est utilisé quotidiennement.

Composants : packages OracleInterfaç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 + AdaptersMetadata Manager permet de consulter les catalogues de bases de données ou les repositories des progiciels. Les connecteursexistants 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 etIntellicorp (partenaires technologiques de SAP) sur leur produit LiveInterface gère l’intégration technique et fonctionnelle, avecgestion 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 desservices 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, lesunivers BO, OLAP (Express, Essbase, Powerplay) et ROLAP (Microstrategy).

TransportPas de middleware propriétaire : le résultat est envoyé directement à la cible par le protocole natif de celle-ci. D’autre part, un shellFTP permet de faire communiquer des plates-formes hétérogènes.

5 7


5 8


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 desphases ; 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 lamê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 commeun 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’autresdé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, puisenfin 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. LeGetMetadata 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èglesde gestion communes à toutes les configurations sont répliquées sur chaque réfé-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 formationpeut 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

Présentation de la sociétéCréation

Créée en 1994 par Samuel Somech, architecte de MQSeries, qui a également participé à la conception de MSMQ, et Arik Kilman. EnBourse depuis 1996.

Répartition des équipes pour les clients français15 consultants (support technique, développement, formation, études préalables).

RéférencesMerril Lynch, France Telecom, Michelin, SNCF, AMDOCS…

HistoriqueLevel 8 est créé en 1994 et ses activités couvrent alors principalement la prestation de services autour de MQSeries d’IBM. Début1998, 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 offremature 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.

Architecture technique du produitL’offre de Level 8 s’appelle Geneva Integration Suite. La solution comprend un message broker, Geneva Integration Broker, et unMOM, Geneva MQ. Elle s’articule autour des modules Geneva Enterprise Integrator pour l’intégration des processus métier et GenevaBusiness 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 composantsCOM, Corba ou EJB. Enfin, la plate-forme dispose d’un outil pour construire un référentiel client qui sera utilisé par les applicationsCRM.

5 9


6 0


Le modèle EAI de Level 8

Processus : Business Process AutomatorGeneva 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 desprocessus 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 BrokerLes fonctions d’intégration sont assurées par un message broker, Geneva Integration Broker. Il offre une vue objet des donnéesprovenant 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 lestransformations à 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 lessources de données applicatives. Il permet de construire des passerelles entre les applications web et les autres éléments dusystème d’information via des composants métier Corba, DCOM et EJB. Le modèle objet opérationnel fournit aux applications unaccès synchrone aux sources de données à travers des proxies et le Data Manager (voir la section « Données »), et accèdedirectement 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écutiond’un processus métier.

Composants : Enterprise IntegratorGeneva Enterprise Integrator 2.0 fournit une passerelle entre les applications web et les autres éléments du système d’informationvia des composants métier Corba, DCOM et EJB. Cette couche intermédiaire apporte une touche synchrone au modèle par systèmede 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étragedes transformations de données. Il fournit des fonctions avancées d’analyse.

B2B

Processus


Composants

Données

Transport

Business Process Automator

Integration Broker

Enterprise Integrator

Data Manager

Geneva MQ

Figure 18 - Modèle EAI de Level 8

Données : Data ManagerData 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 auxoutils 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 dela 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 QueuingGeneva Message Queuing assure le transport de données en mode sécurisé, asynchrone, multi-plateforme et compatible MSMQ. Ilexiste 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.

6 1


6 2


Synthèse

Montée en charge La montée en charge est assurée par les possibilités des outils Microsoft et lesupport d’une architecture distribuée. Geneva Integration Broker est« multithreadé » et peut traiter simultanément de nombreux flux. Le loadbalancing combine l’utilisation du repository central avec les règles définiessur le message broker.

Transactions et moniteurs transactionnels Avec Geneva IB Transaction Flow, il est possible de supporter les transactionspour 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 dumiddleware, respectivement à travers un navigateur Web et à travers laconsole de gestion (MMC) de Microsoft. Geneva Explorer permet deconfigurer les adaptateurs, les transformations et le routage.

Tolérance aux pannes Les outils Microsoft fournissent les fonctionnalités de load balancing et dedynamic clustering (Microsoft Transaction Server, Microsoft Cluster Server etSQL Server).

Sécurité RSA et DES.

XML L’utilisation d’XML est possible à tous les niveaux : Geneva Integration Brokersupporte XML en natif et les composants du système d’EAI peuvent dialoguerentre eux en XML. C’est une facilité très appréciable et qui offre une grandesouplesse.

Ouverture Il est possible de communiquer avec des plates-formes non Windowssuivantes : Solaris (sparc et intel), HP-UX, AIX, Unix, Linux, VMS (vax etalpha), OS400 et VMS.

L’approche composant permet d’étendre les fonctionnalités du messagebroker avec des composants COM.

Geneva supporte également SNMP pour pouvoir s’intégrer dans des outils telsque 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étiersont également disponibles pour Unix (Enterprise Integrator, BusinessProcess Automator).

Productivité de développement L’approche objet et le support des outils de développement Microsoft (VisualStudio et COM) font de Geneva Integration Suite une plate-forme efficace pourle 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éationCréé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.

Répartition des équipes pour les clients françaisCréée en 1998, la filiale française compte plus de 10 collaborateurs employés en France, dont un vice-président Europe du Sud, undirecteur 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érencesPlus 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.

HistoriqueMercator 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 secteurfinancier, et Novera, spécialiste de l’intégration des solutions web. Grâce à cette croissance externe et à un fort développementinterne, Mercator est aujourd’hui un des leaders de l’intégration A2A, B2B et C2B (respectivement application-to-application,business-to-business et consumer-to-business).

Présentation du produitLa 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 etdes 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.

6 3


6 4


Le modèle EAI de Mercator

B2B : Mercator Commerce BrokerMercator Commerce Broker représente l’offre complète : A2A, B2B et C2B. Pour le A2A, Mercator Enterprise Broker répond auxbesoins d’intégration d’applications d’entreprise. Pour le B2B, Mercator Commerce Manager inclut la gestion des partenaires et laconfiguration des communications, la gestion des messages en termes de spécification des transactions, de coordination desprocessus 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 EJBrepré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 DesignerL’Integration Flow Designer est l’outil graphique de conception des flux et permet de gérer la configuration via la distribution descomposants 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éclenchementd’événements. Il dispose de fonctionnalités telles que l’attente et la synchronisation d’événements et que la validation des flux entermes de cohérence des sources et des destinations définies. Mercator Event Server fait appel au moteur d’intégration. Une consolede monitoring permet le suivi des processus. Une intégration avec des outils d’entreprise est possible.

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

B2B

Processus


Composants

Données

Transport

Mercator Commerce Broker

Integration Flow Designer

Mercator Integration Server

Mercator Web Broker

Mercator Type Designer + Adapters

Figure 19 - Modèle EAI de Mercator

Composants : Mercator Web BrokerAvec le rachat de Novera, Mercator a enrichi sa gamme avec les produits Mercator Web Broker et Web Integrator, qui sont désormaisintégrés à l’architecture unique Mercator. Ils permettent de concevoir des composants web réutilisables qui répondent aux normesEJB et Corba, puis de les publier et de les enregistrer du côté serveur d’applications Web.

Données : Type Designer + AdaptersType Designer est l’outil graphique de définition des métadonnées. À travers les adaptateurs, le Type Designer permet de seconnecter aux sources de données et d’importer les métadonnées. Le Type Designer sait découvrir les catalogues des bases dedonné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. Lesadaptateurs prennent en charge la capture des erreurs, la journalisation et le reporting. Le développement d’adaptateurs estpossible.

TransportDes MOM du marché sont utilisés pour transporter les données.

6 5


6 6


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 dansMercator Enterprise Development Kit), qui fait appel au moteur d’intégration.Mercator Integration Server peut appeler un service Tuxedo à travers sonadaptateur Tuxedo.

Sur IBM OS/390, une transaction CICS peut appeler le moteur d’intégrationMercator.

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étrageet de tuning de la solution.

Tolérance aux pannes La multiplication des serveurs d’intégration permet de pallier la défection del’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 transformationsd’un format XML en un format non-XML (et vice versa) sont possibles. Lesstandards 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. Lacouche 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 lesplates-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 negénère pas de code.

Déploiement L’outil graphique Information Flow Designer permet de gérer le déploiement etla distribution à partir d’une interface centralisée.

Formation Le support de Mercator aux clients inclut des prestations de conseil et deformation, d’assistance technique au projet d’intégration et une hotlineré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 ([email protected]).

http://www.neonsoft.com

Présentation de la sociétéCréée par Rick Adam (Goldman Sachs) en 1993 ; 1 000 collaborateurs, dont 250 en recherche et développement.

Répartition des équipes pour les clients françaisLes 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érencesPlus de 2 500 références et une forte politique de partenariat : SAP, PeopleSoft, Microsoft, IBM, Oracle, Sun Microsystems,BroadVision, Commerce One…

Architecture technique du produite-Biz Integrator a demandé 2 à 3 ans de mise en œuvre. Neon a déposé trois algorithmes sur des technologies achetées depuis parIBM, 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 ;

• 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 estréduit par rapport à e-Biz Integrator mais s’appuie sur les capacités de l’architecture Microsoft et adopte un mode de configurationgraphique très convivial et intégré pour l’outil de monitoring.

6 7


6 8


Le modèle EAI de Neon

B2BNeon ne propose pas de plate-forme B2B à proprement parler, mais un ensemble d’adaptateurs applicatifs dédiés à des applicationsB2B ou B2C : adaptateurs XML, EDI et Web fournis en standard avec e-Biz Integrator, adaptateurs Acord, HL7, Swift et CommerceOne.

Processus : Enterprise ProcessExecutiveNeon Enterprise ProcessExecutive (EPE) permet de définir, de gérer et de surveiller les processus métier qui impliquent plusieursapplications (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, diversdaemons, le Rulesengine d’e-Biz Integrator…) sont souvent démarrés par un scheduler (outil de planification) du marché (ou par lecrontab sous Unix).

Moteur d’intégration : NEONRules et NEONFormatterNEONRules et NEONFormatter sont des constituants d’e-Biz Integrator ; ils remplissent les fonctionnalités suivantes :

• NEONRules est le moteur de routage. Son algorithme breveté est spécialement conçu pour monter en charge avec le nombrede règles. Les règles sont orientées « contenu » car une granularité très fine est requise. Les règles de routage sont définiespar 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 messagesentrants. 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 derépétition imbriqués, etc.). NEONFormatter est l’outil qui valide les données des messages entrants, puis transforme et enrichitleur contenu.

B2B

Processus


Composants

Données

Transport

Enterprise Process Executive

Neon Rules / Neon Formatter

Adapters

EMQ, MQSeries

Figure 20 - Modèle EAI de Neon

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 mappingstatique 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é dansune 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’enrichissementsont 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 champsdans 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 desmé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 ettraite l’archivage et la recherche des messages. Il détermine l’état transactionnel des messages : en cours, échoué ou achevé, puisles 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 moyend’une interface utilisateur graphique. L’outil Crystal Report, livré en standard, permet de générer des rapports complets.

Données : AdaptersTous les adaptateurs Neon sont bidirectionnels et peuvent être employés d’une manière distribuée. Ils récupèrent les formats desdonnées des applications et les insèrent dans le référentiel NEONRules & Format. Par exemple, l’adaptateur NEONadapter for SAPest 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èsdirect à 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 exempleentre Commerce One et SAP).

Transport : EMQ, MQSeriesLe middleware maison est Neon EMQ, mais e-Biz Integrator s’appuie également sur MQSeries, d’IBM.

6 9


7 0


Synthèse

Montée en charge Une instance converse directement avec une application. Le load balancing estgéré par la duplication des instances sur une même machine ou sur desmachines différentes. L’algorithme de NEONRules prévoit la montée en chargeau 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 lagestion transactionnelle de MQSeries : transaction par propagation. Il existeNeon CICS sur mainframe IBM.

Administration Les trois applications NEONRules, NEONFormatter et NEONTrack procurentl’ensemble des fonctionnalités d’administration souhaitées via une interfacegraphique.

Tolérance aux pannes Distribution des instances.

Sécurité Le moteur de règles et de formats peut appeler une routine externe pourdé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çonexterne. De plus, le référentiel peut être abrité par les différentes bases dedonnées des grands éditeurs du marché.

Appel de routines externes en C++ pour intégrer des composants métierexternes à 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 codegé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 estparamé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, formationspécifique très courte sur les adaptateurs. Couvre 70 % des fonctionnalités duproduit.

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 ([email protected]).

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.

Répartition des équipes pour les clients françaisLes é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érencesQuelque 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’estinversé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.

Architecture technique du produitLa 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é,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 permetnotamment 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 architectureeAI avec l’adjonction récente de nouveaux modules et s’ouvre aujourd’hui à l’échange interentreprise, renommé en eBI (e-businessIntegration) 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).

7 1


7 2


Le modèle EAI de STC e*Gate 4

B2B : e*Xchange IntegratorASC X.12, Edifact, BizTalk et RosettaNet sont pris en compte. En ce qui concerne ce dernier, l’ensemble des processus et destransactions 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écutionet 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 ManagerL’eBusiness Process Manager permet aux consultants métier et aux utilisateurs finaux de réaliser la modélisation graphique desBusiness 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étiersont de nouveau générés.

Ce module gère également les processus métier B2B.

Moteur d’intégration : Collaboration et TopologieUne Collaboration détermine la gestion technique des processus métier définis dans l’eBusiness Process Manager. Ce module définitla structure des échanges entre les différentes étapes d’un processus, ainsi que le schéma de transformation d’un message en unautre. Le routage des messages, les notifications et l’invocation d’API externes sont également implémentables. Concrètement, uneCollaboration 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 etpermet de gérer la distribution et la configuration de la solution (optimisation à des fins de montée en charge).

B2B

Processus


Composants

Données

Transport

E*Xchange Integrator

Business Process Manager

Collaboration / Topologie

Business Object Broker (BOB)

e*Ways / Communication Client

Intelligent Queues

Figure 21 - Modèle EAI de STC e*Gate 4

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 ProcessManager. Le BOB peut être vu comme un connecteur applicatif (e*Way) interne, destiné à ne communiquer qu’avec les files d’attentedu 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 endroitsphysiques du réseau afin, par exemple, de paralléliser les traitements. Ces composants métier peuvent communiquer entre eux etles tâches peuvent donc être sérialisées. Enfin, le BOB – comme tous les autres service de la solution – dispose localement desinformations du référentiel le concernant, d’où une certaine autonomie et une tolérance aux pannes.

Adaptateurs : e*WaysLes e*Ways (connecteurs) sont des composants de communication intelligents présentés sous forme packagée pour permettre uneconnexion 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 55e*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éeest de représenter graphiquement la structure des tables ou des vues relationnelles sous forme d’arbres, puis de les remplirpar 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 teldéveloppement peut varier d’une demi-journée à 10 jours en fonction de la complexité de l’application à intégrer. STC peut ensuitejuger intéressant d’industrialiser ce développement en créant un e*Way : développement d’une interface utilisateur, rédaction d’unedocumentation et mise en place d’un support technique.

7 3


7 4


Transport : Intelligent QueuesLa 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étierviennent enrichir les services fournis par ces Intelligent Queues.

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 lestraitements 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 parle développement d’un connecteur spécifique ou par l’exploitation d’unee*Way existante.

Administration La solution dispose d’outils de suivi qui permettent de mettre en évidence desgoulets d’étranglement et des tendances générales d’utilisation des processusafin d’entreprendre une politique de duplication et de distribution optimale.e*Gate Monitor est une console de surveillance et e*Gate Alert Agent ungestionnaire d’alertes.

Tolérance aux pannes La possibilité de dupliquer les composants lors de leur distribution permet defaire face à des incidents tels qu’une rupture de connexion réseau. De plus, lesBOB peuvent répliquer en local la partie du référentiel concernant leurfonctionnement (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érentesstructures de message, pour lequel STC fournit le XML DTD Converter. Maisaussi : librairies de structures RosettaNet et BizTalk.

Ouverture « e*Gate architecture is net-centric, not platform centric. » Les e*Ways, lesBOB 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 ouHP 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étieret technique ainsi que le déploiement physique s’opèrent à l’aide des interfacesgraphiques de l’eBusiness Process Manager et de Collaboration, modulescommunicants et centralisés sur le référentiel unique.

Déploiement Facilement réalisable par le biais de l’interface graphique. La phase dedéploiement est ainsi déconnectée de la phase de conception métier et de laphase de développement. Les IQ sont en mode publish and subscribedynamique.La granularité du déploiement est très fine car on distribue des composantsmé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 dusystème d’information via la plate-forme d’EAI.

Formation Deux cursus de formation de 3 jours chacun : e*Gate Basic et e*GateAdvanced. STC propose également un ensemble de cours spécifiques auxe*Ways, à e*Xchange, à l’Alert Agent, à l’e*Index, etc.

Les équipes deviendront ensuite rapidement autonomes et seront en mesured’intégrer de nouvelles applications.

7 5


7 6


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.

Répartition des équipes pour les clients françaisFiliale française depuis 3 ans, 20 collaborateurs (vente et conseil) ; 38 bureaux dans le monde entier.

RéférencesSecteur 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-Uniet en Europe centrale. Quelques références : Nasdaq, Ericsson, Telecom Italia, Hitachi, Pirelli, Adidas, Delta Airlines, Philips MedicalSystems, Yahoo!, EDF Trading, GDF Trading.

HistoriqueEn 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étiersseront 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é PragamaticalGeneric 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.

Tibco Software a acquis en juillet 2000 la société Extensibility, spécialisée dans le développement d’outils de modélisation et dedéveloppement XML.

Architecture technique du produitLongtemps 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 troisbriques 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 Softwarea 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 : ActiveExchangeLa gamme de produits ActiveExchange est conçue pour l’implémentation d’e-marketplaces horizontales (comme mySAP, de SAP) etverticales, 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 leurexécution et un système de gestion des partenaires. TIB/BusinessPartner peut être distribué à des partenaires ne disposant pasd’outil B2B dédié afin qu’ils puissent se connecter à une plate-forme TIB/BusinessConnect ou à toute autre plate-forme supportéepar les adaptateurs. L’outil différencie les processus publics (B2B) et les processus privés (d’entreprise). TIB/BusinessExpresspermet à 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 avecTIB/Rendezvous ou sur HTTP, FTP et SMTP. Une connectivité EDI est possible.

Processus : TIB/InConcert et TIB/IntegrationManagerRacheté en 1999, TIB/InConcert a 10 ans et plus de 700 références : il s’agit donc d’un produit mature. Une interface graphiquepermet de modéliser et de prototyper les processus mettant en œuvre des interactions humaines, et il est possible de suivre ledéroulement des processus en temps réel.

Soulignons d’une part l’existence de processus métier types, fournis en standard et qui permettent de prototyper rapidement unesolution, et d’autre part la possibilité de concevoir des modèles de processus. TIB/InConcert autorise la modification dynamique d’unprocessus lors de son déroulement.

TIB/IntegrationManager est un outil d’automatisation de processus. Il sert à modéliser et à coordonner des transactions courtes etlongues sur des applications intégrées par TIB/Rendezvous, Corba et EJB, et d’automatiser les processus B2B. L’écriture de lignesde 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 égalementproposés.

Les processus métier sont décrits au format XML. Ils peuvent ainsi être partagés entre entreprises (via un client Extensibility, parexemple) dans des procédures type groupware pour élaborer les processus finaux qui auront l’agrément de chaque partenaireintervenant dans l’échange.

7 7


B2B

Processus


Composants

Données

Transport

TIBCO ActiveExchange

TIB/InConcertTIB/Integration Manager

TIB/Message Broker

TIB/Adapters

TIB/Rendez-vous

Figure 22 - Modèle EAI de Tibco

7 8


Moteur d’intégration : TIB/MessageBroker – monitoring : TIB/HawkTIB/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 extraitesdu 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égrationmanifesté par le système d’information, il peut être plus judicieux de conecter un petit message broker sur les adaptateursapplicatifs, à 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 lessurveiller. 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 à desconsoles 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 à unpic de charge. La technologie est complètement distribuée.

Données : TIB/AdaptersLes 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’énergieet 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 dedéveloppement ou solliciter des partenaires pour des adaptateurs spécifiques.

Transport : TIB/RendezvousTIB/Rendezvous est en version 6 et a derrière lui 15 ans d’expérience. TIB/Rendezvous est un MOM supportant des modèles decommunication multiples tels que le publish and subscribe, le request-reply ou le broadcast request-reply, ainsi que des niveaux dequalité de service différents comme le broadcast fiable (reliable broadcast), le multicast fiable (reliable multicast), la délivrance demessages 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 etcomprend 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 multiplientpour 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 demultiples opérations comme une seule unité d’œuvre.

Administration La plate-forme est intégralement administrable par des outils graphiques, quisurveillent à 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 deTIB/Rendezvous peut être fondée sur un formulaire HTML.

Tolérance aux pannes TIB/IntegrationManager, TIB/Hawk et TIB/Rendezvous (API) permettent unredémarrage immédiat suite à des erreurs inattendues, ainsi que la distributionde 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 documentencrypté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 documentsd’échange B2B en XML sur HTTP sont « parsés » à l’entrée et à la sortie pourvalidation et transformés si nécessaire.

Ouverture TIB/InConcert, le moteur de workflow, s’interface facilement avec lescomposants COM et Java et inclut un support LDAP pour Netscape DirectoryServer 3.0 et supérieur. TIB/Hawk fournit une passerelle SNMP.

Portabilité L’interface graphique de TIB/MessageBroker et TIB/BusinessConnect sontentièrement développés en Java. TIB/Rendezvous est disponible pourWindows, 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étieret la partie technique sans développement.

Déploiement L’architecture de TIB/Rendezvous est totalement distribuée.

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 à TibcoActiveEnterprise, concepts de TIB/Rendezvous, installation et administrationde 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/InConcertet à TIB/IntegrationManager).

7 9


8 0


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éationLa société suédoise Frontec, créée en 1981 par Greg Cronin, compte 300 collaborateurs de par le monde. Ses métiers sont le conseiltechnique et organisationnel. Viewlocity est un spin-off du département AMT de Frontec.

Répartition des équipes pour les clients françaisLa filiale française est créée en 1997. Dix collaborateurs en France (4 profils techniques, 4 commerciaux, 2 administratifs).

RéférencesQuelque 3 500 sites dans le monde (40 clients) dont 180 sites équipés en France.

HistoriqueBatteries Venture a investi 10 millions de dollar dans le département AMT pour créer et développer Viewlocity.

Architecture technique du produitLe produit phare est AMTRix : il est riche de fonctionnalités en infrastructure et doté d’un message broker. Mais plus l’outil estouvert, 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 dusystème d’information de s’appuyer sur de l’e-commerce.

Ainsi, pour Volvo, le volume des échanges est de 60 millions de messages par mois, avec, pour les messages de synchronisationde chaînes de production, une contrainte de temps de traitement de bout en bout, intégrant l’acquis applicatif, d’un dixième deseconde.

Le modèle EAI de Viewlocity

B2B : AMTrixAMTrix 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 connecteurXML permet d’implémenter les PIP RosettaNet des applications de gestion logistique.

Processus : Business Process ManagerBusiness 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À travers l’AGL associé à AMTrix, composé du Metadata Browser et de Datamapper, AMTrix permet de mettre en œuvre l’accès auxdonné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 permetd’effectuer – à l’aide du L4G semi-compilé et portable de la plate-forme AMTrix, Message Builder – des opérations de routagecomplexe 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 mettreen œ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.

8 1


B2B

Processus


Composants

Données

Transport

AMTrix

Business Process Manager

Data Mapper & Monitor

Connecteurs

Figure 23 - Modèle EAI de Viewlocity

8 2


DonnéesLes 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 uneproblé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 moniteurstransactionnels. Ceci n’est cependant pas une offre standard à ce jour.

Administration À travers son poste client de supervision, Monitor, AMTrix permet deparamé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 telsque 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. Touttype de DTD est lu, ainsi que XDR. Metadata Browser sait lire ces documentset en permet le mapping et le routage.

Ouverture Interfaçage sur des outils comme HP MC Service Guard pour la tolérance auxpannes. Mise en œuvre de dispositifs d’alerte par remontée SNMP ou auniveau métier à travers les connecteurs de messagerie, SMS et fax.

Portabilité Disponible sur les plates-formes Unix, Windows NT et AS/400. AMTrix utiliseMessage 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 dequelques jours.

Formation La première base de formation dure 5 jours et permet d’acquérir les conceptsde base de l’exploitation d’AMTrix et de l’emploie de Datamapper.

Des cycles complémentaires sont prévus afin d’approfondir les fonctionnalitésde Datamapper et de Message Builder, son langage associé, aussi bien que lamise en œuvre de services de communications complexes tels que X.400.

Vignette-OnDisplayOnDisplay


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

Présentation de la sociétéCréation

Créée en 1996 par Mark Pine (ex-directeur exécutif de Sybase) et Trung Yung (directeur technique d’OpenMarket), OnDisplayemploie actuellement 400 collaborateurs.

Répartition des équipes pour les clients françaisDepuis décembre 1999, OnDisplay s’est installée à Vitrolles pour couvrir le marché de l’Europe du Sud. L’agence compte 5 collabo-rateurs.

RéférencesCommerce & Distribution (Shopping.com), Voyage & Tourisme (Sabre, Travelocity). Positionnement fort en dot-com sur lesmarchés nord-américains. La grosse poussée actuelle est dans le B2B pour aller sur des marchés de brick and mortar. Deux centsréférences.

HistoriqueLa partie EAI vient d’Oberon, société acquise par OnDisplay en décembre 1999.

Architecture technique du produitLa stratégie d’éditeur d’outils d’infrastructure logicielle pour les portails et les places de marché d’OnDisplay couvre la mise en placede 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 encommun, il était plus logique de converger que d’évoluer vers une situation de concurrence.

8 3


8 4


Leur gamme de produit s’appelle CenterStage. L’offre est composée de briques distinctes formant un tout unifié et cohérent maisdont 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 – eBizXchangeeBizXchange XML Server effectue la transformation et l’agrégation des formats XML, EDI, texte structuré, ODBC et JDBC afin degérer des transactions avec d’autres sites. Des agents vont aller chercher des informations sur un site et éventuellement procéderaux transactions et aux transformations nécessaires selon les règles établies. Ces agents sont créés avec l’Agent Builder. Troismoteurs 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à 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 modesécurisé avec accusés de réception.

ProcessusPas de moteur de workflow à proprement parler mais une possibilité de définir des processus, via la modélisation graphique de lienset d’enchaînements, entre les Building Blocks modélisés dans eIntegrate.

Moteur d’intégration : eIntegrateUn outil permet de définir les Building Blocks, éléments de base qui spécifient chacun une étape dans un processus et le travail detransformation à 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 degestion de version, etc. Les tests sont facilités par le débogage avancé, graphique et éventuellement à distance. La compatibilité avecSNMP 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 aussidéployer des archives Java CAB, des objets COM client ou serveur, ActiveX, des servlets Java, etc. L’environnement de déploiementest CenterStage, un serveur d’applications indépendant d’OnDisplay (serveur EJB, Sun Java 2, etc.).

B2B

Processus


Composants

Données

Transport

XML Connect - eBizExchange

eIntegrate

eIntegrate

Building Blocks

Figure 24 - Modèle EAI de Vignette - OnDisplay

Données : Building BlocksLà 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 deBuilding 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 EDIou d’un fichier HTML (en ligne ou non). Les transformations se font visuellement, par glisser-déposer de la source vers ladestination. Ces agents sont la base de la plupart des applications de la ligne CenterStage. Le Building Block paramétré est ensuiteré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 cevolet 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 routageconditionnels.

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 nouveauprocessus.

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 technologieXML.

Ouverture Grande ouverture de la solution avec des possibilités de déploiements dansdes 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 deproduction existe pour NT et pour Unix AIX, HP-UX et Solaris. Il existe uneversion Linux d’eIntegrate.

Productivité de développement Grâce aux interfaces graphiques, il est très facile de recréer un agent en cas demodification d’une source de données. Le système de développement tournesous 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.

8 5


8 6


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 parwebMethods apporte une solution B2B reconnue et crée une plate-forme complète couvrant toutes les couches du modèle EAI sousl’« enseigne » unique de webMethods.

Présentation

CréationCréée en 1996. Implantation internationale. Plus de 750 collaborateurs. Une équipe de Recherche et Développement de 220 collabo-rateurs.

Répartition des équipes pour les clients françaisUne dizaine de collaborateurs en France, répartis entre commerciaux, consultants avant-vente et consultants techniques.

RéférencesPrès de 500 clients pour webMethods, plus de 300 références pour Active Software.

HistoriqueTravaillant 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é parl’OMG, ce qui les conduit à développer un prototype pour concrétiser leur vision. Celui-ci est financé par le Java Funds, fondsd’investissement de la Silicon Valley auquel participent IBM, Oracle, Sun Microsystems, KPMG, etc. Ce prototype est la premièreversion 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érienceautour des e-marketplaces, organisées autour de la solution webMethods B2B Server, comme celles de Dell (25 000 acheteurs) etd’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 auformat 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 entrepartenaires) et B2B.com, un portail dédié aux échanges B2B, à partir duquel une entreprise est en mesure d’inclure rapidement unpartenaire 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’ unréférentiel et d’un environnement de développement communs.

Le modèle EAI de webMethods

B2B : WebMethods B2B ServerwebMethods 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 viawebMethods 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 certificatsdigitaux 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 enmode publish and subscribe. La modélisation des processus est autonome grâce au B2B Pipeline Editor.

Processus : Visual Integrator et Integration ProcessL’utilisateur définit un ensemble d’Integration Components, qui sont autant d’actions élémentaires sur des données (création d’unclient, par exemple). Ces Integration Components sont ensuite liés entre eux pour former une chaîne logique d’actions, appeléeIntegration 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 etles laisser piloter le système.

8 7


B2B

Processus


Composants

Données

Transport

WebMehods B2B Server

Visual Integrator / Integration Process

Information Broker

Agents / Designer

Intelligent Adapters

Information Brokerw

ebM

etho

ds E

nter

pris

e

Figure 25 - Modèle EAI de webMethods

8 8


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

Composants : Agents et DesignerLes Agents sont des programmes spécifiques et propriétaires offrant des possibilités de développement diverses (portions de codespé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 AdaptersActive 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 lescatalogues 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 BrokerInformation Broker gère ses propres files d’attente en utilisant en mode publish and subscribe et reply-request.

Synthèse

Montée en charge La montée en charge se traite de façon traditionnelle, en deux points : d’unepart 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 sanscompliquer l’administration : les brokers sont logiquement liés entre eux, ettoute modification du broker principal est répercutée sur les brokers liés.

Tout service B2B de webMethods B2B est « multithreadé », limitant la chargemachine.

Transactions et moniteurs transactionnels La multiplication des brokers de part et d’autre d’un point réseau sensible peutpermettre au système de continuer à fonctionner même en cas de ruptureréseau.

Application Transaction Coordinator permet de définir graphiquement destransactions longues avec conservation du contexte dans des bases dedonnées Oracle ou Microsoft et rollbacks globaux sur l’ensemble de chaquetransaction. Active Integration Monitor affiche le contenu des transactions etpermet de les reprendre dans l’état dans lequel elles étaient lors de leurinterruption.

Administration Les outils disponibles pour administrer et superviser la plate-forme d’EAI, lesconnexions avec des agents réseaux SNMP (Simple Network ManagementProtocol).

Tolérance aux pannes Les Information Brokers et les Intelligent Adapters peuvent être placés enclusters.

Sécurité Signature digitale pour les enveloppes de messages, certificats digitaux à basede clé, cryptage SSL géré au niveau des connecteurs applicatifs. InformationBroker peut rejeter toute production d’événement non autorisé provenant d’unDynamic Adapter (Client Grouping).

ActiveWorks garantit la délivrance des messages au destinataire.

XML La communication B2B est essentiellement XML. La communication B2B estessentiellement XML.

XML est aussi un des formats pris en charge par les Intelligent Adapters. LeData 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 deworkflow externes. Les Agents peuvent s’interfacer avec des composantsexternes.

WebMethods B2B Server est ouvert à LDAP et à NIS (Network InformationService).

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 interfacegraphique conviviale qui permet un paramétrage fin en limitant la productionde lignes de code. Certains éléments, comme Integration Components, sontréutilisables au travers de plusieurs Integration Processes.

Le module optionnel Designer est intéressant mais nécessite des applicationsexternes (Visio Professionnel 5.0).

Déploiement Rapidité de déploiement de la solution d’intégration et capacité à modifierfacilement cette distribution pour optimiser le fonctionnement.

Formation Cursus de formation de 4 à 5 jours, en France et en français.

8 9


E A I D e l ’ i n t é g r a t i o n à l ’ e - b u s i n e s s / C o n c l u s i o n

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 vontiné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 desfonctionnalités apportées par une plate-forme éditeur offre un compromis qui concilie la robustesse de ces outils avec les besoinsde « 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 etd’être ensuite en mesure de s’insérer efficacement à une chaîne d’échange interentreprises. Comme les plates-formes d’EAI dumarché sont aujourd’hui des offres matures et fiables, on peut donc investir sans risque. Les bénéfices sont immédiats, entraînantun 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 destechnologies en cours de maturation et le besoin d’implémenter une solution d’e-business, outil désormais indispensable en matièred’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 langagesstables, 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 leB2B : « Nous avons compris que l’Internet changerait radicalement les modes de distribution et qu’il fallait s’employer à en fairenotre 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 mined’informations.

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.

5C H A P I T R E

Conclusion

9 0

C o n t a c t

PARIS10, rue du Faubourg Poissonnière75010 ParisTél : +33 1 53 24 67 80Fax : +33 1 53 24 67 89

LYON84, rue du 1er mars 194369625 Villeurbanne CedexTél : +33 4 72 65 21 00Fax : +33 4 78 85 58 24

MARSEILLEBâtiment William Carr263, Boulevard Michelet 13009 Marseille Té l : +33 4 91 77 07 91

Créé en 1988, Cosmosbay est un groupe de conseil ene-business et de mise en œuvre de e-services. Samission est d’accompagner les entreprises dans ladéfinition et la réalisation de leurs solutions métierspour le e-business.

Trois pôles d’activités complémentaires constituent sonoffre globale : Cosmosbay consulting (stratégie & organi-sation), Cosmosbay agency (communication & design) etCosmosbay systems (technologie & ingénierie).

Cosmosbay maîtrise l’ensemble des problématiques dela chaîne de valeur électronique : gestion de la chaînelogistique (Supply Chain Management), intégrationd’applications d’entreprise (Enterprise IntegrationApplication), gestion de la connaissance (KnowledgeManagement) et gestion de la relation client (CustomerRelationship Management).

Cosmosbay est également un groupe français reconnupour son expertise des technologies du web, notammentXML et Java.

W e b : w w w . c o s m o s b a y . c o m • E - m a i l : i n f o @ c o s m o s b a y . c o m