Cosmobay - Livre Blanc Eai - Tres Complet

EAI De l’intégration à l’e-business 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

EAI De l’intégration à l’e-business

EAI

De l’intégration à l’e-business / T a b l e d e s m a t i è r e s

Table des matières Table des matières 1

...................................................................................................................................................................................................

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

7

Fédérer, unifier, s’adapter

.....................................................................................................................................................................................................

8

Mettre en œuvre un système intégré ................................................................................................................................................................................... Recréer un système d’information intégré ................................................................................................................................................................................ Généraliser les passerelles interapplicatives ............................................................................................................................................................................ Fédérer les systèmes ....................................................................................................................................................................................................................

9

Domaines d’application ......................................................................................................................................................................................................... Gestion de la chaîne logistique ................................................................................................................................................................................................... Gestion de la relation client ......................................................................................................................................................................................................... e-marketplaces ............................................................................................................................................................................................................................. De l’intégration à l’e-business

2

4

.............................................................................................................................................................................................

4

9 9 10 11 11 11 12 13

LE MODÈLE EAI

16

Transport : un middleware pour les données ..................................................................................................................................................................... Définition ........................................................................................................................................................................................................................................ Fonctionnalités et technologies .................................................................................................................................................................................................. Couche plate-forme et EAI ..........................................................................................................................................................................................................

16

Données : les adaptateurs applicatifs ................................................................................................................................................................................. Définition ....................................................................................................................................................................................................................................... Fonctionnalités et technologies .................................................................................................................................................................................................. Couche données et EAI ................................................................................................................................................................................................................

19

Composants : appliquer la logique d’entreprise

3

4

16 16 19

19 20 20

...............................................................................................................................................................

21

Moteur d’intégration : le cœur du système d’e-business ................................................................................................................................................ Définition ........................................................................................................................................................................................................................................ Fonctionnalités .............................................................................................................................................................................................................................. Technologies : les message brokers .......................................................................................................................................................................................... Couche moteur d’intégration et EAI ...........................................................................................................................................................................................

23 23

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

27

Processus : modélisation métier .......................................................................................................................................................................................... Définition ....................................................................................................................................................................................................................................... Fonctionnalités et technologies .................................................................................................................................................................................................. Couche processus et eAI .............................................................................................................................................................................................................

27

23 24 26

27 28 29

B2B : eAI ou l’intégration étendue ....................................................................................................................................................................................... Définition ....................................................................................................................................................................................................................................... Fonctionnalités et technologies .................................................................................................................................................................................................. Couche B2B et eAI ........................................................................................................................................................................................................................

29

XML ET L’EAI

33

XML et les six couches du modèle eAI ............................................................................................................................................................................... XML et transport .......................................................................................................................................................................................................................... XML et connecteurs ..................................................................................................................................................................................................................... XML et composants ...................................................................................................................................................................................................................... XML et moteur d’intégration : les serveurs d’applications .................................................................................................................................................... XML, composants métier et workflow ...................................................................................................................................................................................... XML et B2B ................................................................................................................................................................................................................................... XML, langage privilégié de l’échange B2B ........................................................................................................................................................................ cXML, d’Ariba Software ............................................................................................................................................................................................................... xCBL, de Commerce One ............................................................................................................................................................................................................. OBI, de CommerceNet ................................................................................................................................................................................................................. eCo, de CommerceNet ................................................................................................................................................................................................................. ebXML, de l’UN/Cefact et Oasis ................................................................................................................................................................................................. BizTalk, de Microsoft .................................................................................................................................................................................................................... RosettaNet ...................................................................................................................................................................................................................................... Autres initiatives ........................................................................................................................................................................................................................... En résumé… ................................................................................................................................................................................................................................. Une architecture alternative d’EAI bâtie sur XML ............................................................................................................................................................. Applications front-office ...............................................................................................................................................................................................................

29 30 31

33 33 34 34 34 36 37 37 38 38 38 39 39 41 42 43 43 43 44

Table des matières

5

Sources de données ..................................................................................................................................................................................................................... Moteur d’intégration ..................................................................................................................................................................................................................... Référentiel de synchronisation ....................................................................................................................................................................................................

46

MARCHÉ DE L’EAI ET OFFRES DES ÉDITEURS

48

Panorama du marché de l’EAI ............................................................................................................................................................................................... Quelques chiffres ........................................................................................................................................................................................................................... Tendances ....................................................................................................................................................................................................................................... Les offres ....................................................................................................................................................................................................................................... Organisation des fiches produits ................................................................................................................................................................................................

48

Candle ........................................................................................................................................................................................................................................ Présentation de la société ............................................................................................................................................................................................................ Architecture technique du produit .............................................................................................................................................................................................. Le modèle EAI de Candle ............................................................................................................................................................................................................. Synthèse ......................................................................................................................................................................................................................................... Constellar .................................................................................................................................................................................................................................. Présentation de la société ............................................................................................................................................................................................................ Présentation du produit ................................................................................................................................................................................................................ Le modèle EAI de Constellar ........................................................................................................................................................................................................ Synthèse ........................................................................................................................................................................................................................................ Level 8 ....................................................................................................................................................................................................................................... Présentation de la société ............................................................................................................................................................................................................ Architecture technique du produit .............................................................................................................................................................................................. Le modèle EAI de Level 8 ............................................................................................................................................................................................................ Synthèse ......................................................................................................................................................................................................................................... Mercator Software ................................................................................................................................................................................................................... Présentation de la société ............................................................................................................................................................................................................ Présentation du produit ................................................................................................................................................................................................................ Le modèle EAI de Mercator ......................................................................................................................................................................................................... Synthèse .........................................................................................................................................................................................................................................

46

48 48 49 49 51 51 51 52 54 55 55 55 56 58 59 59 59 60 62 63 63 63 64 66

Neon (New Era of Networks) .................................................................................................................................................................................................. Présentation de la société ............................................................................................................................................................................................................ Architecture technique du produit .............................................................................................................................................................................................. Le modèle EAI de Neon ................................................................................................................................................................................................................ Synthèse .........................................................................................................................................................................................................................................

67

STC (Software Technology Corporation) .............................................................................................................................................................................. Présentation de la société ............................................................................................................................................................................................................ Architecture technique du produit .............................................................................................................................................................................................. Le modèle EAI de STC e*Gate 4 ................................................................................................................................................................................................. Synthèse ........................................................................................................................................................................................................................................

71

Tibco Software .......................................................................................................................................................................................................................... Présentation de la société ............................................................................................................................................................................................................ Architecture technique du produit .............................................................................................................................................................................................. Le modèle EAI de Tibco ............................................................................................................................................................................................................... Synthèse .........................................................................................................................................................................................................................................

76

Viewlocity .................................................................................................................................................................................................................................. Présentation de la société ............................................................................................................................................................................................................ Architecture technique du produit .............................................................................................................................................................................................. Le modèle EAI de Viewlocity ....................................................................................................................................................................................................... Synthèse ......................................................................................................................................................................................................................................... Vignette-OnDisplay .................................................................................................................................................................................................................. Présentation de la société ........................................................................................................................................................................................................... Architecture technique du produit .............................................................................................................................................................................................. Le modèle EAI de Vignette-OnDisplay ........................................................................................................................................................................................ Synthèse ........................................................................................................................................................................................................................................ webMethods .............................................................................................................................................................................................................................. Présentation ................................................................................................................................................................................................................................... Le modèle EAI de webMethods ................................................................................................................................................................................................... Synthèse .........................................................................................................................................................................................................................................

6

45

CONCLUSION

67 67 68 70

71 71 72 75

76 76 77 79 80 80 80 81 82 83 83 83 84 85 86 86 87 89 90

5

6

Vue d’ensemble

C H A P I T R E

1 Vue d’ensemble Le système d’information e-business Dans l’entreprise, les développements ont longtemps été pensés et budgétés à un niveau départemental. Cette situation correspondait au succès des technologies client-serveur et au besoin de constituer des applications légères s’appuyant sur leur propre base de données et sachant exploiter le confort procuré par un réseau local. Les réponses apportées aux besoins de l’entreprise en matière de système d’information et de traitement des données étaient en partie guidées par les possibilités technologiques disponibles au moment de la conception de ces systèmes départementaux. Depuis quelques années déjà, Internet met ce modèle en cause. Plusieurs facteurs récents définissent de nouveaux enjeux et élargissent le périmètre du besoin : • La mondialisation de l’économie – Les changements incessants de la nature des marchés, des pratiques commerciales, des législations nécessitent une réactivité accrue de la part de l’entreprise à tous les niveaux de son organisation. • La réduction du time-to-market et l’avantage concurrentiel procuré par le fait d’être le first-to-market – Devant la banalisation des produits et l’érosion de la fidélité des clients, la stratégie Internet d’une entreprise devient un facteur non négligeable de sa réussite commerciale et doit être focalisée sur la fidélisation de sa clientèle et sur la différenciation de sa marque. • La croissance externe et les stratégies de partenariat – Elle sont précédées d’études désormais stratégiques sur la flexibilité du système d’information des entreprises concernées. Lorsque deux systèmes d’information fusionnent, il est indispensable de maintenir un existant opérationnel tout en amorçant la transition vers une consolidation des données. Les acteurs disposent ainsi d’informations fédérées d’aide à la décision assurant la cohérence d’une stratégie partenariale et accompagnant la démarche commerciale et opérationnelle. Ces nouveaux enjeux convergent tous vers la généralisation des besoins d’intégration. Qu’il s’agisse de la production (ERP, Enterprise Resource Planning), de la logistique (SCM, Supply Chain Management) ou de la relation client (CRM, Customer Relationship Management), la chaîne de valeur d’une entreprise se conçoit dans sa globalité et non plus au niveau départemental. L’ensemble des données d’une entreprise (clients, fournisseurs, produits, utilisateurs, etc.) doivent pouvoir évoluer en offrant la garantie de leur cohérence. Cet objectif conduit naturellement à la mise en œuvre de référentiels d’entreprise : l’émergence des métaannuaires l’illustre parfaitement. Pour autant, il n’est pas concevable de se lancer dans une refonte globale du système d’information. D’une part, l’expérience a prouvé que bon nombre de projets aussi volumineux présentaient un risque d’échec important s’ils n’étaient pas découpés en sousprojets de taille plus raisonnable, chacun d’eux étant mis en œuvre progressivement. D’autre part, la réduction du cycle de vie des projets, liée au modèle économique d’Internet, et le besoin de mettre rapidement en application une politique d’e-business nécessitent de s’appuyer sur tout ou partie du système d’information existant. Cette exploitation des données et des applications de l’entreprise doit s’affranchir des rigidités inhérentes aux spécificités de ces systèmes et à leur hétérogénéité. Le système résultant doit être en mesure de réagir efficacement au changement, qui est le nouveau défi permanent lancé à l’entreprise. Toute modification du contexte économique et concurrentiel doit être absorbée sereinement par le système d’information de l’entreprise. Les travaux d’adaptation et d’évolution ne doivent entraîner aucune instabilité, même temporaire, car le facteur Internet impose la disponibilité permanente des systèmes de commerce électronique.

7

EAI

De l’intégration à l’e-business / V u e d ’ e n s e m b l e

Ayant été conçu sans une vision d’ensemble des besoins de l’entreprise, un système départemental ne peut pas servir de fondement à un projet d’e-business : le système d’information doit désormais être pensé à l’échelle de l’entreprise, afin d’atteindre une logique d’unification et de communication globale. Bien sûr, tout au long de cette démarche, il faut accorder un soin particulier à la flexibilité et à l’interopérabilité des éléments d’infrastructure qui constitueront le système fédéré. Les principales technologies mises en œuvre dans les projets d’intégration répondent à ces exigences et s’appuient aujourd’hui, pour étendre l’intégration aux partenaires de l’entreprise, sur l’apport des technologies d’Internet, notamment de leur champion : XML (eXtensible Markup Language).

Fédérer, unifier, s’adapter Les mots-clés régissant l’infrastructure d’un système intégré sont fédération, unification et adaptation. • La fédération est la démarche qui privilégie la réutilisation des sources de données et des règles métier existant dans l’entreprise. • L’unification est la mise en place de processus métier d’entreprise coordonnant les sources de données et les applications entre elles. • L’adaptation est la capacité du système à prendre en compte de nouveaux processus métier ou de nouvelles applications et à modifier les processus et les applications existants.

8

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

Vue d’ensemble

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

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

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

Applications spécifiques

SCM

CRM

ERP

Figure 1 – Système « spaghetti »

E-commerce

9

EAI

De l’intégration à l’e-business / V u e d ’ e n s e m b l e

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

Fédérer les systèmes

10

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

Applications légataires

Applications spécifiques

Solution d'EAI

SCM

ERP

CRM

E-commerce

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

Vue d’ensemble

La concrétisation d’une démarche d’EAI peut représenter un défi technique au coût non négligeable. Mais les avantages procurés par ces outils dans la mise en œuvre du système d’e-business (fluidification des échanges d’information, modélisation des processus métier, flexibilité et réactivité au changement) et l’évolutivité de ces plates-formes dans le cadre de l’intégration de nouvelles applications garantissent un retour sur investissement très rapide – en général après quelques mois d’exploitation. Les plates-formes d’EAI conduisent également à une industrialisation des processus de conception, de développement et de déploiement des applications, gage de la pérennité des systèmes intégrés ainsi réalisés. En résumé, tout concourt à privilégier la démarche d’EAI dans le processus d’évolution d’un système d’information vers l’e-business.

Domaines d’application Les bénéfices de la démarche d’EAI couvrent toute la chaîne de valeur de l’entreprise et l’accompagnent dans l’application de sa stratégie d’e-business. Cette démarche est un facteur de réussite important dans les domaines de la gestion de la chaîne logistique (SCM), de la gestion de la relation client (CRM) et des places de marché sur Internet (e-marketplaces).

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

Gestion de la relation client La gestion de la relation client (CRM) a pour objectif d’améliorer la satisfaction et la fidélité des clients. Le développement d’applications CRM nécessite une démarche d’unification des informations dispersées dans l’entreprise pour constituer le référentiel client (voir l’encadré « Le référentiel client »). Ce dernier s’enrichit d’informations fournies par des services traditionnellement mis en œuvre au sein du back-office. Il faut donc bien penser l’intégration du projet CRM au système d’information et qualifier avec soin les données qui constitueront le référentiel client. Le besoin d’intégration se fait particulièrement sentir sur le plan de l’alimentation des services de gestion de la relation client. En effet, le système CRM, situé à la croisée de domaines tels que la vente, le marketing et le support client, est un consommateur avide d’informations consolidées. En aval, il peut également s’intégrer avec les applications de facturation et de comptabilité ou avec des systèmes décisionnels.

11

EAI

De l’intégration à l’e-business / V u e d ’ e n s e m b l e

Cette démarche d’intégration des informations client élargit le potentiel de personnalisation des services offerts. Ce potentiel se manifeste lors de l’extension des activités de l’entreprise sur Internet. La personnalisation du contenu et des services est une stratégie payante en matière de fidélisation des clients ; cette démarche rend possible la collecte d’un ensemble d’informations indispensables à la connaissance du profil des internautes visitant le site. Cette application devient en effet un point de contact privilégié avec des clients que l’entreprise ne verra peut-être jamais physiquement. L’e-business est une forme d’intermédiation dans laquelle les informations sont présentées au client sans le concours des collaborateurs du front-office. Ceux-ci, de par leur connaissance du métier, savent masquer la complexité des processus d’entreprise et ont une appréhension « physique » du client qu’une application Internet ne peut pas avoir. L’application Internet doit comporter des mécanismes permettant de créer cette connaissance à partir des informations fournies sur le site par le client.

Le référentiel client Chaque application à intégrer (CRM, ERP, applications légataires, etc.) dispose d’une vue différente de l’entité client. La constitution d’un référentiel client unifié est bien plus qu’une problématique technique car elle influe sur la définition même du client et des processus métier qui l’utilisent. La fiabilité des informations échangées dépend à la fois du format des données et de l’application des règles métier. Pour assurer la cohérence, il faut construire une vue unifiée du client en temps réel. Cette vue unifiée constitue le référentiel client, indispensable aux applications CRM et point central des applications d’e-business construites sur le nouveau système.

12

e-marketplaces Une place de marché est un point de liaison central destiné à réunir des centaines d’acheteurs et de vendeurs. Sur Internet, le concept de place de marché se traduit par la mise en relation des systèmes d’information des entreprises au travers d’une intégration « métier ». Ces places de marché sont généralement spécifiques à des industries, mais les besoins d’intégration sont similaires et convergent aujourd’hui vers un certain nombre d’initiatives de normalisation. Ce nouveau modèle économique impose la prise en compte de trois dimensions : • La gestion des transactions, de la sécurité (cryptage et authentification des parties) et de l’infrastructure réseau – Techniquement, les besoins sont proches de ceux de l’EAI interne à une entreprise : messaging, non-répudiation et sécurité. • La gestion des fournisseurs et des catalogues – Il s’agit de la capacité à recruter des vendeurs, à collecter les catalogues (sous tous formats, y compris papier) et à générer des catalogues normalisés. • L’offre de services à valeur ajoutée – Ce sont des enchères, des appels d’offres, ou encore les services de logistique ou de facturation électronique. La différenciation concurrentielle tient à l’originalité du modèle de services et à sa qualité. La participation financière des acteurs pourra être fixée au mois ou à la transaction. On retrouve différents acteurs sur ce marché : • Des éditeurs d’applications d’e-marketplace, comme i2 Technology et son produit TradeMatrix. • Des éditeurs de progiciels comme SAP, avec mySAP.com ou Oracle, avec Oracle Exchange. La spécificité de ces offres est de se connecter à leurs propres environnements logiciels. • Des acteurs du B2B, comme Ariba Software ou Commerce One. • Des acteurs de l’EAI qui, comme Tibco, enrichissent leur offre d’EAI initiale de modules complémentaires d’EIP (Enterprise Information Portal) et de B2B. Les solutions de places de marché sont en général créées à partir de technologies complémentaires. Par exemple, e2open.com est une place de marché reliant les acteurs des industries informatique et électronique fondée sur B2B Commerce Platform, d’Ariba Software, sur l’application d’e-marketplace TradeMatrix, d’i2 Technology, et sur WebSphere Commerce Suite, d’IBM.

EAI et EIP La distinction entre EAI et EIP (Entreprise Information Portal) peut paraître floue dans la mesure où ces deux types de solutions se connectent à des systèmes hétérogènes et à des sources de données variées. Cependant, l’EAI a pour objectif l’échange de données entre applications, alors que l’EIP agrège les informations pour une application cible qui va se charger de les présenter à l’utilisateur final. L’EIP a donc une finalité front-end marquée, alors que l’EAI est orientée back-end. En règle générale, ces deux solutions sont complémentaires et l’application d’EIP constitue le front-end du système d’information dont les données proviennent en partie de la plate-forme d’EAI. L’e-marketplace est un réseau à valeur ajoutée dont la matérialisation tient autant de l’EIP que de l’eAI (l’extension sur Internet de l’intégration d’applications).

Vue d’ensemble

De l’intégration à l’e-business Parmi les trois démarches de conception d’un système intégré que nous avons décrites précédemment, la démarche d’EAI est celle qui permet de s’appuyer sur les applications existantes en se focalisant sur la flexibilité et l’adaptabilité du système résultant. Par définition, la démarche d’EAI est un processus d’intégration d’applications développées indépendamment, utilisant des technologies incompatibles et devant continuer à être gérées séparément. La flexibilité, l’évolutivité et l’adaptabilité, aujourd’hui indispensables au maintien de la compétitivité de l’entreprise, sont également des bénéfices stratégiques qui découlent de la mise en œuvre de ces solutions. Ainsi, non seulement une démarche d’intégration permet d’orienter les systèmes d’information vers l’e-business, mais elle est aussi la plus apte à assurer leur pérennité face aux besoins d’évolution. Cette réactivité couvre la possibilité d’accueillir facilement de nouvelles applications au sein de l’entreprise conçue dans sa globalité, c’est-à-dire étendue aux systèmes de ses partenaires. Pour répondre à de telles exigences, les plates-formes d’EAI imbriquent des technologies très variées. Afin d’en aborder la richesse et d’en comprendre l’évolution, examinons les différentes briques qui constituent aujourd’hui les solutions d’intégration. La première génération de plates-formes d’EAI, dédiée à la libération des flux d’information au sein de l’entreprise, est dotée d’une organisation, que nous qualifierons de modèle EAI, construite sur quatre briques techniques : • Le transport des données – Potentiellement sécurisé, il passe par des files d’attente de messages qui encapsulent l’information et la stockent jusqu’à son exploitation. • L’extraction d’informations depuis les applications et l’insertion de nouvelles informations dans ces applications – Cette opération est réalisée par l’utilisation de connecteurs qui se « branchent » sur les applications. • Les composants – Ils permettent d’effectuer des traitements métier complémentaires sur les données extraites. Ils enrichissent et étendent l’intelligence de la plate-forme d’intégration. • Le moteur d’intégration – Il administre les règles de transformation et de routage des données. Cœur du système, il fournit également un ensemble de services complémentaires d’administration, de surveillance et d’analyse de l’activité du système. Ce modèle est représenté graphiquement par la figure 3.

Moteur d'intégration Composants Données Transport Figure 3 - Modèle EAI

13

EAI

De l’intégration à l’e-business / V u e d ’ e n s e m b l e

Lors d’une extraction de données, l’information est recueillie par les connecteurs applicatifs, puis empaquetée dans un message placé et conservé dans des files d’attente. Le moteur d’intégration, alerté par l’arrivée d’un message, traduit les données pour les router vers l’application destinataire. Les composants peuvent être sollicités pour vérifier certaines règles métier et influencer le comportement du moteur d’intégration. En dernier lieu, les données sont transmises, via la couche transport, au connecteur branché sur l’application destinataire et chargé d’opérer la mise à jour des données. Ce modèle est extrêmement flexible, car il existe des connecteurs applicatifs pour un grand nombre d’applications standard du marché. Il devient dès lors plus facile de remplacer une application obsolète par une application exploitant de nouvelles fonctionnalité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 celleci aux files d’attente de messages, configurées depuis le moteur d’intégration. Le système d’information bénéficiant de l’apport d’une plate-forme d’EAI devient un système modulaire dont l’évolution n’est pas source d’instabilité. La deuxième génération est tournée vers les processus métier et les échanges interentreprises : elle prend en compte les nouveaux modèles économiques créés et promus par Internet et ses technologies (TCP/IP, SMTP, HTTP, FTP, XML, etc.). Cette deuxième génération de plates-formes d’eAI dispose d’une architecture enrichie, qualifiée désormais d’eAI, offrant un modèle d’intégration étendu à ses partenaires. Les technologies qui viennent se greffer sur le modèle initial sont : • Un moteur de workflow – Il sert à modéliser et à mettre en œuvre au sein de la plate-forme d’intégration les processus métier de l’entreprise. • Une infrastructure d’échange B2B – Elle permet aux entreprises de communiquer.

14

Le moteur de workflow complète le travail des composants dans l’organisation de la logique métier. Concrètement, les processus métier modélisés au sein du moteur de workflow sont implémentés par ces composants. Leur exécution s’enrichit de mécanismes de synchronisation ou de rendez-vous, prend en compte l’intervention humaine à travers des notifications et encapsule des transactions longues avec possibilité de restaurer les données dans leur état initial. La brique d’échange B2B ouvre la plate-forme vers l’extérieur. Cette ouverture s’appuie sur un échange des données formatées dans des langages normalisés construits sur XML. Cet échange s’intègre dans un processus métier workflow, lui-même normalisé par les travaux d’organismes fédérateurs que nous présentons plus loin dans ce livre blanc. Seront ainsi distingués les processus privés, internes à l’entreprise, et les processus publics, partagés avec les partenaires. Ces deux nouvelles briques viennent se superposer au modèle initial pour définir la topologie à six couches représentée graphiquement par la figure 4.

B2B Processus Moteur d'intégration EAI Composants Données Transport Figure 4 - Modèle eAI

eAI

Vue d’ensemble

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

15

EAI

De l’intégration à l’e-business / L e m o d è l e E A I

C H A P I T R E

2 Le modèle EAI Ce chapitre reprend les couches décrites dans la vue d’ensemble : • transport ; • données ; • composants ; • moteur d’intégration.

16

Transport : un middleware pour les données Définition Les services de transport assurent la livraison des données aux applications via le moteur d’intégration, tout comme l’appareil circulatoire alimente en sang chaque organe du corps. Dans la pratique, toutes les solutions d’EAI reposent sur une couche plateforme, ou middleware, soit propriétaire, soit fournie par un éditeur partenaire. Plus généralement, une solution d’EAI doit savoir se connecter à tout middleware existant et doit proposer des passerelles entre les middlewares hétérogènes présents dans l’entreprise. L’intégration s’opère ainsi à tous les niveaux : applications, données et middlewares.

Fonctionnalités et technologies Le middleware de l’EAI par excellence est asynchrone. Il est constitué de files d’attente de messages (message queues). Ces solutions sont regroupées sous la dénomination de MOM (Message Oriented Middleware). La plus connue est sans conteste MQSeries, d’IBM ; Microsoft propose MSMQ, sa propre solution. Les MOM sont une couche de transport et ont besoin pour fonctionner d’un outil d’administration des messages transportés : le message broker. Dans une solution d’EAI, ce dernier tient le rôle de moteur d’intégration. Deux autres middlewares synchrones sont également utilisés dans une logique d’intégration : • les ORB (Object Request Brokers), qui correspondent à la fois au middleware sur lequel reposent certaines solutions d’EAI et au middleware constitutif de l’existant d’une entreprise qu’il faut savoir intégrer ; • TCP/IP et HTTP (HyperText Transfer Protocol), protocoles standard de l’Internet, en passe de devenir le middleware de référence de l’échange workflow. Retenons pour l’instant qu’avec un middleware asynchrone, il n’est pas nécessaire de s’assurer de la disponibilité de l’application destinataire, alors qu’un middleware synchrone va l’exiger. Or, tout progiciel connaît régulièrement des phases d’indisponibilité, correspondant au lancement de traitements de masse ou à des opérations de maintenance. Les middlewares sont donc plutôt des technologies complémentaires qu’une plate-forme d’EAI doit savoir intégrer et faire communiquer avec le système de MOM sur lequel elle repose.

Le modèle EAI

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

Rules

Subscriptions Publisher

Topic

subscribe

Agent registrer receive notification/ message

Subject, Channel Figure 5 – Modèle publish and subscribe

Subscriber Agent

17

EAI

De l’intégration à l’e-business / L e m o d è l e E A I

Middlewares synchrones : les ORB et HTTP Les ORB Les ORB peuvent être considérés comme une évolution structurée des mécanismes de RPC (Remote Procedure Calls). Dans les deux cas, le principe est l’invocation synchrone de fonctions applicatives sur des serveurs distants. A la suite de l’appel, le client attend un message l’informant de l’issue de l’exécution de la fonction. Ce type de fonctionnement est difficilement compatible avec une logique d’intégration, selon laquelle les applications autonomes doivent continuer à s’exécuter indépendamment les unes des autres. Rendre le système intercommunicant ne signifie pas le rendre interdépendant ; dans une perspective d’intégration, l’interdépendance forte des systèmes est à éviter. Notons de plus qu’un système fondé sur ces mécanismes nécessite une bande passante élevée pour faire face au trafic réseau requis par les nombreux échanges de messages interapplicatifs. Si on peut difficilement placer les ORB au centre d’une plate-forme d’intégration, on peut néanmoins les rencontrer parmi les technologies à intégrer, notamment pour réutiliser les services métier fournis par des composants placés sur un bus ORB. Nous allons brièvement décrire les mécanismes ORB et ses implémentations les plus fréquemment rencontrées dans l’entreprise. Un ORB forme un bus logique sur lequel se trouvent des composants métier qui fournissent des services. L’ORB traite l’arrivée des requêtes, localise le composant appelé et retourne le résultat de l’appel. Un référentiel (interface repository) est nécessaire pour connaître les interfaces de tous les composants disponibles. Les ORB sont conçus pour être utilisés dans des projets utilisant une véritable approche orientée objet. Les implémentations d’ORB disponibles sur le marché sont Corba (Common Object Request Broker Architecture), de l’OMG (Object Management Group), DCOM (Distributed Component Object Model), de Microsoft et les EJB (Enterprise JavaBeans), de Sun Microsystems.

18

• Corba – L’OMG, groupement de plusieurs centaines de membres, a défini dans les années 90 un standard pour le monde des ORB : Corba. Ce standard est un ensemble de spécifications laissant le choix de l’implémentation aux éditeurs. Des incompatibilités entre les API et entre les ORB en ont résulté. Corba est avant tout un mouvement qui a amené les vendeurs à une meilleure reconnaissance et a facilité les développements. Deux grandes étapes ont marqué la vie de ce standard : - La création d’IDL (Interface Definition Language), langage de description des interfaces de composants logiciels. - La définition, en 1996, du protocole IIOP (Internet Inter-ORB Protocol), qui a été un pas important pour la communication inter-ORB. Ce protocole a ensuite été étendu à des ORB ne s’alignant pas sur Corba, comme RMI (Remote Method Invocation), de Sun Microsystems, et par conséquent au modèle EJB. • DCOM – DCOM est une évolution du modèle de composants propriétaires COM, de Microsoft. Cet ORB utilise le protocole ORPC (Object Remote Procedure Call) et fonctionne essentiellement sous le système d’exploitation Windows. Son avantage est d’être plus accessible que la technologie Corba car globalement moins complexe. Des éditeurs tiers fournissent des services COM sur différentes plates-formes. Les services offerts par DCOM sont plus limités que ceux proposés par les spécifications Corba, mais ils s’améliorent avec COM+ ou avec l’adjonction d’autres technologies Microsoft. • EJB – Le monde Java propose une solution de rechange émergente, reposant sur RMI et sur le modèle de composants métier EJB couplé au référentiel JNDI (Java Naming Directory Interface). Grâce à l’apport de la spécification EJB 1.0 puis 1.1, les architectures Java disposent désormais d’un ORB capable de communiquer avec des ORB Corba. Malheureusement, des spécifications non exhaustives ont, comme pour Corba, obligé les éditeurs à effectuer leurs propres implémentations du modèle, rendant les composants EJB peu portables. La spécification 2.0 vise à combler ces lacunes.

Le modèle EAI

HTTP Nous avons évoqué les raisons pour lesquelles un middleware synchrone paraît inadapté à une architecture d’intégration. HTTP semble pourtant y avoir sa place, mais peut-être davantage dans le modèle eAI que dans le modèle EAI. En effet, en plus de sa nature synchrone, HTTP propose des performances moyennes comparées à celles des MOM, ce qui semble lui barrer la route de l’intégration intra-entreprise. Il permet en revanche un couplage faible et non intrusif entre les systèmes d’information d’entreprises autonomes, rendant l’échange possible sans qu’il soit nécessaire de connaître les technologies utilisées chez les partenaires. De plus, HTTP est un standard véhiculé par un autre standard, le réseau Internet, qui permet d’élargir facilement la gamme des services offerts, là où Edifact et X.12, protocoles de l’EDI, sont nettement plus fermés. HTTP peut devenir, en tant que couche de transport de messages métier XML, le middleware de l’échange interentreprise. Ce middleware se superpose à celui utilisé en interne par la plate-forme d’intégration : le message provenant d’un partenaire est transmis à une file d’attente qui assure la jointure entre les parties internes et externes du système d’e-business. Certaines discussions concernent aujourd’hui la généralisation de HTTP dans une architecture d’intégration en vue de créer des systèmes d’e-business « temps réel » entièrement fondés sur un protocole synchrone.

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

Données : les adaptateurs applicatifs Définition Les données de chaque application doivent être conservées dans leur format natif et sur leur support d’origine, en vue de permettre à l’application qui les héberge de continuer à assurer les services fournis avec le même niveau de performances et d’éviter les coûts liés à leur migration d’un référentiel vers un autre. Les adaptateurs applicatifs (ou connecteurs) vont extraire ces données en fonction des besoins (événements déclenchés par l’arrivée d’un message, étape d’un processus métier) et les diriger vers l’application destinataire. Les connecteurs assurent la communication entre la plate-forme d’EAI et les applications ou les services applicatifs du système d’information. Un adaptateur applicatif est un composant logiciel qui offre la connectivité nécessaire à l’interfaçage avec les applications et les sources de données, avec ou sans intelligence métier. Cette couche logicielle masque à l’utilisateur la complexité de la communication entre l’API du moteur d’intégration et celle de l’application.

19

EAI

De l’intégration à l’e-business / L e m o d è l e E A I

Fonctionnalités et technologies Les connecteurs doivent être des systèmes non intrusifs (on n’introduit pas de portions de codes dans les systèmes sources ou cibles). Ils peuvent fournir des services complémentaires tels que la gestion des exceptions ou des mécanismes de remontée d’erreurs. Ils doivent donc être dotés de l’intelligence nécessaire à l’interprétation de ces messages. Il faut également que la plate-forme d’intégration soit capable d’interpréter les messages d’erreur en tant que tels.

Typologie des adaptateurs Il existe aujourd’hui un grand nombre d’adaptateurs, qui correspondent aux différents types d’applications que l’on peut rencontrer. Le nombre d’adaptateurs fournis avec chaque solution est d’ailleurs un argument de vente des éditeurs d’EAI. Pour décrire les offres d’EAI, nous adopterons dans ce livre blanc la classification suivante : SGBD – DB2, SQL Server, Informix, Oracle, Sybase, Lotus Notes, ODBC, JDBC, etc. ; ERP – PeopleSoft, SAP, Oracle Applications, JDEdwards, Siebel, etc. ; CRM – Vantive, Siebel, Clarify, BroadVision, etc. ; SCM – i2 Technology, etc. ; Mainframes – SNA, CICS, IMS, OSI TP, VSAM, EBCDIC, 3270, OS/390, etc. ; MOM – MQSeries, MSMQ, etc. ; ORB – Corba, DCOM, Java, etc. ; Protocoles Internet – HTTP, XML, SMTP, etc. ; B2B – Swift, Edifact, X.12, XML (RosettaNet, BizTalk), etc.

20

Applications spécifiques Il y a, dans une entreprise, un ensemble d’applications spécifiques légataires pour lesquelles il ne peut exister d’adaptateur standard sur le marché. Pour cette raison, les éditeurs fournissent généralement avec leur plate-forme un kit de développement. Il guide la mise en œuvre de connecteurs et masque une partie de la complexité technique propriétaire, notamment la communication avec les files d’attente. Les kits de développement (SDK, Software Development Kit), la documentation sur les API existantes et la formation dessinent la panoplie du développeur de connecteurs. Il est donc important, lors de la recherche d’une plate-forme d’EAI, de vérifier si des formations sont assurées, éventuellement sur site et, au besoin, si elles sont dispensées en français. Généralement, l’éditeur propose aussi des prestations de conseil et d’ingénierie pour la réalisation des adaptateurs ou délègue ces missions à des intégrateurs partenaires.

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

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

Le modèle EAI

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

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

21

EAI

De l’intégration à l’e-business / L e m o d è l e E A I

OAGI (Open Application Group, Inc.) OAGI est un consortium industriel à but non lucratif créé en 1995. Regroupant au départ des entreprises comme Dun & Bradstreet Software, Oracle, PeopleSoft ou SAP, le consortium compte désormais plus de 37 membres. Son but est de promouvoir l’intégration de composants métier logiciels pour l’entreprise en définissant un modèle de solutions pratiques et implémentables pour rendre l’interopérabilité possible. Après 18 mois de travaux, OAGI a rendu en juin 1997 la proposition OAGIS (Open Application Group Integration Specification), qui spécifie exhaustivement la démarche d’intégration. Ce modèle contient : • une architecture applicative ; • des définitions de composants métier logiciels ; • des diagrammes de scénario d’intégration de composants ; • des définitions détaillées d’API nécessaires à l’intégration de composants métier logiciels ; • un dictionnaire de données décrivant les éléments individuels de ces API. Une démarche d’intégration type est également définie : • définition du besoin et du scénario d’intégration ; • définition des composants métier logiciels et de leur granularité ; • développement d’un scénario d’intégration détaillé. La phase de modélisation est évidemment déterminante dans un projet d’EAI. Elle permet de définir les objectifs à atteindre et, à travers eux, de déterminer le nombre, la complexité et la portée des processus métier : • modélisation des processus métier et définition des relations entre les composants métier ; • définition d’un dictionnaire de données commun pour permettre aux composants métier de partager le même vocabulaire ;

22

• mise au point de normes pour décrire les flux entre les composants logiciels métier, définissant l’interopérabilité pour la synchronisation de données, la validation, les transactions, le reporting, l’audit, la sécurité et l’authentification. OAGIS se concentre sur la démarche et non sur la technologie. Le consortium a néanmoins défini un niveau d’interopérabilité des composants par la définition d’un modèle d’objet virtuel, en réalité une couche d’implémentation standardisée venant se superposer à l’interface publique de tout composant et la rendant virtuellement privée. Les composants communiquent alors entre eux par l’échange de BOD (Business Object Documents) entre ces interfaces virtuelles.

Le modèle EAI

Moteur d’intégration : le cœur du système d’e-business Définition Le moteur d’intégration centralise l’intelligence de la plate-forme d’EAI via son référentiel, qui contient toutes les règles de routage et de transformation des données. Il sait à quel événement métier appartient le message recueilli et assure la continuité de cet événement. Il se configure et s’administre grâce à un ensemble d’outils munis d’une interface graphique. Le moteur d’intégration est donc la brique qui donne naissance au prototypage, puis au développement du projet d’EAI. Le rôle du moteur d’intégration consiste à convertir les données, qui sont au départ au format de l’application source, dans le format utilisé par l’application de destination (fonctionnalités de transformation) et à les transmettre à cette application (fonctionnalités de routage).

Transformation Les applications du système d’information ont des modèles de données différents. Les données de l’application A ne sont pas directement compréhensibles par une application B : elles ne partagent généralement pas les mêmes types ni la même sémantique. Par exemple, un champ Date d’émission stocké au format texte dans une application mainframe peut correspondre au champ Date de sortie, de type date, dans la base de données d’une application Internet. Le moteur d’intégration connaît les spécificités de chaque application et sait comment transformer les informations pour assurer la correspondance entre les modèles de données. C’est le processus de mapping, étape importante de tout projet d’EAI. Convertir des données entre deux applications est une opération délicate, dont la complexité s’intensifie à mesure que de nouvelles applications s’ajoutent aux précédentes. La facilité d’évolution d’une plate-forme d’EAI vers l’intégration de nouvelles applications doit être étudiée avec soins lors du choix d’une plate-forme. La richesse des outils de configuration et de l’interface graphique à disposition de l’utilisateur doit être qualifiée avec soin.

Routage L’intelligence de routage est complémentaire de l’intelligence de transformation. Toute plate-forme d’EAI inclut un référentiel des métadonnées, qui contient les règles de routage mises en rapport avec le processus métier auxquelles elles se réfèrent. Ainsi, l’arrivée d’un message est corrélée avec une étape de processus, et le référentiel indique les actions à mener et l’application à laquelle il faut s’adresser pour passer à l’étape suivante. Le routage ne désigne pas systématiquement une communication one-to-one linéaire entre une application A et une application B. Les données peuvent être recueillies auprès de plusieurs sources, puis agrégées pour créer un nouveau message qui sera envoyé à plusieurs applications. Ce mode de communication many-to-many se rencontre lorsque des processus métier se croisent ou dans le cas d’une intégration incrémentale (remplacement progressif d’une application par une autre application fonctionnellement équivalente ou plus évoluée).

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

Configuration, administration et supervision Les plates-formes d’EAI proposent habituellement trois types d’outils pour insérer la plate-forme au sein du système d’information et l’exploiter au quotidien. Ils sont généralement dotés d’une interface graphique, qui entraîne, pour certains, la nécessité d’administrer la plate-forme depuis un client Microsoft Windows. Le déploiement peut cependant généralement s’opérer sur des machines équipées de systèmes d’exploitation hétérogènes (Unix majeurs du marché et parfois Linux). On recense : • Des outils capables de découvrir facilement les ressources mises à disposition par les sources de données et les applications existantes, de créer les schémas de correspondance entre les structures de données et les transformations de ces données.

23

EAI

De l’intégration à l’e-business / L e m o d è l e E A I

• Des outils capables de tracer les échanges de messages, de suivre le déroulement des processus et d’élaborer des rapports d’activités. Il est indispensable de savoir si les processus se sont correctement achevés et de connaître la durée de leur exécution. Il faut être en mesure d’identifier la nature et la raison des problèmes rencontrés et de reprendre tout ou partie d’un processus non achevé. Enfin, il est nécessaire de disposer de rapports sur les performances de la plate-forme et du système et sur son comportement au moment des pics de charge. Ces informations vont avoir des conséquences sur la configuration du système, car l’administrateur va alors rechercher la configuration optimale afin d’améliorer les performances et la robustesse du système. Les points d’optimisation concernent la montée en charge (déplacement des charges et pics de charge), la tolérance aux pannes, les goulets d’étranglements, les ruptures de connexions réseau, etc. Des outils capables de modifier facilement la répartition des éléments du système et la distribution à distance de ses composants ou des message brokers (architecture multi-hub) vont permettre de pratiquer cette optimisation facilement et à distance.

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

Référentiel Répertoire des applications connectées et de leurs spécificités, connaissance des informations à transmettre d’une application à l’autre et de la traduction à effectuer. Ce référentiel est soit une base propriétaire propre à l’architecture de l’éditeur, soit l’exploitation d’une des bases de données majeures du marché (IBM, Microsoft, Oracle, Sybase).

Ouverture aux fonctions d’annuaires 24

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

Technologies : les message brokers Les message brokers mettent en relation des entités sources et des entités destinataires via un échange de messages entre elles. Il intègre nativement les fonctions de routage et de transformation évoquées. 1. Les message brokers ne remplacent pas les middlewares traditionnels comme les MOM, les ORB et HTTP, mais ils s’y couplent. Un message broker peut ainsi être perçu comme un « middleware pour le middleware ». MOM et message brokers forment aujourd’hui un duo indispensable à toute architecture d’intégration. 2. L’architecture qui en résulte est qualifiée de hub-and-spoke (à moyeu et à rayons) : le moteur d’intégration se conduit comme un hub centralisé. Il utilise les technologies de files d’attente pour traiter les messages en provenance des différentes applications du système. Il est le nœud centralisateur ; il apporte sa valeur ajoutée au contenu et à la structure des messages avant de les diffuser aux applications cibles. Les connecteurs applicatifs et le système des files d’attente permettent au message broker de s’affranchir de la technologie des applications auxquelles il transmet des données. En contrepartie, les applications émettrices envoient des messages sans se soucier de la technologie de l’application cible, ni même de celle du message broker. Le couplage lâche entre le message broker et les applications du système d’information qui résulte de la mise en œuvre de ces technologies procure un avantage indéniable à cette architecture. Aucun aménagement lié à l’intégration n’est nécessaire dans les applications sources : le développement est réalisé visuellement depuis les interfaces graphiques du message broker et centralisé dans le référentiel d’intégration. 3. Les message brokers reposent généralement sur des technologies de message queuing, avec un support du publish and subscribe. Les applications publient (publish) des messages sur les files d’attente du MOM gérées par le message broker. Celui-ci transforme les messages et les place sur d’autres files d’attente, où d’autres applications abonnées (subscribe) à ces files les récupèrent. Chaque file d’attente est caractérisée par un sujet (par exemple, enterprise.erp.logistique).

Le modèle EAI

4. Dans un contexte d’EAI, un message broker assure des communications any-to-any et many-to-many. Any-to-any désigne une connexion facilitée et transparente entre toutes sources de données. Celle-ci est garantie par la présence d’adaptateurs applicatifs standard et par la possibilité d’en développer. Many-to-many signifie que toute application sait se connecter aux informations publiées par toute autre application et sait les utiliser. Les capacités de transformation du message broker sont alors déterminantes. 5. La vocation d’une plate-forme d’intégration est de se placer au centre du système d’information. Cette place stratégique implique des architectures performantes, robustes et capables de traiter de gros volumes de données. Elle requiert aussi des fonctionnalités comme le support des transactions, l’intégration de processus métier sophistiqués aux règles de routage complexes ou l’ouverture aux fonctions d’administration réseau, qui ne sont pas la vocation première de ces plates-formes. Le support des transactions n’est pas pris en charge par un message broker. Il est important que la plate-forme d’EAI incorpore un gestionnaire de transactions sachant communiquer avec le message broker, mais cette possibilité intéressante aura obligatoirement un impact sur les performances. L’intégration de processus métier complexes est liée aux difficultés parfois rencontrées par un message broker pour coder certaines règles de routage. Le niveau de sophistication exigé n’est pas forcément atteint. Cette raison a poussé l’EAI à intégrer une véritable brique de workflow et à la rendre communicante avec le message broker. La complexité des processus d’entreprise à modéliser déterminera le besoin d’intégration et donc la nécessité ou non d’utiliser cette brique de workflow. L’ouverture aux fonctions d’administration réseau, par connexion à des agents SNMP, permet d’inclure la plate-forme dans un ensemble plus vaste. La plate-forme d’intégration doit incorporer un ensemble de fonctions d’ouverture à des éléments extérieurs qui élargiront son spectre fonctionnel et technique tout en supportant la charge de travail qui en résultera. 6. Les architectures d’EAI reposant sur un message broker sont nombreuses et majoritaires. Citons ActiveWorks, d’Active Software (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 ».

25

EAI

De l’intégration à l’e-business / L e m o d è l e E A I

Couche moteur d’intégration et EAI Rappelons que les architectures d’EAI utilisant un message broker et fonctionnant selon le mode que nous avons décrit sont qualifiées d’architectures hub-and-spoke. Les applications sont connectées à un nœud central, qui concentre les flux. Ce hub contient les règles nécessaires pour connecter des applications et rassembler des messages. C’est l’architecture typique d’une plateforme d’intégration.

Application Application

Application

Application

Message Broker Application

Application Application

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

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

Application

Application Application

Application

Application

Message Broker

Message Broker

Application

Application Application

Application

Application

Application

Message Broker

Application

Application

Application

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

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

C H A P I T R E

3 De l’EAI à l’intégration étendue Ce chapitre reprend les couches décrite dans la vue d’ensemble : • processus ; • B2B.

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

Séparation du métier et de la technique En incorporant une brique de modélisation métier sophistiquée, concrétisée techniquement par un moteur de workflow, les platesformes d’intégration séparent la modélisation métier et l’implémentation technique des processus.

27

EAI

De l’intégration à l’e-business / D e l ’ E A I à l ’ i n t é g r a t i o n é t e n d u e

Il est logique de dissocier les deux aspects : lors de la réflexion sur les processus métier, l’architecture technique nécessaire à leur future exécution ne doit pas interférer. Les interlocuteurs participant à la réflexion sont en effet des analystes métier, et non des architectes du système d’information. Inversement, lors de la mise en œuvre technique, les analystes métier ne doivent pas être concernés : peu importe le processus, les seules réponses à apporter concernent les composants métier, l’extraction des données, leur routage et leur transformation.

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

Gestion du workflow Son principe consiste à automatiser le routage des informations et des documents d’utilisateur à utilisateur : • Processus à durée de vie longue, automatisés mais avec la possibilité d’une intervention utilisateur. • L’état du processus peut être conservé en base de données. • Des milliers de tâches par heure. • Des fonctions fortement structurantes pour l’organisation : utilisé pour le traitement d’une déclaration d’assurance, la vérification d’un rapport de dépenses ou pour passer les ordres de commande fournisseur. • Un reporting métier fort.

Automatisation de processus Son principe consiste à automatiser les processus de production entre applications et systèmes. • Processus de transport et de contrôle d’information à durée de vie courte, complètement automatisés. • L’état du processus ne peut être conservé qu’en mémoire centrale. • Des centaines de messages par seconde. • Processus rapides, adaptés au Web (B2B et portails).

28

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

Standardisation Les travaux du WfMC (Workflow Management Coalition) cherchent à uniformiser la terminologie et à définir des standards pour élaborer une spécification d’interopérabilité et un langage commun de requêtes et de réponses d’un moteur de workflow. Pour l’EAI, c’est l’occasion : • de faire communiquer entre eux des systèmes d’EAI hétérogènes au niveau processus et non plus seulement données ; • d’affranchir l’échange B2B du cadre dans lequel une entreprise pivot dirige l’échange et le processus métier. Le WfMC définit également les fonctionnalités que tout moteur de workflow se doit d’implémenter.

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

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

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

Gestion d’alertes et notification automatique Cette gestion d’alertes doit être intelligente ; elle doit être capable de router la notification vers un autre acteur en cas d’indisponibilité du destinataire initial ou de prendre une décision qui automatise l’étape courante.

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

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

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

B2B : eAI ou l’intégration étendue Définition L’EAI fédère le système d’information en rendant ses applications intercommunicantes et en centralisant les mécanismes de cette communication. L’EAI apparaît ainsi comme une étape préparatoire à l’eAI, en ce sens que l’eAI est l’extension de cette intégration à l’extérieur de l’entreprise. Ayant libéré ses propres flux d’information, l’entreprise peut envisager l’échange avec ses partenaires et avec tout organisme public ou privé. On regroupera sous le terme d’échange business-to-business, ou B2B, les formes normalisées prises par ces échanges, aboutissant à une transaction au moyen de protocoles de communications standard, légers et conçus pour Internet.

29

EAI

De l’intégration à l’e-business / D e l ’ E A I à l ’ i n t é g r a t i o n é t e n d u e

Selon cette définition, l’EDI (échange de données informatisé) apparaît comme une forme d’échange B2B (voir l’encadré « Échanges sécurisés »). L’objectif de ce livre blanc n’étant pas de traiter de l’EDI, domaine trop vaste pour être couvert ici, nous nous bornerons à évoquer les nombreux standards et initiatives émergeant hors EDI. L’objectif est l’établissement de relations stratégiques entre partenaires, la création de chaînes de valeur permettant d’acquérir ou de conserver un avantage concurrentiel. Ceci implique la création de processus interentreprises automatisés, sécurisés, fiables et en temps réel, dans lesquels l’intervention humaine sera limitée. L’échange d’informations est ainsi créateur de richesse de par la réduction du cycle de circulation des données et l’élargissement des formes de travail collaboratif.

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

Impact sur les modèles économiques L’automatisation des opérations entraîne évidemment une réduction substantielle des coûts de transaction, qui sont inférieurs à ceux d’une transaction EDI. Les économies réalisées grâce à ce type d’échanges attirent les acteurs institutionnels et les grands comptes. En contrepartie, ils font profiter les mécanismes B2B de leur puissance, en termes de données comme de services : on retrouve ces acteurs dans les initiatives de conception des langages et des frameworks B2B.

30

De nouveaux modèles économiques se construisent. Le modèle build-to-order, évoqué dans le premier chapitre de ce livre blanc, en est une bonne illustration. L’entreprise dispose en permanence et en temps réel d’informations sur l’évolution des commandes et peut aligner sa logistique sur ces informations. La visibilité des stocks s’accroît et les coûts d’inventaire diminuent significativement. Les échanges B2B ne se limitent pas à des bons de commande. Des boîtes à outil sectorielles se créent. Des initiatives destinées à promouvoir l’échange d’informations de produits ou de projets voient le jour. Par exemple, un bureau d’études disposera de normes et de ressources pour distribuer les spécifications d’un nouveau produit à un fabricant. Les délais de fabrication s’amenuisent et le produit se retrouve plus rapidement sur le marché. Cette accélération des processus répond au niveau de compétitivité exigé par l’ebusiness.

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

Performances La distribution des données d’une requête à plusieurs dizaines de partenaires et l’agrégation des résultats en temps réel nécessitent une qualité de service stable, avec un niveau de performances irréprochable. En effet, l’utilisateur final exigera toujours la disponibilité permanente et rapide des informations. Cela se justifie particulièrement lorsque, par exemple, l’entreprise désireuse de connaître l’état d’une commande est en France et que son fournisseur est aux États-Unis. Les capacités de montée en charge et de tolérance aux pannes doivent donc être fortes, l’accroissement du volume des transactions étant au moins aussi rapide que celui de l’Internet.

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

Flexibilité et facilité d’intégration La modularité que procure une plate-forme d’EAI aux applications du système d’information doit se vérifier dans le cadre d’une démarche d’eAI. Il faut pouvoir intégrer rapidement les changements survenus dans l’environnement professionnel. Dans ce but, le couplage entre applications doit rester lâche. L’utilisation d’Internet est devenue une évidence, et les échanges sur HTTP seront donc privilégiés, ce qui désigne de facto XML comme support de structure des données. Une solution d’intégration doit être fondée sur des standards ouverts, qui garantiront la compatibilité avec d’autres systèmes. On privilégiera également les systèmes non intrusifs.

Fiabilité S’insérer dans une chaîne d’échange nécessite un système robuste, sous peine d’en être le maillon faible et de perturber l’efficacité du transport de l’information.

Sécurité Les systèmes impliqués dans des échanges B2B contiennent les données de chaque transaction, mais également des données confidentielles. Les données échangées sont sensibles et les échanges doivent être sécurisés : cryptage des messages transmis avec X.509, authentification par utilisation de certificats X.509, utilisation de protocoles de sécurité du monde de l’EDI (X.435). Enfin, la connexion directe à des systèmes partenaires doit s’effacer au profit de l’échange d’informations sur HTTP. Les rôle des standards du Web est donc déterminant. La définition et l’administration des processus d’agrément d’échange entre les partenaires sont également très importantes.

Échanges sécurisés S/MIME S/MIME (Secure Multipurpose Internet Mail Extensions) est une méthode sécurisée d’envoi d’e-mails utilisant le système de chiffrement RSA. Intégré aux versions les plus récentes des navigateurs web commercialisés par Microsoft et Netscape, S/MIME a reçu l’aval d’autres éditeurs de produits de messagerie. S/MIME est le protocole de courrier électronique sécurisé le plus déployé. PGP/MIME PGP (Pretty Good Privacy) est un protocole disponible depuis 1991. L’utilisation de PGP a connu un certain succès grâce à son cryptage fort des e-mails et des fichiers. PGP/MIME est une évolution de PGP. Les deux architectures se différencient par l’authentification : • S/MIME repose sur les certificats X.509 (une autorité de certification vend un certificat d’identité). S/MIME est orienté vers une administration centralisée au niveau d’un référentiel d’entreprise. • PGP repose sur un système dit de réseau de confiance (on affirme sa confiance en signant les clés publiques de ses amis). Il se fonde sur une gestion de la politique et des clés par l’utilisateur. Les plates-formes d’intégration orientées B2B incorporent fréquemment l’un ou l’autre de ces protocoles de sécurisation, voire les deux.

Couche B2B et eAI La rapidité d’implémentation des solutions sera un critère déterminant. Une interface graphique va se révéler nécessaire pour parvenir à un bon niveau de productivité. Deux écoles s’opposent quant à la nature des outils susceptibles de répondre au mieux au besoin. Les uns, initialement éditeurs d’EAI, partent du constat que le B2B est inutile sans démarche d’intégration EAI préalable. Une plateforme 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 technologies propriétaires issues d’un même éditeur : les deux systèmes communiquent entre eux en conservant de bons niveaux de performances. Les autres, éditeurs de solutions B2B, affirment que la démarche d’intégration B2B est une démarche spécifique qu’un outil généraliste ne peut prétendre adresser efficacement. La spécialisation de leur plate-forme leur permet de fournir davantage de fonctionnalités et des performances accrues. L’échange B2B requiert en effet des fonctionnalités que l’échange EAI n’exige pas, comme la gestion des partenaires ou la gestion de la sécurité. Cependant, rien n’empêche de développer ces fonctionnalités pour la couche B2B d’une plate-forme initialement dédiée à l’EAI.

31

EAI

De l’intégration à l’e-business / D e l ’ E A I à l ’ i n t é g r a t i o n é t e n d u e

Étant donné le lien étroit qui existe dans l’entreprise globale entre ERP, SCM, CRM et e-business, la politique d’intégration doit également être globale pour être efficace et ne peut être réservée qu’à l’échange B2B. Une plate-forme exclusivement dédiée au B2B doit donc savoir s’interfacer avec la brique de workflow d’une plate-forme d’EAI en vue d’établir la connexion avec le système d’information « interne » de l’entreprise. À tout besoin d’intégration correspond une ou plusieurs plates-formes ; il convient de déterminer celle qui satisfait le mieux la demande en fonction de critères prioritaires. Par conséquent, la phase de prototypage est une étape incontournable de tout projet d’EAI. Par ailleurs, lorsque la communication interentreprise est normalisée selon des règles communes à un secteur ou à une industrie, elle peut finalement se dérouler selon les mêmes principes qu’une solution interne : le système reste un système modulaire. On peut envisager d’élargir son activité avec de nouveaux partenaires ou d’en changer sans remettre en cause l’existant et sans impliquer de modifications importantes dans la gestion des interfaces avec ses partenaires. En mettant à disposition un ensemble de services et de procédures d’échanges de données, une entreprise va dévoiler à ses partenaires une partie de ses mécanismes de traitement de l’information, notamment ceux relatifs aux aspects cruciaux des performances et de la sécurité. Nous avons vu que les études sur l’efficacité des systèmes d’information sont devenues monnaie courante et déterminent la faisabilité d’un partenariat, d’une alliance ou d’une fusion. Les entreprises de l’e-business auront à gérer l’image de leur système d’information, et ce critère entrera en ligne de compte dans le choix de la mise en œuvre d’un partenariat ou d’une collaboration. D’après le cabinet Forrester Research, l’expansion des échanges B2B est légèrement freinée par la relation privilégiée qu’entretiennent les entreprises avec certains partenaires hors de toute considération technologique. Ces habitudes sont d’ores et déjà bousculées par les besoins de modularité qu’entraînera demain la généralisation des échanges B2B, a fortiori devant l’accroissement exponentiel du nombre de partenaires interconectés via une e-marketplace.

32

XML et l’eAI

C H A P I T R E

4 XML et l’eAI XML, le métalangage de description des données, soutenu par l’ensemble de l’industrie informatique, est appelé à prendre une place importante sur le marché de l’eAI. Ses avantages intrinsèques le désignent en effet comme une technologie de choix dans ce domaine : il est capable de résoudre toutes les problématiques d’interopérabilité et sait se greffer à moindre coût sur un existant. Cette partie reprend un certain nombre d’informations déjà présentées dans ce livre blanc et les regroupe afin d’éclairer les rôles réel et potentiel tenus par XML dans le monde de l’eAI. Le chapitre 5 du présent livre blanc, « Marché de l’EAI et offres des éditeurs », montre qu’XML est systématiquement pris en compte dans une offre d’eAI. S’il est souvent simplement considéré comme un format reconnu par un connecteur applicatif, il est aussi parfois réservé à des fonctions plus sophistiquées et devient indispensable dès qu’on aborde l’échange B2B. Nous allons, dans ce chapitre, détailler une architecture parallèle à celle généralement constatée dans les plates-formes d’eAI. Elle sera illustrée par un exemple tiré d’un cas réel mis en œuvre par les équipes de Cosmosbay.

XML et les six couches du modèle eAI XML et transport Les messages extraits des applications peuvent être échangés au format XML et véhiculés sur HTTP – deux standards universels – alors que les MOM reposent généralement sur des technologies propriétaires. L’ensemble est ouvert à d’autres standards, ce qui prend tout son intérêt dès qu’on traite de sujets tels que la sécurité. Par exemple, dans un échange B2B, les messages XML sur HTTP peuvent être encryptés avec SSL ou S/MIME et franchir le pare-feu du partenaire sans configuration particulière de celui-ci. Cependant, le fait que HTTP n’autorise pas l’asynchronisme des échanges semble lui interdire le titre de middleware de l’intégration. Modérons cependant ce jugement. Les MOM non standard ne permettent pas aux systèmes de deux partenaires de se connecter simplement. Cette connexion se réalise sur des protocoles propriétaires et le modèle de connexion est une reproduction entre deux entreprises du modèle d’intégration point à point entre deux applications. Il est plus simple d’interconnecter deux entreprises sur un réseau standard supportant un protocole standard, a fortiori quand ceuxci sont mondialement accessibles. HTTP, standard de l’Internet, est la solution. Comme en outre il est non intrusif et permet un couplage faible des systèmes, il devient de facto le middleware standard de l’intégration B2B, et XML, pour les mêmes raisons, devient le langage de prédilection pour formaliser ces échanges. Pour des raisons d’homogénéité, l’entreprise peut souhaiter déployer une architecture d’intégration interne dont les technologies sont identiques à celles de ses échanges B2B, et ainsi généraliser l’utilisation de HTTP comme protocole standard de son système d’information. C’est une démarche inverse à celle que nous présentons depuis le début de ce livre blanc et que l’on rencontre dans les entreprises qui ne disposent pas d’un existant technologique fort. Le système d’information est alors conçu comme un système intégré faisant communiquer les applications ERP, SCM, CRM et Internet.

33

EAI

De l’intégration à l’e-business / X M L e t l ’ e A I

XML et connecteurs Véhiculer des messages XML sur HTTP implique un premier niveau de transformation des données en XML par les connecteurs applicatifs. La communication avec le moteur d’intégration est organisée autour de ce format pivot, comme dans la plate-forme d’intégration Fusion, de Forte. Organiser l’intégration en interne par des flux XML favorise la flexibilité du système et la simplification des adaptateurs : l’interface XML est toujours identique. De plus, une partie de l’intelligence applicative est déplacée au sein du connecteur, ce qui le rend autonome dans un contexte de distribution de la solution. La montée en charge et la tolérance aux pannes peuvent être gérées au niveau des connecteurs autrement que par multithreading. L’interface XML d’envoi et d’accueil des données peut être réutilisée pour d’autres besoins d’intégration ou d’autres projets. Enfin, l’adoption d’un format pivot comme XML pourrait permettre de découpler les briques du modèle EAI et de s’affranchir de la technologie propre à un vendeur en sélectionnant les adaptateurs les plus performants du marché. En effet, à l’heure actuelle les adaptateurs ne savent qu’exploiter les technologies de la plate-forme avec laquelle ils sont fournis. Par conséquent, l’extraction de données au format XML nécessite souvent de développer ses propres connecteurs et de les intégrer à une plate-forme d’intégration spécifique. L’élaboration de ce type de plate-forme est évoquée plus loin, dans la section « XML et moteur d’intégration : les serveurs d’applications ». Certains éditeurs de progiciels proposent néanmoins aujourd’hui des connecteurs XML avec leurs solutions : SAP propose le Business Connector, et les principaux SGBD du marché (IBM, Informix, Microsoft, Oracle, Sybase) extraient en XML les données relationnelles stockées à la demande.

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

XML et moteur d’intégration : les serveurs d’applications La mise en place d’une plate-forme d’intégration reposant sur XML et sur HTTP implique un développement spécifique fondé sur un serveur d’applications. Les raisons et les moyens du déploiement d’une telle application sont décrits ci-dessous. 1. Les serveurs d’applications répondent aux limitations des message brokers : - Le support des transactions est natif pour certains d’entre eux et peut être corrélé avec la session utilisateur, notion absente d’un message broker.

34

- Dans ce contexte, les questions de montée en charge et de tolérance aux pannes sont prises en charge nativement par le système et éprouvées depuis de nombreuses années, alors qu’un éditeur d’EAI traditionnel aura dû développer sa propre technologie. - Une application d’e-business repose forcément sur un serveur d’applications : celui-ci peut devenir le nœud central du système intégré. Il faut cependant développer toute la logique de transformation et de routage, alors que le choix d’un message broker n’impose que le paramétrage. 2. Les serveurs d’applications fonctionnent généralement de manière synchrone par RPC ou ORB pour invoquer des méthodes sur les composants. Ceux-ci peuvent à leur tour traiter des messages XML sur HTTP. On généralise ainsi les technologies d’intégration à l’ensemble du système, sans faire de distinction technologique entre intégration interne et intégration étendue. L’exécution asynchrone de certains traitements peut être spécifiée, notamment pour ceux portant sur des messages XML. Enfin, il est techniquement envisageable de s’interfacer avec un MOM pour disposer d’accès asynchrone grâce aux files d’attente. Java Messaging Service est l’API implémentée pour les serveurs d’applications Java. On trouve aussi MQSeries chez IBM et MSMQ dans le monde Microsoft. 3. L’architecture repose sur l’exécution de composants administrés par le serveur d’applications. Ceux-ci sont soit des objets métier qui gèrent l’exécution des processus métier, soit des composants d’accès aux applications, qui jouent alors le rôle de connecteurs. Dans tous les cas, ils peuvent être facilement distribués, ce qui résout les questions de montée en charge et de tolérance aux pannes tout en améliorant la granularité de déploiement des traitements.

XML et l’eAI

• Transformation - La transformation des données XML d’une application à l’autre est effectuée au moyen de feuilles de styles XSL (eXtensible StyleSheet Language) au niveau des connecteurs ou des composants métier. La centralisation du déploiement rend cette solution particulièrement facile à maintenir et évolutive. On peut de plus mettre ainsi à profit les fortes capacités d’agrégation d’XML pour établir une communication many-to-many. • Flexibilité et évolution - La structure des documents XML peut être modifiée sans qu’il faille également modifier la logique codée dans les composants métier. Par exemple, l’ajout d’une nouvelle balise dans un document XML est transparent pour les composants existants. • Administration - Un message XML reste lisible et compréhensible même en dehors de ses applications sources et destinataires. On n’aura donc aucune difficulté à l’interpréter. 4. Tous ces éléments ont conduit des éditeurs de serveurs d’applications à proposer une offre dédiée à l’intégration alors qu’ils ne disposent pas d’une technologie de message broker. - Oracle propose Oracle Integration Server, combinaison de briques existantes : Oracle 8i pour stocker le référentiel d’intégration, JServer pour l’exécution de composants métier et JDeveloper pour leur développement, des adaptateurs applicatifs (comme le connecteur SAP, de webMethods) et un MOM (Oracle Advanced Queuing). - Microsoft propose SQL Server, le couple ASP/IIS, Visual Studio et MSMQ. - IBM propose DB2, la plate-forme WebSphere/VisualAge et MQSeries. - BEA propose la plate-forme WebLogic et Symantec Café, joints à une base de données d’un éditeur tiers. Deux applications sont plus spécifiquement dédiées à l’intégration : eLink pour l’intégration interne et WebLogic Collaborate pour l’intégration étendue. - Et il en existe de nombreux autres… De leur côté, les éditeurs traditionnels de l’EAI ont cherché à enrichir leur offre d’intégration interne ou étendue par un serveur d’applications dédié aux applications d’e-business. C’est le cas de Level 8 avec Geneva Enterprise Integrator ou de Mercator avec Web Integration Broker. Ces offres s’insèrent dans une offre d’intégration globale et répondent à la nécessité de mettre en œuvre des solutions d’e-business synchrones en « temps réel ». En effet, les plates-formes d’intégration e-business doivent aujourd’hui répondre aux besoins synchrones comme aux besoins asynchrones. Serveurs d’applications et message brokers apparaissent ainsi davantage comme des technologies complémentaires que comme des technologies concurrentes pour le système d’e-business. 5. Les connecteurs applicatifs sont généralement absents des offres reposant sur les serveurs d’applications. Il faut prévoir un développement spécifique ou s’intéresser aux outils fournis avec les progiciels, comme le Business Connector avec SAP R/3. Il faut en outre développer le moteur d’intégration, sous forme de référentiel couplé aux composants métier. Il convient de spécifier très finement l’ensemble afin d’obtenir une solution évolutive, capable d’intégrer ultérieurement d’autres applications. Certaines solutions d’intégration, telles que Roma, de Candle, fournissent une API qui implémente les fonctionnalités d’intégration depuis des composants COM (en C++ ou en Visual Basic) et Java. 6. Le choix entre plate-forme d’intégration et développement spécifique se fondera principalement sur le rapport besoin d’intégration/coût. Plus nombreuses sont les applications à intégrer, plus nombreux sont les connecteurs à implémenter, et plus élevé est le montant total du projet d’intégration. On réservera une telle architecture au développement de petits projets d’intégration, comportant un nombre restreint d’applications à intégrer à court et à moyen terme. En revanche, si vous souhaitez intégrer plus de quatre applications existantes puis, par la suite, d’autres applications, il est préférable d’envisager l’utilisation d’une plate-forme éditeur qui pilotera l’ensemble des échanges du système, et, éventuellement, de l’interfacer avec les serveurs d’applications existants. En somme, le choix d’une plate-forme d’intégration éditeur n’est pas lié à la taille de l’entreprise, mais bien au besoin d’intégration. Un exemple de projet d’intégration fondé sur un serveur d’applications et mené par Cosmosbay est détaillé plus bas. Il faut insister sur le fait qu’une telle plate-forme n’est pas le « choix du pauvre » ; au contraire, par son respect des standards et l’utilisation de technologies homogènes pour l’ensemble du système d’information, cette solution se présente comme une solution pérenne, évolutive et adaptée aux contraintes de réactivité de l’e-business.

35

EAI

De l’intégration à l’e-business / X M L e t l ’ e A I

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

GE GE

PME

GE

Entreprise pivot

GE

PME

GE GE

PME

GE

PME

GE PME

Le réseau de type moyeu et rayons classique

PME

PME

PME

Le réseau neuronal XML

GE = Grande Entreprise PME = Petite ou Moyenne Entreprise Figure 8 – Évolution des relations interentreprises

36 De plus, les capacités d’agrégation d’XML peuvent être exploitées dans le cas d’un rendez-vous entre deux processus, pour envoyer le message résultant à l’application cible. Enfin, XML assure la liaison entre les processus publics et privés de l’entreprise par l’utilisation de technologies communes dans la définition et la mise en œuvre de ces processus. Les partenaires définissent à plusieurs les étapes d’un processus métier interentreprise. Le processus est codé en XML pour en faciliter l’échange et la modélisation via un client XML. C’est le choix retenu par TIBCO avec l’acquisition de la société Extensibility et l’intégration de ses outils de conception de documents et de structures de données XML à sa plate-forme ActiveEnterprise.

XML et l’eAI

XML et B2B XML est le format incontournable dès qu’il est question d’échanges interentreprises. Avec XML, il devient aisé de transmettre des informations à un partenaire sans en connaître l’existant technologique, sans avoir à s’y adapter techniquement ni à s’y introduire de façon logicielle. En couplant faiblement les systèmes, la technologie constitue de fait un moteur et non plus un frein à l’extension des échanges. L’échange B2B s’organise aujourd’hui autour d’une entreprise pivot, qui sert de relais et pilote les transactions pour un ensemble de partenaires au moyen d’échanges normalisés par des langages fondés sur XML.

XML, langage privilégié de l’échange B2B L’industrie informatique connaît une effervescence soutenue depuis quelques temps déjà à cause de la finalisation des langages qui vont standardiser les échanges interentreprises et implémenter des plates-formes techniques capables de les supporter. Ces initiatives vont de l’élaboration de langages de normalisation de catalogues ou d’achats (e-procurement) jusqu’à la formalisation des agréments entre partenaires (avec le langage tpaML, d’IBM) ou de l’EFI (échange de formulaires informatisés). Le tableau ci-dessous récapitule les initiatives les plus importantes. Initiative

Instigateur

Type

BizTalk

Microsoft

framework XML pour l’ensemble de l’industrie et référentiel de formats d’échange

cXML

Ariba Software

e-catalog et transactions financières pour les places de marché

ebXML

Oasis et UN/Cefact

framework XML pour l’ensemble de l’industrie et référentiel de formats d’échange

eCO

consortium

framework XML pour l’ensemble de l’industrie et référentiel de formats d’échange

IOTP

IETF

commerce électronique grand public

OBI

CommerceNet (consortium)

gestion des achats (X.12)

RosettaNet

consortium

framework XML pour l’ensemble de l’industrie et référentiel de formats d’échange

xCBL

Commerce One

e-catalog et transactions financières pour les places de marché

tpaML

IBM

agréments entre partenaires commerciaux

XFDL

PureEdge

formulaires électroniques (EFI)

XFA

JetForm

formulaires électroniques (EFI)

Cette section présente les principaux organismes moteurs de cette normalisation et les initiatives qu’ils promeuvent. On constate que la quasi-totalité de ces normes d’échanges pour l’Internet sont des langages conçus à partir d’XML, lui-même conçu pour l’Internet.

B2B et EDI Il faut des intérêts communs et une volonté partagée pour parvenir à mettre en œuvre une synergie d’échange interentreprise. Il faut aussi disposer de normes et de standards pour partager des données décrites dans un vocabulaire symétriquement compréhensible par les parties impliquées. Cette idée évoque sans doute des notions familières à certains : elle est le fondement des procédures d’EDI. La complexité et la durée de déploiement de ces procédures en ont restreint la propagation à des grands comptes. L’EDI concerne à l’heure actuelle 2 % des entreprises ; c’est peu. Pour impliquer les PME et les PMI dans ces chaînes d’échange, d’autres normes, plus légères, faciles à implémenter et adaptées à l’Internet, sont requises. Idéalement, le format pivot de ces normes reposera sur XML. En ce sens, XML n’a pas pour objectif de remplacer l’EDI, mais de fournir une solution de rechange flexible et complémentaire. Ainsi, XML va permettre des échanges orientés conversation, alors que l’EDI est mieux adapté au dialogue. Plus léger, XML permet de réfléchir à l’instauration de frameworks globaux alors que l’EDI définit principalement des standards sectoriels. Le B2B apparaît donc comme un EDI léger et personnalisable, à vocation universelle.

37

EAI

De l’intégration à l’e-business / X M L e t l ’ e A I

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

xCBL, de Commerce One Commerce One (anciennement DistriVision) existe depuis 1994 (depuis 1997 en France) et participe à de nombreuses initiatives relatives à XML : membre du W3C, de l’IETF (Internet Engineering Task Force), des groupes de travail Oasis (donc eCo et ebXML), OBI (Open Buying on the Internet), RosettaNet et BizTalk. Fondateur du global trading web, une volonté d’interconnecter des e-marketplaces pour créer une place de marché globale, Commerce One a pour vocation de mettre en relation acheteurs et vendeurs. Commerce One est à l’origine d’un langage d’échange B2B reposant sur XML et nommé xCBL. La spécification actuelle, xCBL 2.0, permet de créer des documents XML dédiés à l’échange B2B et fournit des passerelles avec les échanges EDI traditionnels. xCBL est gratuit et disponible sur les référentiels en ligne tels que BizTalk ou xml.org ainsi que sur le référentiel maison, MarketSite. Commerce One propose BuySite, un logiciel d’e-procurement, qui gère l’émission des bons de commande, MarketSite, technologie d’e-marketplace qui gère la consolidation des catalogues et les transactions, et MarketBuilder, version allégée de MarketSite permettant à des communautés spécialisées de construire leurs portails verticaux sans devoir se charger de leur gestion technique.

38

Enfin, Commerce One travaille actuellement avec Rational Software à la formalisation d’une méthode UML (Unified Modeling Language) adaptée à l’échange B2B de documents à base de messages XML. Pour en savoir plus, visitez : • Commerce One : http://www.commerceone.com ; • MarketSite : http://www.marketsite.net.

OBI, de CommerceNet Lancé en avril 1994, CommerceNet est un consortium à but non lucratif regroupant aux États-Unis plus de 600 entreprises et organisations qui se proposent de « transformer l’Internet en une place de marché électronique ». Le but est de développer des standards ouverts pour l’achat sur Internet. L’initiative de CommerceNet est comparable à celle de Commerce One. Le consortium OBI (Open Buying on the Internet) est le résultat des travaux de CommerceNet. Les travaux, débutés en septembre 1997, ont abouti début mai 2000 à la spécification OBI 2.1, fruit du travail conjoint d’acteurs comme American Express, Barnes and Noble, Lockheed Martin, Microsoft, Netscape et d’un ensemble d’experts des achats et du commerce en ligne. L’objectif est la réduction du coût des transactions d’achat sur Internet grâce à l’automatisation et à la désintermédiation.

XML et l’eAI

OBI définit un simple format de catalogue et un protocole de commandes. Les fonctionnalités incluent : • une méthodologie pour utiliser des applications EDI avec des systèmes compatibles OBI ; • des processus d’accès standardisé aux catalogues électroniques ; • des formats de données standard pour décrire les données des commandes et les transmettre d’un partenaire à l’autre ; • des mécanismes standard de sécurité, d’authentification et de non-répudiation ; • le support des transactions internationales en devises. La version 3.0 intégrera XML dans les bons de commande et les bons de livraison. Pour en savoir plus, visitez : • CommerceNet : http://www.commercenet.com ; • OBI : http://www.openbuy.org.

eCo, de CommerceNet Le système eCo a été initié en juillet 1998 par CommerceNet. Son objectif est l’établissement d’une plate-forme autorisant l’interopérabilité logicielle, étape indispensable à la mise en œuvre des transactions électroniques. Les domaines couverts sont : • les services métier ; • les termes métier ; • les services de conformité et de validation ; • les rôles et les activités dans l’e-commerce ; • les standards de paiement ; • les mécanismes de sécurité ; • le contexte de workflow et de traitement des processus ; • les types d’informations impliqués dans une transaction. Les travaux effectués sont incomplets et n’ont pas eu un grand impact sur les entreprises. Ils ont néanmoins le mérite de servir de base de travail aux groupes de travail ebXML depuis septembre 1999.

ebXML, de l’UN/Cefact et Oasis L’UN/Cefact est une entité des Nations unies dont les directives incluent le développement stratégique et technique du commerce électronique et de l’e-business. Oasis (Organization for the Advancement of Structured Information Standards) est quant à lui un consortium à but non lucratif. Son objectif est la promotion des formats non propriétaires fondés sur tout standard permettant le traitement de l’information structurée, tels que SGML et XML. Les membres d’Oasis sont des spécialistes de ces technologies. Oasis regroupe un grand nombre d’acteurs : certains sont « institutionnels » (IBM, Informix, Microsoft, Oracle, SAP, Sun Microsystems), d’autres sont issus du monde de l’EAI et du B2B (Bluestone, Extricity, Mercator, Netfish) ou du monde de l’EIP ou de la gestion documentaire (ArborText, DataChannel, Documentum, Sequoia, etc.). Pour en savoir plus, visitez : • Oasis : http://www.oasis-PGP/MIME ; • Référentiel : http://www.xml.org. Pour minimiser la prolifération des initiatives et fédérer le développement du commerce électronique, l’UN/Cefact et Oasis ont lancé ebXML (electronic business XML). ebXML est une initiative ouverte et indépendante visant à établir un framework technique et sémantique global articulé autour du métalangage XML. Les six premiers mois de travaux ont abouti à l’approbation des sujets de spécifications et à une démonstration de la viabilité du concept (tests de routage des messages ebXML).

39

EAI

De l’intégration à l’e-business / X M L e t l ’ e A I

Cette initiative permet d’y voir plus clair dans ce monde qui gravite autour d’XML et de la « fusion » XML/EDI. Cent vingt entités ont porté leur soutien à ce projet, créé en septembre 1999, qui s’est donnée 18 mois pour atteindre ses objectifs. Applications

Integration

UN

Technology

W3C

ebXML

XML Steering Committee

CEN

OASIS

Working Groups

Sectors

Semantic Repositiories

National Bodies

Commerce One

ISO TC 154 BSR

Editors

BizTalk, etc.

Figure 9 – Groupes de travail autour d’ebXML

ebXML reprend le travail effectué par le framework eCo Architecture, qui concurrence en quelque sorte des projets tels que BizTalk, mais qui est plus universel car détaché des considérations propriétaires. ebXML compte favoriser le développement de modèles de documents directement exploitables par l’industrie. L’association annonce par ailleurs la constitution d’un groupe d’experts internationaux chargés de décliner les spécifications techniques de futurs formats XML sectoriels. Le public visé va de la TPE (très petite entreprise) à la multinationale.

40

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 petites entreprises ; • de faciliter le support multilingue. Cet énoncé montre une concordance évidente entre des objectifs ambitieux (démarche internationale désireuse d’intégrer tout type d’acteur) et la présence d’XML. ebXML vise à englober toutes les initiatives pour définir une architecture globale incluant : • les messages ; • les processus ; • les traitements ; • des répertoires et des référentiels pour stocker les exigences spécifiques aux industries.

XML et l’eAI

Huit facteurs d’interopérabilité sont ainsi définis : • processus métier (exécution d’une transaction métier) ; • sémantique ; • vocabulaire : connexion des mots à des sens sémantiques ; • encodage des caractères : utilisation d’Unicode ; • expression : définition des éléments de structure semblables ; • sécurité ; • protocole de transfert de données ; • réseau. ebXML est une initiative ouverte, publique et indépendante. Il est encore trop tôt pour déterminer si ebXML remplira tous les ambitieux objectifs fixés. L’enjeu n’est rien de moins qu’un standard international qui recueillera le soutien de nombreuses entreprises de par le monde. ebXML est une formidable chance pour le commerce électronique et l’initiative la plus prometteuse en cours d’élaboration. Pour en savoir plus, visitez http://www.ebxml.org.

BizTalk, de Microsoft Avec BizTalk, Microsoft aspire à créer un framework du même type qu’eCo ou qu’ebXML. Ce projet est aussi une démarche visant à présenter simultanément aux entreprises un framework XML, un référentiel et un logiciel B2B. La version 2.0 du framework gère la création et la publication des formats d’échange par HTTP et SMTP, soit : les spécifications d’un format d’enveloppe et de routage de messages XML, la compatibilité avec le protocole SOAP 1.1 (Simple Object Access Protocol) et Multipart MIME (Multipurpose Internet Mail Extensions). Le référentiel en ligne centralise les formats XML reconnus par l’industrie. Cette initiative concurrente de xml.org fournit un corpus d’échange B2B utilisant la technologie XML-Data. Le prolongement de cette démarche est l’implémentation d’un serveur d’échange B2B, BizTalk Server, dédié au développement, à l’exécution et à l’administration des processus d’entreprise distribués et qui s’interface au mieux avec l’architecture DNA de Windows 2000.

41

EAI

De l’intégration à l’e-business / X M L e t l ’ e A I

BizTalk Server propose les éléments suivants : • Outils graphiques de développement – BizTalk Editor et BizTalk Mapper sont dédiés au développement et à la transformation des schémas XML et des documents métier. • Moteur d’échange de documents – Documents à base de formats XML, mais aussi EDI (Edifact et X.12), ainsi que de fichiers plats. • Moteur robuste et sécurisé – Sécurité PKI, signatures digitales et encryptage. • Adaptateurs applicatifs. BizTalk est soutenu par un ensemble de consortiums et d’initiatives B2B, comme l’OAG, SAP ou Commerce One, qui proposent principalement des schémas pour le référentiel en ligne. Des utilisateurs finaux se joignent également au projet (Boeing, BP/Amoco) et participent aux spécifications. Pour en savoir plus, visitez : • Microsoft : http://www.microsoft.com ; • BizTalk : http://www.biztalk.org.

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

e-APPLICATION

PROCESS METIER

PROCESS eBUSINESS

DIALOGUE

PIP

GRAMMAIRE

FRAMEWORK

MOTS

DICTIONNAIRES

ALPHABET

HTML

RosettaNet

42

TELEPHONE

XML

SON

INTERNET

Echange professionnel entre personnes

Echange professionnel entre systèmes informatiques

Figure 10 – Couches (layers) de RosettaNet

RosettaNet accorde autant d’importance à la définition de standards de données qu’à la définition de standards de processus. Le RNIF (RosettaNet Implementation Framework) spécifie le cadre d’implémentation des standards de processus et de données. Les travaux sont orientés vers la définition de dictionnaires commerciaux et techniques. Des propriétés communes sont définies pour chaque produit (destinées à faciliter leur comparaison financière et technique), pour chaque partenaire et pour les transactions. Les PIP (Partner Interface Processes) définissent les séquences d’étapes nécessaires pour compléter un processus B2B (le passage d’un ordre de commande, par exemple). Ils déterminent aussi l’échange d’information et les transactions générées par le franchissement de chacune des étapes d’un processus. Ils définissent enfin les processus publics et les données associées nécessaires pour conduire des transactions électroniques sur Internet. RosettaNet utilise UML et OCL (Object Constraint Language) pour définir les processus métier B2B, et XML pour décrire les formats de données.

XML et l’eAI

En février 2000, RosettaNet a publié des spécifications détaillées pour différents PIP. On trouve par exemple la distribution de nouvelles informations produit (PIP2A1), la recherche d’informations techniques (PIP2A5) ou la gestion d’ordres de commande (PIP3A4). RosettaNet est actuellement mis en œuvre dans le secteur des technologies de l’information (notamment par Dell qui l’a utilisé pour fédérer toute sa chaîne d’échange fournisseurs) et dans l’industrie des composants électroniques. RosettaNet se pose ainsi comme l’initiative la plus directement concurrente de ce qui existe aujourd’hui dans le monde de l’EDI. Pour en savoir plus, visitez http://www.rosettanet.org.

Autres initiatives AL3 (Automation Level 3) est une initiative conduite par Acord, organisme à but non lucratif chargé de définir des standards dans le monde de l’assurance. Swift (Society for Worldwide Interbank Financial Telecommunication) est une des plus célèbres organisations de ce domaine ; elle définit un standard pour le monde de la banque et de la finance. Quelque 7 000 institutions financières réparties dans 200 pays en sont membres. HL7 (Health Level 7) est le protocole standard utilisé par le monde de la santé. Enfin, l’OAG a publié 122 DTD XML pour différents types de transactions.

En résumé… Les standards sont des pièces indispensables du puzzle B2B. Cependant, ils sont longs à concevoir et à implémenter. Certains sont déjà dépassés lorsqu’ils arrivent sur le marché : les entreprises sont obligées d’agir avant qu’ils soient disponibles et constatent conséquemment l’apparition de nouveaux besoins. Les standards d’échange doivent donc être flexibles ; le support d’XML conduit justement à cette flexibilité. Les processus doivent aussi être évolutifs : des référentiels en ligne peuvent permettre de bénéficier rapidement de l’évolution d’un standard. Ils doivent enfin pouvoir être personnalisés si plusieurs partenaires trouvent un accord dans le cadre de leurs échanges. Il importera alors de conserver une compatibilité entre le format dérivé et le standard d’origine. Certaines entreprises pourront ainsi apporter aux standards les améliorations qu’elles jugent nécessaires, conférer un surcroît de compétitivité à leurs échanges et conserver cet avantage concurrentiel tout en respectant les normes internationales en vigueur.

Une architecture alternative d’EAI bâtie sur XML Cosmosbay a été consulté au début de l’année 2000 pour concevoir, élaborer et réaliser la plate-forme intranet-extranet de l’un de ses clients. Il s’agissait d’une grande entrerprise du domaine du matériel électrique, dotée d’un grand nombre de systèmes et de sources de données. Le besoin fort était de réutiliser les informations présentes dans les sources de données suivantes : • un progiciel de CRM nommé GRC (gestion de la relation client) ; • un ERP (SAP R/3) ; • une application spécifique qui gère le catalogue produits. Ces données doivent pouvoir être consultées, modifiées et enrichies par les collaborateurs du groupe. Le choix d’une interface de type web (un portail d’entreprise) a été fait. Les données sont ensuite mises en forme à destination des partenaires du groupe (installateurs, distributeurs, revendeurs) pour obtenir des informations sur les produits et passer des commandes en ligne. Un front-office d’e-commerce de type extranet a été envisagé, avec l’objectif pour notre client de se poser comme fournisseur privilégié de ses partenaires. L’architecture qui a été retenue ne repose pas sur un message broker utilisant un MOM mais sur un serveur d’applications utilisant HTTP comme middleware. Plusieurs raisons président à ce choix :

43

EAI

De l’intégration à l’e-business / X M L e t l ’ e A I

• Le petit nombre d’applications à intégrer. • Un nombre élevé d’échanges asynchrones. • Les données dont la disponibilité doit être permanente (celles du front-office Internet) sont dupliquées dans une base de données qui sert de référentiel de synchronisation. Avant de détailler davantage cette architecture, nous allons l’illustrer par une représentation graphique.

R E F E R E N T I E L

GRC

CONNECTEUR

X M L

ERP

CONNECTEUR

X M L

DEVT SPECIF

CONNECTEUR

X M L

Serveur de transactions

WORKFLOW

XML/ HTTP

Journal

Clients

Composant métier

X M L

Produits

Composant métier

X M L

Acteurs

Composant métier

X M L

W

Serveur de Présentation

E B

FRONT OFFICE

XML/HTTP (SSL)

Pages actives

Données

Métier

Applications CLIENTES FRONT OFFICE e-Commerce EXTRANET / INTRANET

Présentation

Figure 11 – Architecture EAI retenue

44

Il s’agit clairement d’une architecture à trois niveaux (3-tiers) avec une problématique d’intégration. Nous allons nous arrêter en détail sur chacun des éléments qui la composent : les applications front-office, les sources de données, le référentiel de synchronisation et le moteur d’intégration.

Applications front-office Serveur de Présentation FRONT OFFICE

W E B

Applications CLIENTES FRONT OFFICE e-Commerce

Pages actives

Figure 12 – Front-office

EXTRANET / INTRANET

XML et l’eAI

La partie serveur front-office (à gauche) et les applications clientes (à droite) communiquent via Internet et HTTP ; il s’agit d’une configuration désormais traditionnelle : HTTP y tient la place qu’il occupe au sein de millions de serveurs d’applications de par le monde. Dans une logique d’intégration, le front-office Internet est une application comme les autres, au même titre que SAP ou que le progiciel de gestion de la relation client. Si elle figure à part dans notre schéma d’architecture, c’est parce qu’elle représente l’objectif dans lequel cette architecture d’intégration a été mise en place et qu’elle illustre parfaitement les raisons qui poussent les entreprises à se tourner aujourd’hui vers des solutions d’intégration.

Sources de données On retrouve l’ensemble des sources de données de l’entreprise : le progiciel de gestion de la relation client, l’ERP et le développement spécifique.

R E F E R E N T I E L

GRC

CONNECTEUR

X M L

ERP

CONNECTEUR

X M L

DEVT SPECIF

CONNECTEUR

X M L

Figure 13 – Sources de données

Ces applications sont exécutées soit sur des plates-formes Windows NT, soit sur des plates-formes Sun Solaris. Un serveur HTTP et un serveur d’applications ont été placés sur chaque plate-forme : IIS sur la plate-forme Microsoft et le couple Apache/JServ sur la plate-forme Unix. Chaque bloc connecteur de la figure ci-dessus est donc en réalité un composant exécuté et géré par ces serveurs d’applications. Ce composant connaît la logique de transformation des données qui lui parviennent. Il n’y a donc pas, comme dans le cas d’une plateforme d’intégration gérée par un message broker, de traduction des données d’un format natif dans un autre format natif. Ici, tout format natif est systématiquement converti en XML, format pivot des échanges du système d’information ; ce message XML est ensuite envoyé au connecteur branché sur l’application destinataire, qui transforme ce format XML en format natif (via une feuille de styles XSL, par exemple) avant de le transmettre à l’application. Dans cette architecture, ce sont les connecteurs qui effectuent la transformation. Ils disposent de l’intelligence de transformation, qui n’est pas centralisée au sein d’un référentiel sur une machine unique. On retrouve ce principe dans les plates-formes d’EAI du marché qui savent dupliquer et distribuer le référentiel central vers des serveurs distants, comme Roma, de Candle, ou e*Gate, de STC. Le connecteur SAP, fourni en standard, est une solution packagée nommée Business Connector qui code sa propre logique de transformation ; il permet d’économiser du temps de développement sur le projet. Dans notre architecture, les traitements sont synchrones sur HTTP, mais rien n’interdit d’adjoindre une technologie de files d’attentes (ou des échanges SMTP) sur nos serveurs d’applications pour obtenir des traitements asynchrones. Les connecteurs sont des composants capables de gérer deux types de flux de données : XML d’un côté, natif de l’autre. Ces composants peuvent facilement être distribués sur différentes machines en vue de gérer un autre aspect important : la montée en charge.

45

EAI

De l’intégration à l’e-business / X M L e t l ’ e A I

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

WORKFLOW

Serveur de transactions

Journal

Clients

Composant métier

X M L

Produits

Composant métier

X M L

Acteurs

Composant métier

X M L

Figure 14 – Moteur d’intégration

Oracle 8i sert à la fois de base de données pour le référentiel de synchronisation et de moteur d’intégration exécutant des composants Java chargés de réaliser l’intégration. Les messages XML en provenance des connecteurs applicatifs déclenchent des événements au sein des composants métier gérés par JServer. Ces composants alertent le moteur Oracle Workflow du début de la transaction. Le moteur de workflow se charge alors de piloter la transaction, en répercutant les messages XML dans les applications qui ont besoin de ces données pour poursuivre le processus métier. Enfin, un serveur de transactions permet de reprendre une transaction qui a échoué ou de déterminer la cause de son échec.

Référentiel de synchronisation 46

Toutes les données nécessaires au fonctionnement du front-office et déjà présentes dans le système d’information sont dupliquées dans Oracle 8i ; l’application de front-office fonctionne avec les données qui sont contenues dans ce référentiel, mais jamais directement avec des données extraites de l’ERP, du CRM ou de l’application spécifique. Aucun MOM n’apparaît dans notre schéma. Tous les échanges reposent sur des messages XML véhiculés par HTTP. L’ensemble des échanges est synchrone, ce qui, nous l’avons vu, peut se révéler contraignant dans une logique d’intégration. Ces choix ne sont pas en contradiction avec la logique d’intégration mais permettent au contraire de s’affranchir des contraintes inhérentes au Web dans le cadre de la construction d’un système B2B. En effet, des systèmes tels que SAP dans notre cas, mais aussi tous les mainframes, pour ne citer qu’eux, font l’objet d’opérations de maintenance et de traitements batch à des heures où les utilisateurs de ces systèmes (les collaborateurs de l’entreprise) ne s’en servent pas. Pendant ces opérations, ces systèmes sont normalement indisponibles. Or, un internaute est susceptible de naviguer et d’utiliser l’application à toute heure du jour et de la nuit, y compris le week-end. Le front-office doit rester disponible en permanence. Pour répondre à cette nécessité, les données du front-office sont stockées dans une base de données Oracle 8i dédiée. Il apparaît donc important de synchroniser au plus tôt les données entre les sources, d’où la nature synchrone des échanges et l’utilisation d’un middleware adapté à ce besoin. L’emploi de HTTP nous permet d’utiliser un middleware unique employant un format de messages métier unique : XML. Le référentiel Oracle, base de données du front-office Internet, devient également un référentiel de synchronisation.

XML et l’eAI

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

47

EAI

De l’intégration à l’e-business / M a r c h é d e l ’ E A I e t o f f r e s d e s é d i t e u r s

C H A P I T R E

5 Marché de l’EAI et offres des éditeurs Panorama du marché de l’EAI Quelques chiffres IBM, le leader, détient 20 % des parts de marché. Les acteurs suivants sont Neon, Mercator, Tibco et webMethods, tous quatre autour de 10 %. Les meilleures progressions du premier semestre 2000 sont celles de BEA, GEIS (General Electric Internet System), STC et Vitria. Plus de 30 % du marché restent cependant détenus par des acteurs figurant hors du top 10. Ceci garantit une compétition forte et une progression technologique des offres importante. Aujourd’hui, il n’y a pas de plate-forme d’intégration optimale, mais des plates-formes qui répondent à des besoins d’intégration divers : • Intégration de données ou modélisation des processus métier ? • Volume des données à échanger. • Nombre et type des applications à intégrer. • Nécessité d’échanges externes B2B ? Type de ces échanges (support des initiatives XML). • Site centralisé ou géographiquement réparti (moteur d’intégration conçu pour un système distribué) ? Les services offerts autour de la technologie (méthodologie, conseil, formation, support technique) ont également une grande importance.

48

Tendances Une tendance marquée de ce domaine est la consolidation du marché. La notion d’intégration s’étant considérablement élargie ces derniers temps, l’enrichissement rapide d’une offre s’effectue par croissance externe plutôt que par de nouveaux développements techniques. Les acquisitions récentes d’Active Software par webMethods et d’OnDisplay par Vignette illustrent ces mouvements. Level 8 a construit la dernière version de son offre en rachetant XIPC, Seers et Template Software. Par le passé, Neon Software a acquis VIE System, SLI International AG, MicroScript et ConvoyCorporation. Mercator a absorbé en 1999 Braid Systems et Novera. Cette tendance permet au client de ne pas voir les acteurs se multiplier lors de la mise en œuvre d’un projet global d’intégration. Le client veut en effet des solutions end-to-end. Le rapprochement des acteurs leur permet de répondre plus rapidement aux attentes des clients, de maintenir les supports techniques existants et, temporairement, les versions de produits. D’autre part, la constitution d’acteurs de taille plus importante garantit plus sûrement leur pérennité.

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 permet aux éditeurs actuellement présents sur le marché de bâtir des offres globales et robustes à l’heure où des acteurs « institutionnels » disposant de moyens élevés, tels qu’Oracle ou Sun Microsystems (via Forte), font leur entrée. Enfin, des jeux de partenariats se constituent. Par exemple, Neon s’est allié à BEA, à BroadVision, à Commerce One et à Microsoft et collabore toujours avec IBM pour le développement de MQIntegrator. D’une manière générale, les partenariats sont nombreux, y compris entre les acteurs de l’eAI, qui travaillent à faire communiquer leurs plates-formes entre elles.

Les offres Pour cette étude, nous avons préféré vous présenter les acteurs spécifiques au monde de l’EAI et du B2B plutôt que les solutions des grands éditeurs « institutionnels » de l’industrie informatique. Nom de l’éditeur

Site web

Offre

Candle

http://www.candle.com

Roma

Constellar

http://www.constellar.com

Constellar Hub

Level 8

http://www.level8.com

Geneva

Mercator Software

http://www.mercator.com

Mercator

Neon Software

http://www.neonsoft.com

e-Biz Integrator

STC

http://www.stc.com

e*Gate

Tibco

http://www.tibco.com

ActiveEnterprise

Viewlocity

http://www.viewlocity.com

AMTrix

Vignette-OnDisplay

http://www.ondisplay.com

eIntegrate

webMethods

http://www.webmethods.com

ActiveWorks B2B Integration Server

Nous ne pouvons bien sûr pas présenter tous les acteurs qui émaillent le marché de l’EAI. Certains n’ont pu répondre à temps à nos questions ; nous intégrerons probablement leur offre dans une prochaine version de ce livre blanc. Nous avons exclu les éditeurs non représentés en France pour des raisons difficultés de relations clients dans les phases de conseil, de formation et de support au produit. Nous avons néanmoins tenu à citer ces acteurs pour information, et nous vous invitons à aller à la rencontre de leurs solutions en visitant leurs sites. Certaines offres seront présentées en détail dans les prochaines versions de ce livre blanc. Nom de l’éditeur

Site web

Offre

Bluestone Software

http://www.bluestone.com/xml/

XML Server

CrossWorlds

http://www.crossworlds.com

CrossWorlds

Extricity Software

http://www.extricity.com

Extricity AllianceSeries

IBM

http://www-4.ibm.com/software/ts/mqseries

MQSeries

Forte

http://www.forte.com

Fusion, Forte for Java

GEIS

http://www.gegxs.com

Global eXchange

Netfish

http://www.netfish.com

XDI

Saga

http://www.sagasoftware.com

Sagavista

Sopra

http://www.sopra.fr

Règles du jeu

Vitria Technology

http://www.vitria.com

BusinessWare

Organisation des fiches produits La première section est consacrée à une présentation générale de la société et aux coordonnées du siège social, des bureaux français et du contact. Quelques chiffres ainsi qu’un historique sont fournis.

49

EAI

De l’intégration à l’e-business / M a r c h é d e l ’ E A I e t o f f r e s d e s é d i t e u r s

Le produit d’intégration est ensuite présenté, dans ses grandes lignes d’abord, puis brique par brique en respectant le modèle EAI que nous avons présenté. Une offre d’EAI est un package riche qui comprend différents outils aux fonctionnalités bien distinctes et aux finalités bien définies : pour chaque couche, nous indiquons le produit correspondant dans l’offre de l’éditeur. Voici ci-dessous, à titre d’exemple, le modèle EAI de Candle :

B2B Processus

Roma Workflow Access

Moteur d'intégration

Roma Broker

Composants Données

Application Environment Connectors

Transport

MQSeries / MSMQ Figure 15 - Modèle EAI de Candle

Les briques natives de la technologie de l’éditeur figurent en gras, les briques fournies avec la solution mais provenant de technologies 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 :

50

Montée en charge

Mécanismes natifs prévus pour faire face à des pics de charge ponctuels ou à des déplacements de plus longue durée de la charge.

Transactions et moniteurs transactionnels

Mécanismes natifs qui permettent de définir des transactions longues ou les connexions possibles à un moniteur transactionnel.

Administration

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

Tolérance aux pannes

Mécanismes natifs pour pallier les déficiences du système ou du réseau.

Sécurité

Mécanismes de sécurité natifs destinés à protéger les échanges internes et les échanges B2B.

XML

Rôle joué par XML dans la plate-forme d’EAI : simple format de données disposant de son connecteur, langage commun à l’ensemble du système, etc.

Ouverture

Connexions possible de la plate-forme à des outils capables d’en accroître la qualité de service : agents réseaux SNMP, annuaires LDAP, composants métier existants, etc.

Portabilité

Plates-formes pour lesquelles la solution est disponible.

Productivité de développement

Rapidité de mise en œuvre de la solution d’intégration.

Déploiement

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

Formation

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

Marché de l’EAI et offres des éditeurs

Candle Siège social

Bureaux français

201, N. Douglas St

13, avenue de la Porte-d’Italie

El Secundo, CA 90245

75013 Paris

Tél. : +1 310 535 3600

Tél. : +33 153 616 000 Fax : +33 153 610 515

Contacts : Jean-Christophe Laplace, MQ Business Developer Manager ([email protected]). http://www.candle.com

Présentation de la société Création Créée en 1976 par Aubrey Chernick.

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

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

Historique Candle est surtout connu dans le monde du mainframe IBM comme éditeur de la suite Omegamon, solution d’aide à l’optimisation de la disponibilité et de la performance des systèmes. Développement de MQSeries pour Tandem. Accord international en 1998 : Omegamon est fourni en version bridée avec MQSeries.

Architecture technique du produit Étant le premier revendeur mondial de MQSeries, Candle s’est servi de sa forte compétence en middlewares (mise en avant comme critère fondamental d’une intégration d’applications réussie) pour monter dans le train de l’EAI avec la suite Roma. Sortie en 1997, Roma en est aujourd’hui à la version 3. Candle a récemment choisi de renommer cette suite CandleNet e-business Platform, tout en précisant qu’elle repose toujours sur la technologie Roma. Le produit est aujourd’hui essentiellement axé sur une logique d’EAI interne. L’architecture se présente sous forme d’une business services platform : elle interconnecte des « composants » (les applications) fournissant des services. Sa force principale réside dans son ouverture à un ensemble de standards du marché. Des API permettent de faire de Roma une plate-forme d’intégration au cœur d’une architecture pilotée par des serveurs d’applications. C’est donc la nature du système d’information qui définit la place de Roma et non l’inverse.

51

EAI

De l’intégration à l’e-business / M a r c h é d e l ’ E A I e t o f f r e s d e s é d i t e u r s

Le modèle EAI de Candle

B2B Processus

Roma Workflow Access

Moteur d'intégration

Roma Broker

Composants Données

Application Environment Connectors

Transport

MQSeries / MSMQ Figure 16 - Modèle EAI de Candle

B2B La localisation géographique des applications étant transparente (celles-ci sont déclarées dans un annuaire), il est possible de se connecter à des applications distantes chez des partenaires. Roma F/S Access assure une connexion au réseau financier Swift.

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

Moteur d’intégration : Roma Broker Roma Broker gère le routage et la transformation. La solution peut être interfacée ou gérée par d’autres message brokers du marché : ceux de Neon, de Mercator et de Cognitive Systems.

52

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’administration et de configuration est développée en Java pour des raisons de portabilité. L’administration du système est réalisée par CandleNet Application Manager, qui s’occupe de la reprise des transactions, de la montée en charge, du suivi des performances et de la remontée des erreurs. L’ensemble est accessible depuis une interface graphique. CandleNet Broker Access assure la connectivité au message broker MQIntegrator, de Neon et IBM, et à celui de Mercator.

Données : Application Environment Connectors Les connecteurs applicatifs sont surtout tournés vers le middleware, les mainframes et les progiciels (SAP) : • SGBD – ODBC, Lotus Notes ; • ERP – SAP (récupération des iDoc), PeopleSoft ;

Marché de l’EAI et offres des éditeurs

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

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

53

EAI

De l’intégration à l’e-business / M a r c h é d e l ’ E A I e t o f f r e s d e s é d i t e u r s

Synthèse Montée en charge

Définition d’une pondération (cost) sur chacun des BSP pour déterminer sur lequel on équilibre. Définition des nombres d’instances minimal et maximal de Business Processes. Récupération d’alertes de produits de tuning pour agir sur la disponibilité des services en dynamique, sinon nombre d’instances fixes. Distribution des files d’attente et des connecteurs applicatifs.

Transactions et moniteurs transactionnels

Pas de gestion de transactions longues, mais sait prévenir par envoi de messages qu’une transaction n’a pu arriver à terme. En effet, certaines actions ne peuvent subir de rollback étant donné la nature asynchrone des échanges. Roma est néanmoins compatible avec les moniteurs transactionnels XA (CICS, Tuxedo) : ce qui est déjà coordonné le reste, on se repose sur les architectures existantes.

Administration

CandleNet Application Manager fournit à l’utilisateur une interface graphique centralisant tous les services d’administration souhaitables : audit, surveillance et remontée des erreurs. Candlelight est un freeware qui présente les temps de traitement et de transport des messages, graphiquement et sous forme de fichiers de tableur.

Tolérance aux pannes

La tolérance aux pannes est assurée par les capacités de réplication en local du référentiel Roma Directory.

Sécurité

Fourniture d’une offre de sécurisation MQSeries. Cryptage, authentification, certification 128 bits. InLine Service permet de définir les niveaux de sécurisation sur les BSP.

XML

Le Metadata Repository permet de définir les conversions des messages en XML et vice versa. C’est un data mapper qui définit les formats de conversion. Un parseur intégré valide les documents au regard de DTD. Cette composante de Roma ne nécessite pas de passer par un message broker.

Ouverture

À noter : la possibilité de s’interfacer avec d’autres message brokers, voire à utiliser comme message broker unique une technologie non-Candle (MQIntegrator, Neon ou Mercator). Accès aux API disponibles en C, C++, Java, ActiveX. Roma peut être utilisé comme un composant adressable depuis Visual Basic ou Powerbuilder. Référentiel reposant sur une structure LDAP. Ouverture aux agents SNMP.

Portabilité

Disponible sous MVS, Windows NT et 2000, HP, SUN, AIX, AS/400. L’interface graphique de configuration et d’administration est développée en Java, donc portable.

Évolutivité

Une nouvelle application est facile à référencer dans Roma (localisation physique, type de MOM utilisé, procédures d’audit, de suivi, etc.). Développement de connecteurs par le client ou par une société tierce.

Productivité de développement

Toute la configuration s’opère via une interface graphique. Toute application peut se « plugger » sur les API Roma qui permettent d’envoyer et de recevoir des messages. Le toolkit procure une économie de 70 % du temps de développement des connecteurs.

Déploiement

Référentiel centralisé répliqué automatiquement et connecteurs applicatifs distribués sur les machines distantes.

54

Les files d’attente sont réparties. On peut demander au produit de générer automatiquement des files ou de s’appuyer sur la configuration de files déjà existantes, mais on ne prend pas en charge la supervision. Formation

La connaissance de MQSeries est un bon prérequis pour démarrer facilement avec le produit. On peut alors prendre le produit en main en moins de 2 jours. Un cursus de formation est mis en place en France. L’intégralité du cursus dure 15 jours : développement, installation, workflow, XML, Object Access, architecture et conception des applications MQ.

Marché de l’EAI et offres des éditeurs

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

Présentation de la société Création Créée en 1995 par Brian Donnelly.

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

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

Présentation du produit Constellar Hub 3.5e est le produit actuellement distribué en France. Constellar Hub répond à des besoins d’EAI spécifiques, liés à l’intégration performante de gros volumes de données. Cette intégration est fondée sur une communication many-to-many des sources de données et sur une planification fine des tâches. L’accent est mis sur la robustesse du produit, sur ses aptitudes à la montée en charge (6 Go par heure) et sur sa flexibilité, et moins sur une gestion des processus métier. En cela, l’incorporation d’un moteur de workflow n’est pas à l’ordre du jour, même si l’outil est capable de modéliser des règles métier assez complexes. Cela se vérifie par une percée dans le domaine de la banque d’affaires (dont les règles de gestion sont par essence très compliquées) et chez les opérateurs de télécommunications (pour des questions de volume). Les start-up qui ont des contraintes fortes de rapidité de mise en œuvre et de robustesse trouveront également en Constellar Hub un produit répondant à leur attente. Constellar Hub incorpore un volet décisionnel – Warehouse Builder – qui permet de définir et de reprendre des schémas de data warehouses et de data marts, avec agrégation complète ou partielle des sources de données, et de les poster vers différents systèmes décisionnels, dont la liste est fournie ci-dessous, dans la description technique du produit.

55

EAI

De l’intégration à l’e-business / M a r c h é d e l ’ E A I e t o f f r e s d e s é d i t e u r s

Le modèle EAI de Constellar B2B

Transformation Manager

Processus Moteur d'intégration

Transformation Manager

Composants

Packages Oracle

Données

Metadata Manager + Adapters

Transport Figure 17 - Modèle EAI de Constellar

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

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

Moteur d’intégration : Transformation Manager Transformation Manager permet de constituer des interfaces (couplage logique n-n entre données sources et cibles), les traitements de transformation des données et les processus de remontée des erreurs de chacune des phases de l’intégration (le cycle de transformation en définit cinq : grab (collecte), extract, transform, export et send). Les règles de transformation et les règles de gestion sont stockées dans un référentiel Oracle 7.3.4, 8 ou 8i.

56

Les données sont systématiquement remontées en base de données avant transformation et, si besoin, agrégées. Les sources hétérogènes peuvent ainsi être jointes (par jointure relationnelle) et il devient possible, en s’appuyant sur les capacités natives d’Oracle, de traiter de gros volumes de données. Transformation Manager est une interface graphique qui facilite l’administration grâce au suivi : • des erreurs (avec conseil de correction et consultation des valeurs de cible) ; • des tâches qui incorporent les flux de données ; • des performances. Grâce au produit LiveInterface, d’IntelliCorp (partenaire de Constellar), Transformation Manager centralise de façon conviviale les erreurs issues de SAP R/3. D’une manière générale, le produit centralise toute l’administration, y compris Parallel Server, d’Oracle, ou Warehouse Builder.

Marché de l’EAI et offres des éditeurs

Un scheduler (outil de planification) permet ensuite de déterminer les lancements des tâches définies. Il a une partie cliente sous Windows NT et serveur sous Unix. Le scheduling peut être partitionné sur chacune des phases. Metadata Manager est un outil de développement qui sert à définir le référentiel de production (règles de transformation et règles métier). En production, seul Transformation Manager est utilisé quotidiennement.

Composants : packages Oracle Interfaçage avec des programmes PL/SQL ou Pro*C pour réutiliser des règles métier déjà existantes ou ajouter de nouvelles intelligences applicatives.

Données et applications : Metadata Manager + Adapters Metadata Manager permet de consulter les catalogues de bases de données ou les repositories des progiciels. Les connecteurs existants sont non intrusifs. Ils permettent la lecture dynamique des référentiels des progiciels et des bases de données concernées. Il existe des connecteurs source (extraction de données) et des connecteurs target (cibles). • SGBD – Interrogation native pour Oracle, via ODBC pour Sybase, Informix et Microsoft. • ERP – PeopleSoft, Siebel, SAP, Oracle Applications. Pour SAP, une solution développée conjointement par Constellar et Intellicorp (partenaires technologiques de SAP) sur leur produit LiveInterface gère l’intégration technique et fonctionnelle, avec gestion des exceptions (remontée des erreurs vers le hub Constellar). • Mainframes – Reprise des description de données des fichiers « descendus » des mainframes. Capacité d’invoquer des services distants. • MOM – MQSeries est interfacé avec les modules Extract et Export. La file MQ est traitée comme un fichier. • Protocoles Internet – HTTP, FTP, XML. • Warehouse Builder – Une forme particulière de connecteur Target. Les formats supportés sont les bases relationnelles, les univers BO, OLAP (Express, Essbase, Powerplay) et ROLAP (Microstrategy).

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

57

EAI

De l’intégration à l’e-business / M a r c h é d e l ’ E A I e t o f f r e s d e s é d i t e u r s

Synthèse Montée en charge

S’appuie sur les mécanismes de load balancing d’Oracle (parallélisation des traitements, partitionnement), administrables depuis la console.

Transactions et moniteurs transactionnels

Pas encore gérés.

Administration

Découpage des processus en phases avec gestion des erreurs pour chacune des phases ; identification des problèmes de performances avec possibilité d’optimisation phase par phase. Toute opération est suivie de bout en bout, de l’acquisition des données jusqu’à leur livraison. Toutes les erreurs sont centralisées sur la même console graphique.

Tolérance aux pannes

S’appuie sur le hot standby d’Oracle et sur Oracle Parallel Server, mais configurable depuis le Transformation Manager.

Sécurité

Pas de sécurisation spécifique du fait de l’emploi des protocoles natifs.

XML

Connecteur XML sur HTTP.

Ouverture

Le produit se comporte comme une application sur une base Oracle et non comme un système complet venant fédérer le système d’information. La question de l’ouverture du système ne se pose donc pas : un moteur Oracle est ouvert à d’autres développements.

Portabilité

Constellar Hub est disponible sous Unix (Sequent, Digital Tru64, Linux, HP-UX, AIX, Solaris) et sous Windows NT.

Productivité de développement

Démarche hiérarchique depuis la console graphique : déclaration des interfaces, des transactions, du mapping des sources de données, des flux de sortie, puis enfin du mapping au niveau attribut. Il est possible de définir des règles métier à tous les niveaux. Des assistants (wizards) permettent d’importer les métadictionnaires. Le GetMetadata Wizard reprend les métadonnées issues de sources Cobol, SGBDR, case Tools ou iDoc. Il existe des assistants de production d’états. Ces états peuvent ê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 distants sont interconnectés, le hub doit être installé sur chacun des sites. Les règles de gestion communes à toutes les configurations sont répliquées sur chaque référentiel distant. Le développement reste centralisé sur une seule plate-forme.

Formation

Cursus de 3 jours sur Constellar Hub. Prérequis : Oracle et PL/SQL. La formation peut avoir lieu sur site.

58

Marché de l’EAI et offres des éditeurs

Level 8 Siège social

Bureaux français

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. En Bourse depuis 1996.

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

Références Merril Lynch, France Telecom, Michelin, SNCF, AMDOCS…

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

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

59

EAI

De l’intégration à l’e-business / M a r c h é d e l ’ E A I e t o f f r e s d e s é d i t e u r s

Le modèle EAI de Level 8 B2B Processus

Business Process Automator

Moteur d'intégration

Integration Broker

Composants

Enterprise Integrator

Données

Data Manager

Transport

Geneva MQ Figure 18 - Modèle EAI de Level 8

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

Moteur d’intégration : Integration Broker Les fonctions d’intégration sont assurées par un message broker, Geneva Integration Broker. Il offre une vue objet des données provenant de toutes les sources de données, et utilise une technologie distribuée pour l’intégration d’applications, de flux d’informations, et de données dans un modèle dynamique (structure et état). Il possède un éditeur et un référentiel pour stocker les transformations à effectuer sur les messages. Ces transformations sont conservées sous forme de métadonnées XML.

60

Configuration et paramétrage s’opèrent par la console Geneva Entreprise Integrator 2.0, portail des ressources en cours d’utilisation. Geneva Enterprise Integrator permet de construire un modèle objet opérationnel qui facilite l’intégration des applications avec les sources de données applicatives. Il permet de construire des passerelles entre les applications web et les autres éléments du système d’information via des composants métier Corba, DCOM et EJB. Le modèle objet opérationnel fournit aux applications un accès synchrone aux sources de données à travers des proxies et le Data Manager (voir la section « Données »), et accède directement aux applications. Il est conservé en mémoire résidente. PMC (Process Monitor Component) est un outil de supervision qui permet la distribution dynamique, et la supervision de l’exécution d’un processus métier.

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

Marché de l’EAI et offres des éditeurs

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

Transport : Geneva Message Queuing Geneva Message Queuing assure le transport de données en mode sécurisé, asynchrone, multi-plateforme et compatible MSMQ. Il existe aussi une passerelle MQSeries/Geneva MQ. Geneva Message Queuing fournit à la gestion des messages une interopérabilité sans rupture avec les plates-formes supportées.

61

EAI

De l’intégration à l’e-business / M a r c h é d e l ’ E A I e t o f f r e s d e s é d i t e u r s

Synthèse

Montée en charge

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

Transactions et moniteurs transactionnels

Avec Geneva IB Transaction Flow, il est possible de supporter les transactions pour préserver l’intégrité des données lors d’un processus en plusieurs étapes (des commits et rollbacks globaux sont effectués sur les messages).

Administration

Geneva MQ Web Monitor et Geneva Explorer sont des outils de surveillance du middleware, respectivement à travers un navigateur Web et à travers la console de gestion (MMC) de Microsoft. Geneva Explorer permet de configurer les adaptateurs, les transformations et le routage.

Tolérance aux pannes

Les outils Microsoft fournissent les fonctionnalités de load balancing et de dynamic clustering (Microsoft Transaction Server, Microsoft Cluster Server et SQL Server).

Sécurité

RSA et DES.

XML

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

Ouverture

Il est possible de communiquer avec des plates-formes non Windows suivantes : Solaris (sparc et intel), HP-UX, AIX, Unix, Linux, VMS (vax et alpha), OS400 et VMS. L’approche composant permet d’étendre les fonctionnalités du message broker avec des composants COM. Geneva supporte également SNMP pour pouvoir s’intégrer dans des outils tels que Tivoli, Unicenter ou HP OpenView. Portabilité Windows NT et 2000. Geneva MQ et un certain nombre d’outils liés à l’intégration au niveau métier sont également disponibles pour Unix (Enterprise Integrator, Business Process Automator).

62 Productivité de développement

L’approche objet et le support des outils de développement Microsoft (Visual Studio et COM) font de Geneva Integration Suite une plate-forme efficace pour le développement.

Déploiement

Le modèle est distribuable.

Formation

Non communiqué.

Marché de l’EAI et offres des éditeurs

Mercator Software Siège social

Bureaux français

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

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

Répartition des équipes pour les clients français Créée en 1998, la filiale française compte plus de 10 collaborateurs employés en France, dont un vice-président Europe du Sud, un directeur commercial Europe du Sud et 3 ingénieurs d’affaires, un directeur technique et 3 consultants senior. Le support international comprend trois niveaux : le premier est en France, le deuxième est le service de hotline européen, basé à Londres, et le troisième est le centre de recherche et développement, en Floride.

Références Plus de 5 000 clients utilisent les produits Mercator ; parmi eux figurent Alcatel, Alstom, American Express, BASF, British Airways, City Bank, Coca Cola, Décathlon, Deutsche Bank, Deutsche Telekom, Federal Express, Hoechst, IBM, Microsoft, Nestlé, Philips, Prudential, Sara Lee, Société Générale, Union Gas.

Historique Mercator s’est tourné vers le secteur de l’EAI dès 1992. En 1999, Mercator a racheté Braid, spécialiste de l’EAI pour le secteur financier, et Novera, spécialiste de l’intégration des solutions web. Grâce à cette croissance externe et à un fort développement interne, Mercator est aujourd’hui un des leaders de l’intégration A2A, B2B et C2B (respectivement application-to-application, business-to-business et consumer-to-business).

Présentation du produit La gamme comprend trois solutions : Mercator Commerce Broker (B2B), Mercator Enterprise Broker (EAI) et Mercator Web Broker (B2C), qui répondent chacun à des besoins spécifiques. L’architecture de transformation repose néanmoins sur une plate-forme et des composants uniques. Les couches processus et moteur d’intégration sont étroitement liées. Ainsi, System Editor, qui sert à modéliser les processus, gère également la distribution des messages.

63

EAI

De l’intégration à l’e-business / M a r c h é d e l ’ E A I e t o f f r e s d e s é d i t e u r s

Le modèle EAI de Mercator B2B

Mercator Commerce Broker

Processus

Integration Flow Designer

Moteur d'intégration

Mercator Integration Server

Composants

Mercator Web Broker

Données

Mercator Type Designer + Adapters

Transport Figure 19 - Modèle EAI de Mercator

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

Processus : Integration Flow Designer L’Integration Flow Designer est l’outil graphique de conception des flux et permet de gérer la configuration via la distribution des composants sur les plates-formes adéquates.

64

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

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

Marché de l’EAI et offres des éditeurs

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

Données : Type Designer + Adapters Type Designer est l’outil graphique de définition des métadonnées. À travers les adaptateurs, le Type Designer permet de se connecter aux sources de données et d’importer les métadonnées. Le Type Designer sait découvrir les catalogues des bases de données relationnelles du marché. L’import des métadonnées est possible pour : • SGBD – Oracle, SQL Server, DB2, Sybase, ODBC. • ERP – SAP (ALE, BAPI, BDC, DMI, EDI), PeopleSoft (Message Agent API, Open Query Interface, EDI), Siebel. • MOM – BEA Tuxedo, IBM MQSeries, MSMQ, Oracle Advanced Queue et TIB/Rendezvous. • Protocoles Internet – HTTP, HTTPS, LDAP, FTP, SMTP, MAPI. • Autres – copybooks Cobol. Les données sources sont récupérées, transformées et acheminées vers les destinataires en mode fil de l’eau ou batch. Les adaptateurs prennent en charge la capture des erreurs, la journalisation et le reporting. Le développement d’adaptateurs est possible.

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

65

EAI

De l’intégration à l’e-business / M a r c h é d e l ’ E A I e t o f f r e s d e s é d i t e u r s

Synthèse Montée en charge

La montée en charge s’opère par la multiplication des serveurs d’intégration.

Transactions et moniteurs transactionnels

BEA Tuxedo peut invoquer Tuxedo Transformation Server (inclus dans Mercator Enterprise Development Kit), qui fait appel au moteur d’intégration. Mercator Integration Server peut appeler un service Tuxedo à travers son adaptateur Tuxedo. Sur IBM OS/390, une transaction CICS peut appeler le moteur d’intégration Mercator.

66

Administration

Des outils de monitoring sont fournis, et l’intégration avec les outils d’entreprise est possible. L’absence d’une base de données système garantit l’agilité (indépendance, portabilité, évolutivité) et minimise le besoin de paramétrage et de tuning de la solution.

Tolérance aux pannes

La multiplication des serveurs d’intégration permet de pallier la défection de l’un d’eux le cas échéant.

Sécurité

Les échanges B2B sont sécurisés selon les mécanismes traditionnels (X.509, SSL, ACL).

XML

XML est reconnu et supporté pour l’échange B2B et toutes les transformations d’un format XML en un format non-XML (et vice versa) sont possibles. Les standards reconnus sont X.12, Edifact, HL7, Swift et les BOD, de l’OAG.

Ouverture

L’intégration avec IBM Tivoli, BMC Patrol et HP OpenView est supportée. La couche transport est dédiée à de nombreux middlewares du marché : MQSeries, BEA MessageQ et Tuxedo, MSMQ, Candle Roma, etc.

Portabilité

Le client de conception, de développement et de configuration tourne sur les plates-formes Microsoft. Le serveur d’intégration est disponible sur 22 platesformes (Windows NT, AIX, Solaris, HP-UX, Compaq, mainframes IBM, etc.).

Productivité de développement

Mercator utilise un langage de paramétrage comparable à un tableur et ne génère pas de code.

Déploiement

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

Formation

Le support de Mercator aux clients inclut des prestations de conseil et de formation, d’assistance technique au projet d’intégration et une hotline régionale.

Marché de l’EAI et offres des éditeurs

Neon (New Era of Networks) Siège social

Bureaux français

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çais Les bureaux français sont implantés depuis 1999. Ils couvrent l’Europe de l’Ouest et du Sud. Les prévisions sont de 20 collaborateurs fin 2000. Le support technique 24 heures sur 24 et 7 jours sur 7 est réparti sur 3 centres mondiaux.

Références Plus de 2 500 références et une forte politique de partenariat : SAP, PeopleSoft, Microsoft, IBM, Oracle, Sun Microsystems, BroadVision, Commerce One…

Architecture technique du produit e-Biz Integrator a demandé 2 à 3 ans de mise en œuvre. Neon a déposé trois algorithmes sur des technologies achetées depuis par IBM, BEA et Sun Microsystems. e-Biz Integrator propose des solutions départementales (banque sur Internet) ou d’entreprise sur toutes plates-formes. L’offre d’EAI et d’e-business de Neon, Neon e-Biz Integrator 2.1, comprend en standard les éléments suivants : • Neon Enterprise ProcessExecutive, le gestionnaire de processus métier ; • NEONRules et NEONFormatter, les moteurs de règles et de formats ; • les adaptateurs XML et EDI ; • NeonWeb ; • Neon e-ADK, le kit de développement d’adaptateurs. e-Biz 2000 est une solution intégrée pour environnement Windows seulement. Il est très employé dans le domaine de la santé. Il est réduit par rapport à e-Biz Integrator mais s’appuie sur les capacités de l’architecture Microsoft et adopte un mode de configuration graphique très convivial et intégré pour l’outil de monitoring.

67

EAI

De l’intégration à l’e-business / M a r c h é d e l ’ E A I e t o f f r e s d e s é d i t e u r s

Le modèle EAI de Neon B2B Processus

Enterprise Process Executive

Moteur d'intégration

Neon Rules / Neon Formatter

Composants Données

Adapters

Transport

EMQ, MQSeries Figure 20 - Modèle EAI de Neon

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

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

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

68

• NEONRules est le moteur de routage. Son algorithme breveté est spécialement conçu pour monter en charge avec le nombre de règles. Les règles sont orientées « contenu » car une granularité très fine est requise. Les règles de routage sont définies par simple glisser-déplacer dans l’interface graphique NEONRules. • NEONFormatter est le moteur de transformation ; il effectue également l’analyse et la validation des données des messages entrants. L’interface graphique permet la modélisation graphique de la transformation. Celle-ci suit les règles métier prédéfinies à l’aide de l’interface homme-machine NEONFormat. Ce moteur supporte tout type de message (délimité, variable, groupes de répétition imbriqués, etc.). NEONFormatter est l’outil qui valide les données des messages entrants, puis transforme et enrichit leur contenu.

Marché de l’EAI et offres des éditeurs

L’originalité de NEONFormatter tient au concept de découplage à l’intérieur même de la solution d’EAI, qui permet d’associer dynamiquement à un seul format de message entrant plusieurs formats de messages sortants et d’éviter ainsi une définition de mapping statique souvent laborieuse. e-Biz Integrator incorpore la configuration et l’administration graphique. Aucun code n’est généré. Les référentiel est stocké dans une base Oracle, Sybase, DB2 ou MS SQL Server. L’utilisation de métadonnées facilite le changement de plate-forme. Grâce au concept de building blocks, tous les éléments constituant les règles de validation, de transformation et d’enrichissement sont très réutilisables : une règle métier définie pour valider un format de date peut ensuite être associée à une multitude de champs dans d’autres mappings. NEONRules et NEONFormatter sont entièrement déclaratifs : ils ne produisent pas de code source. Les règles et les formats sont des métadonnées sauvegardées dans un SGBDR du marché (Oracle, Sybase, DB2 ou MS SQL). NEONTrack contrôle les messages lors de leur entrée ou de leur sortie de l’environnement e-Biz Integrator. Il suit les transactions et traite l’archivage et la recherche des messages. Il détermine l’état transactionnel des messages : en cours, échoué ou achevé, puis les stocke dans une base de données. Le programme contrôle la base de données et affiche de l’information sur son statut au moyen d’une interface utilisateur graphique. L’outil Crystal Report, livré en standard, permet de générer des rapports complets.

Données : Adapters Tous les adaptateurs Neon sont bidirectionnels et peuvent être employés d’une manière distribuée. Ils récupèrent les formats des données des applications et les insèrent dans le référentiel NEONRules & Format. Par exemple, l’adaptateur NEONadapter for SAP est capable de charger les formats d’iDoc et/ou BAPI SAP dans NEONRules & Format. • SGBD – ODBC ; la prochaine version prévoit des connecteurs directs aux bases de données. • ERP – SAP, PeopleSoft, Oracle Applications, JDEdwards. • CRM – Siebel, BroadVision. • SCM – i2 Technology. • MOM – NEONadapter for Protocols permet la communication entre MOM hétérogènes ; la prochaine version permettra l’accès direct à MSMQ, à Oracle AQ, à Tuxedo/Q, etc. • Autres : formats et protocoles financiers – Swift, FIX, Oasys Global, Stelink, Chaps, etc. • Autres : progiciels bancaires – Reuters, Bloomberg, Autex, Sungard Devon, Sungard Panorama, Kondor+, Summit, Infinity, OLF, Fenics, Atlas, Royal Blue, Murex, Currency+, Cognotec, Cobra, The Box, intelliSTOR, intelliTRAC. • Réalisés à la demande – Clarify, Trilogy, Vignette, Symbols, OpenLink Financial, Dodge, Limits, Arrow, Global Oasys, Baan, Sun GL, MFG/PRO, BisGen, Logility, Maximo, BSCS, Ariba, Gerber WebPDM, etc. Neon e-ADK est une boîte à outils permettant le développement rapide d’adaptateurs non fournis par Neon. L’offre est complétée par les accélérateurs (ensemble de règles de transformations prédéfinies entre deux applications, par exemple entre Commerce One et SAP).

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

EAI

De l’intégration à l’e-business / M a r c h é d e l ’ E A I e t o f f r e s d e s é d i t e u r s

Synthèse Montée en charge

Une instance converse directement avec une application. Le load balancing est géré par la duplication des instances sur une même machine ou sur des machines différentes. L’algorithme de NEONRules prévoit la montée en charge au fur et à mesure de l’accroissement du nombre de règles.

Transactions et moniteurs transactionnels

Gère les transactions longues et courtes grâce à Enterprise ProcessExecutive. Il est possible d’auditer une transaction pour visualiser. Neon se repose sur la gestion transactionnelle de MQSeries : transaction par propagation. Il existe Neon CICS sur mainframe IBM.

Administration

Les trois applications NEONRules, NEONFormatter et NEONTrack procurent l’ensemble des fonctionnalités d’administration souhaitées via une interface graphique.

Tolérance aux pannes

Distribution des instances.

Sécurité

Le moteur de règles et de formats peut appeler une routine externe pour décrypter un message afin de le traiter et de le recrypter en sortie.

XML

Adaptateur livré en standard avec e-Biz Integrator.

Ouverture

NEONRules & Format a une API. Il est possible de gérer ce moteur de façon externe. De plus, le référentiel peut être abrité par les différentes bases de données des grands éditeurs du marché. Appel de routines externes en C++ pour intégrer des composants métier externes à l’intérieur du moteur de règles et de format.

70

Portabilité

Sun Solaris, HP-UX, AIX, MVS et Windows NT 4SP5 et 2000. Pas de code généré, tout est dans une base de données relationnelles : solution d’importation-exportation.

Productivité de développement

Pratiquement pas de code à écrire.

Déploiement

NEONRules & Format peut être administré à distance. La configuration est paramétrable en fonction des nécessités d’optimisation.

Formation

Cursus sur tous les produits. Offre de formation packagée qui couvre l’intégralité de l’offre produit. Formations à e-Biz 2000, à NEONTrack, formation spécifique très courte sur les adaptateurs. Couvre 70 % des fonctionnalités du produit.

Marché de l’EAI et offres des éditeurs

STC (Software Technology Corporation) Siège social

Bureaux français

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

Présentation de la société 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çais Les équipes sont réparties en deux pôles : Paris (équipes commerciales et techniques : avant-vente et consultants) et Angleterre (recherche et développement, support technique francophone).

Références Quelque 1 600 sites en production chez des grands comptes, représentant plus de 30 000 applications intégrées.

Historique À l’origine, le produit s’appelait DataGate et résolvait une problématique d’intégration à laquelle le secteur hospitalier américain a été historiquement très sensible. Il y a deux ans, 80 % des clients de STC étaient des professionnels de la santé. La répartition s’est inversée et aujourd’hui, grâce à sa nouvelle offre, e*Gate, STC réalise plus de 75 % de son chiffre d’affaires en dehors de ce secteur. e*Gate propose une architecture entièrement distribuable qui couvre l’ensemble des couches du modèle EAI.

Architecture technique du produit La solution e*Gate repose sur une architecture de type network centric (orientée réseau) gérée par un unique référentiel centralisé, multi-plate-forme et propriétaire. Sa spécificité est la génération de composants métier pour les opérations portant sur les données (dont la transformation), entièrement distribuable au travers du système d’information de l’entreprise. Cette architecture permet notamment une granularité de distribution par composants assez fine pour gérer la montée en charge ou la tolérance aux pannes. Parti d’un modèle EAI de première génération (le produit est l’un des plus anciens du marché), e*Gate a évolué vers une architecture eAI avec l’adjonction récente de nouveaux modules et s’ouvre aujourd’hui à l’échange interentreprise, renommé en eBI (e-business Integration) chez STC. Enfin, poursuivant une démarche d’intégration CRM forte, e*Gate incorpore désormais un outil de constitution 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).

71

EAI

De l’intégration à l’e-business / M a r c h é d e l ’ E A I e t o f f r e s d e s é d i t e u r s

Le modèle EAI de STC e*Gate 4 B2B

E*Xchange Integrator

Processus

Business Process Manager

Moteur d'intégration

Collaboration / Topologie

Composants

Business Object Broker (BOB)

Données

e*Ways / Communication Client

Transport

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

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

Processus : eBusiness Process Manager L’eBusiness Process Manager permet aux consultants métier et aux utilisateurs finaux de réaliser la modélisation graphique des Business Process (règles métier) des flux, puis de générer et configurer les composants sous-jacents de l’application (les e*Ways, les BOB et les IQ) en s’affranchissant de la mise en œuvre technique du processus. Si le processus est modifié, les objets métier sont de nouveau générés. Ce module gère également les processus métier B2B.

72 Moteur d’intégration : Collaboration et Topologie Une Collaboration détermine la gestion technique des processus métier définis dans l’eBusiness Process Manager. Ce module définit la structure des échanges entre les différentes étapes d’un processus, ainsi que le schéma de transformation d’un message en un autre. Le routage des messages, les notifications et l’invocation d’API externes sont également implémentables. Concrètement, une Collaboration se présente comme un éditeur graphique qui génère par glisser-déposer des scripts basés sur un L4G. L’écran de Topologie propose une vision physique du système d’information en tant que réseau composé de machines physiques et permet de gérer la distribution et la configuration de la solution (optimisation à des fins de montée en charge).

Marché de l’EAI et offres des éditeurs

Composants : BOB (Business Object Brokers) Les BOB sont des services métier qui communiquent avec les files d’attente (IQ) et qui incluent un ou plusieurs traitements (Collaboration) sur les données. Le BOB mappe techniquement la logique métier multiétapes définie au sein de l’eBusiness Process Manager. Le BOB peut être vu comme un connecteur applicatif (e*Way) interne, destiné à ne communiquer qu’avec les files d’attente du système d’information (les IQ). Pour des raisons de montée en charge et de tuning du système, des BOB identiques peuvent être déployés à différents endroits physiques du réseau afin, par exemple, de paralléliser les traitements. Ces composants métier peuvent communiquer entre eux et les tâches peuvent donc être sérialisées. Enfin, le BOB – comme tous les autres service de la solution – dispose localement des informations du référentiel le concernant, d’où une certaine autonomie et une tolérance aux pannes.

Adaptateurs : e*Ways Les e*Ways (connecteurs) sont des composants de communication intelligents présentés sous forme packagée pour permettre une connexion rapide aux applications existantes. Les connecteurs (e*Ways) sont bidirectionnels et multithreads. Plusieurs types d’e*Ways sont proposés dans l’offre (plus de 55 e*Ways sont disponibles au moment où nous rédigeons ce texte et 100 à 150 le seront d’ici à fin 2000) ; parmi eux figurent : • SGBD – Natifs pour Oracle et Sybase, ODBC. Ces composants sont nommés DART (Data Access Retrieval Technology). L’idée est de représenter graphiquement la structure des tables ou des vues relationnelles sous forme d’arbres, puis de les remplir par les enregistrements. • ERP – SAP, PeopleSoft, Siebel, BroadVision, Vantive, Clarify. • i*Bridge : Intelligent Bridges packagés – SAP vers PeopleSoft, BroadVision vers SAP, BV/Siebel. • MOM – Oracle AQ, IBM MQSeries, MSMQ, Sybase IQ, Tibco. • Protocoles Internet – TCP/IP, FTP, batch, HTTP (Apache, IIS, WebSphere), HTTPS, SMTP. Deux modes de fonctionnement sont possibles : événementiel ou batch, mais aussi synchrone ou asynchrone en fonction de l’applicatif à intégrer. STC fournit une boîte à outils, l’e*Way Extension Kit, pour développer ses propres e*Ways (L4G, C et C++ ou Java). Le développement de connecteurs spécifiques requiert une prestation de service, qui peut être assurée par STC. La durée d’un tel développement peut varier d’une demi-journée à 10 jours en fonction de la complexité de l’application à intégrer. STC peut ensuite juger intéressant d’industrialiser ce développement en créant un e*Way : développement d’une interface utilisateur, rédaction d’une documentation et mise en place d’un support technique.

73

EAI

De l’intégration à l’e-business / M a r c h é d e l ’ E A I e t o f f r e s d e s é d i t e u r s

Transport : Intelligent Queues La non-perte et la garantie de délivrance unique des informations sont assurées par un stockage persistant dans un format crypté. D’autres mécanismes tels que le buffering, le contrôle de routage, l’envoi d’accusés de réception et l’audit des événements métier viennent enrichir les services fournis par ces Intelligent Queues.

74

Marché de l’EAI et offres des éditeurs

Synthèse Montée en charge

La solution est conçue pour permettre de distribuer des composants (IQ, BOB, e*Way) en tout point physique du réseau. Les dupliquer en vue de répartir les traitements garantit de bonnes capacités de montée en charge du produit. Enfin, les composants sont multiprocess et multithreads.

Transactions et moniteurs transactionnels

Le produit n’incorpore pas encore de fonctionnalités transactionnelles natives. Il est néanmoins possible de l’interfacer avec un moniteur transactionnel par le développement d’un connecteur spécifique ou par l’exploitation d’une e*Way existante.

Administration

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

Tolérance aux pannes

La possibilité de dupliquer les composants lors de leur distribution permet de faire face à des incidents tels qu’une rupture de connexion réseau. De plus, les BOB peuvent répliquer en local la partie du référentiel concernant leur fonctionnement (transformation et routage).

Sécurité

Les IQ garantissent la diffusion unique d’un message et sa non-perte. L’eSecurity Manager est un outil dédié à la sécurité B2B : intégrité, cryptage, authentification de la source et non-répudiation.

XML

XML est un des nombreux formats d’échange possibles entre les différentes structures de message, pour lequel STC fournit le XML DTD Converter. Mais aussi : librairies de structures RosettaNet et BizTalk.

Ouverture

« e*Gate architecture is net-centric, not platform centric. » Les e*Ways, les BOB et les IQ sont distribuables sur un grand nombre de plates-formes. Accès à des API externes. La solution e*Gate est ouverte aux agents réseau SNMP comme IBM Tivoli ou HP OpenView. Utilisation de C et C++, Java, Visual Basic, etc.

Portabilité

Référentiel disponible pour un grand nombre de plates-formes : Windows NT 4/2000 (Intel/Alpha), différents Unix (AIX, Solaris, HP-UX, Linux) et OS/390.

Productivité de développement

Il n’y a pas de développement au sens strict du terme. La modélisation métier et technique ainsi que le déploiement physique s’opèrent à l’aide des interfaces graphiques de l’eBusiness Process Manager et de Collaboration, modules communicants et centralisés sur le référentiel unique.

Déploiement

Facilement réalisable par le biais de l’interface graphique. La phase de déploiement est ainsi déconnectée de la phase de conception métier et de la phase de développement. Les IQ sont en mode publish and subscribe dynamique. La granularité du déploiement est très fine car on distribue des composants métier et non des hubs. Le nombre de files d’attente à déployer sur le système est, par exemple, fonction de l’éloignement physique des traitements à intégrer, des volumes, etc. C’est une des voies possibles d’optimisation des performances du système d’information via la plate-forme d’EAI.

Formation

Deux cursus de formation de 3 jours chacun : e*Gate Basic et e*Gate Advanced. STC propose également un ensemble de cours spécifiques aux e*Ways, à e*Xchange, à l’Alert Agent, à l’e*Index, etc. Les équipes deviendront ensuite rapidement autonomes et seront en mesure d’intégrer de nouvelles applications.

75

EAI

De l’intégration à l’e-business / M a r c h é d e l ’ E A I e t o f f r e s d e s é d i t e u r s

Tibco Software Siège social

Bureaux français

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

Présentation de la société 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çais Filiale française depuis 3 ans, 20 collaborateurs (vente et conseil) ; 38 bureaux dans le monde entier.

Références Secteur de la finance avec plus des 300 institutions à travers le monde ; secteur de la fabrication high-tech (80 % de chip processing – Intel, Hitachi). Position dominante dans le secteur de l’énergie en Asie, en Australie et en Europe. Concentration au Royaume-Uni et en Europe centrale. Quelques références : Nasdaq, Ericsson, Telecom Italia, Hitachi, Pirelli, Adidas, Delta Airlines, Philips Medical Systems, Yahoo!, EDF Trading, GDF Trading.

Historique

76

En 1995, le monde de la finance s’intéressait de près au multicast et au messaging. Reuters scinde Teknekron, dont le métier initial était de construire des bus logiciels plug and play, en deux entités : Tibco (The Information Bus Company) Software, dont les métiers seront la technologie et la vente de produits, et Tibco Finance, qui implémentera des solutions pour les marchés financiers. Aujourd’hui, Tibco Software et Cisco, actionnaire minoritaire, travaillent à la création d’un protocole IP-multicast appelé Pragamatical Generic Multicast (en cours de standardisation), qui utilise la technologie Tibco. Cette technologie est utilisée sur Cisco IOS 12.1 (qui utilise TIB/Rendezvous et TIB/Hawk – voir ci-dessous) et fera partie de la prochaine version de Solaris. Tibco Software a acquis en juillet 2000 la société Extensibility, spécialisée dans le développement d’outils de modélisation et de développement XML.

Architecture technique du produit Longtemps tourné vers l’intégration EAI, Tibco Software fournit aujourd’hui une infrastructure d’e-business complète, avec l’apparition récente de produits d’EIP et de B2B. L’offre s’adresse autant aux entreprises Brique et Mortier qu’aux dot-com. Les trois briques de la solution sont : • ActiveEnterprise pour l’intégration EAI ; • ActivePortal pour l’EIP ; • ActiveExchange pour l’intégration B2B ; • Extensibility. Le premier client, Goldman & Sachs, a permis de créer une place de marché financière virtuelle pour les courtiers. Tibco Software a alors ciblé 80 % du marché financier, équipant des places de marché telles que le Nasdaq ou la City.

Marché de l’EAI et offres des éditeurs

Le modèle EAI de Tibco B2B

TIBCO ActiveExchange

Processus

TIB/InConcert TIB/Integration Manager

Moteur d'intégration

TIB/Message Broker

Composants Données

TIB/Adapters

Transport

TIB/Rendez-vous Figure 22 - Modèle EAI de Tibco

B2B : ActiveExchange La gamme de produits ActiveExchange est conçue pour l’implémentation d’e-marketplaces horizontales (comme mySAP, de SAP) et verticales, mais aussi pour l’échange de données entre serveurs. Elle comprend trois outils : TIB/BusinessConnect, TIB/BusinessPartner et TIB/BusinessExpress. TIB/BusinessConnect est le hub ; il comprend un outil graphique de définition des processus, un moteur d’automatisation de leur exécution et un système de gestion des partenaires. TIB/BusinessPartner peut être distribué à des partenaires ne disposant pas d’outil B2B dédié afin qu’ils puissent se connecter à une plate-forme TIB/BusinessConnect ou à toute autre plate-forme supportée par les adaptateurs. L’outil différencie les processus publics (B2B) et les processus privés (d’entreprise). TIB/BusinessExpress permet à tout partenaire d’accéder à TIB/BusinessConnect par l’intermédiaire d’un navigateur HTML. Les messages sont transmis en XML et respectent les standards RosettaNet, cXML, BizTalk et OAG. Ils peuvent être délivrés avec TIB/Rendezvous ou sur HTTP, FTP et SMTP. Une connectivité EDI est possible.

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

77

EAI

De l’intégration à l’e-business / M a r c h é d e l ’ E A I e t o f f r e s d e s é d i t e u r s

Moteur d’intégration : TIB/MessageBroker – monitoring : TIB/Hawk TIB/MessageBroker transforme les données fournies par TIB/Rendezvous au moyen de règles définies par une interface graphique. TIB/MessageBroker assure un routage intelligent des messages par analyse de leur contenu. Les métadonnées peuvent être extraites du référentiel TIB/Repository au format XML. Il est important de noter qu’un message broker dédié est optionnel dans cette configuration. En fonction du besoin d’intégration manifesté par le système d’information, il peut être plus judicieux de conecter un petit message broker sur les adaptateurs applicatifs, à l’écoute des messages circulant sur le bus. TIB/Hawk fournit une vue centralisée des applications distribuées et des systèmes à travers toute l’entreprise et permet de les surveiller. Des traitements automatisés peuvent être planifiés (batch, agents) et la réparation d’incidents peut être effectuée à distance. TIB/Hawk sert également à mesurer les performances des bases de données Oracle, Sybase et SQL Server, à se connecter à des consoles CA UniCenter et Tivoli, et fournit une passerelle SNMP. TIB/Hawk peut surveiller l’activité des outils B2B ou d’un adaptateur et décider de lancer de nouvelles instances pour faire face à un pic de charge. La technologie est complètement distribuée.

Données : TIB/Adapters Les adaptateurs ne nécessitent aucun développement. Voici la liste des adaptateurs fournis par Tibco : • SGBD – DB2, MS SQL Server, Informix, Oracle, Sybase, ODBC. • ERP – Baan, Oracle Applications, Clarify, i2 Technology, JDEdwards, Siebel, Vantive, PeopleSoft, SAP. • MOM – MSMQ, MQSeries, Oracle AQ. • ORB – COM, Corba. • B2B – Ariba, Calico, Selectica (gestion de la configuration pour e-marketPlaces). • EDI – adaptateurs GEIS. • Protocoles Internet – HTTP, HTTPS, FTP, Secure FTP, SMTP et S/MIME. • Adaptateurs verticaux – Plus de 50 adaptateurs pour le domaine bancaire ; des adaptateurs pour le monde high-tech, l’énergie et les télécommunications. • Autres – Fax, GSM. TIB/Adapter SDK permet à l’entreprise de développer ses propres adaptateurs. Tibco Software peut effectuer des prestations de développement ou solliciter des partenaires pour des adaptateurs spécifiques.

Transport : TIB/Rendezvous

78

TIB/Rendezvous est en version 6 et a derrière lui 15 ans d’expérience. TIB/Rendezvous est un MOM supportant des modèles de communication multiples tels que le publish and subscribe, le request-reply ou le broadcast request-reply, ainsi que des niveaux de qualité de service différents comme le broadcast fiable (reliable broadcast), le multicast fiable (reliable multicast), la délivrance de messages certifiés (guaranteed messaging) et le messaging transactionnel. TIB/Rendezvous utilise une technologie brevetée TIB d’adressage par sujet. Un message est publié une seule fois sur le réseau et comprend un « sujet » dans son en-tête (subject based addressing). Les applications abonnées à ce sujet reçoivent automatiquement le message. Cette technologie permet de réduire le trafic réseau, rend la localisation des applications entièrement transparente et permet un niveau de modularisation du système d’information extrêmemnt élevé.

Marché de l’EAI et offres des éditeurs

Synthèse Montée en charge

TIB/IntegrationManager, TIB/Hawk et TIB/Rendezvous (API) se multiplient pour gérer cet aspect. L’architecture est totalement distribuable.

Transactions et moniteurs transactionnels

TIB/IntegrationManager permet de définir des transactions courtes et longues, interapplicatives et interpartenaires. TIB/Rendezvous TX permet d’exécuter de multiples opérations comme une seule unité d’œuvre.

Administration

La plate-forme est intégralement administrable par des outils graphiques, qui surveillent à la fois l’exécution des processus et des transactions, les performances du système et l’activité réseau. La plate-forme d’administration de TIB/Rendezvous peut être fondée sur un formulaire HTML.

Tolérance aux pannes

TIB/IntegrationManager, TIB/Hawk et TIB/Rendezvous (API) permettent un redémarrage immédiat suite à des erreurs inattendues, ainsi que la distribution de certaines tâches avec des micro-agents pour pallier d’éventuelles interruptions réseau.

Sécurité

Signature digitale des documents par PCKS#7, transport et document encryptés. Sécurité (encryptage 56 et 128 bits SSL), encryptage X.509, signature digitale, non-répudiation et fonctionnalité d’audit sur les transactions.

XML

Les métadonnées du référentiel peuvent être extraites en XML. Les documents d’échange B2B en XML sur HTTP sont « parsés » à l’entrée et à la sortie pour validation et transformés si nécessaire.

Ouverture

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

Portabilité

L’interface graphique de TIB/MessageBroker et TIB/BusinessConnect sont entièrement développés en Java. TIB/Rendezvous est disponible pour Windows, Unix et mainframes OS/390. Hawk est disponible sous NT, Unix, Linux et VMS.

Productivité de développement

Un ensemble d’outils graphiques permet de traiter séparément la partie métier et la partie technique sans développement.

Déploiement

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

Formation

Le cursus complet dure 11 jours et comprend un tronc commun et une spécialisation. Le tronc commun dure 7 jours et comprend les modules : introduction à Tibco ActiveEnterprise, concepts de TIB/Rendezvous, installation et administration de TIB/Rendezvous, concepts et configuration de TIB/MessageBroker, administration avec TIB/Hawk. La spécialisation dure 4 ou 5 jours et concerne soit le B2B (formation à ActiveExchange et à ActivePortal), soit le workflow (formation à TIB/InConcert et à TIB/IntegrationManager).

79

EAI

De l’intégration à l’e-business / M a r c h é d e l ’ E A I e t o f f r e s d e s é d i t e u r s

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

Présentation de la société Création La société suédoise Frontec, créée en 1981 par Greg Cronin, compte 300 collaborateurs de par le monde. Ses métiers sont le conseil technique et organisationnel. Viewlocity est un spin-off du département AMT de Frontec.

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

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

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

Architecture technique du produit Le produit phare est AMTRix : il est riche de fonctionnalités en infrastructure et doté d’un message broker. Mais plus l’outil est ouvert, moins il est ergonomique. AMTrix est donc un produit puissant mais avec une interface ingrate.

80

AMTrix se positionne comme intégrateur de la chaîne d’approvisionnement et de commande, pour permettre aux applications du système d’information de s’appuyer sur de l’e-commerce. Ainsi, pour Volvo, le volume des échanges est de 60 millions de messages par mois, avec, pour les messages de synchronisation de chaînes de production, une contrainte de temps de traitement de bout en bout, intégrant l’acquis applicatif, d’un dixième de seconde.

Marché de l’EAI et offres des éditeurs

Le modèle EAI de Viewlocity B2B

AMTrix

Processus

Business Process Manager

Moteur d'intégration

Data Mapper & Monitor

Composants Données

Connecteurs

Transport Figure 23 - Modèle EAI de Viewlocity

B2B : AMTrix AMTrix dispose d’un référentiel complet des formats d’échanges EDI internationaux et est ouvert aux standards fondés sur XML. SmartSync assure la synchronisation et l’automatisation des flux d’e-business sur architecture distribuée. La sécurité s’opère de la façon suivante : • Grâce à X.435, protocole très sécurisé (développé en Suède), orienté vers les flux EDI. • Grâce à HTTPS et à S/MIME, orientés vers les flux web, pour transporter des flux de messages Edifact. • Le produit garantit un acheminement confidentiel des données avec un haut niveau de sécurité et de traçabilité. Viewlocity fait partie du groupe de travail RosettaNet et intègre ce framework, ainsi que BizTalk, à son produit AMTrix. Le connecteur XML permet d’implémenter les PIP RosettaNet des applications de gestion logistique.

Processus : Business Process Manager Business Process Manager sert à réaliser une modélisation graphique du workflow au sein de l’entreprise étendue et à mettre en œuvre le paramétrage nécessaire aux traitements associés.

Moteur d’intégration : Datamapper et Monitor À travers l’AGL associé à AMTrix, composé du Metadata Browser et de Datamapper, AMTrix permet de mettre en œuvre l’accès aux données applicatives des progiciels de gestion intégrés aussi bien qu’à celles des applications héritées. L’outil de transformation des formats, Datamapper, en assure également le contrôle. Son intégration avec le routeur AMTrix permet d’effectuer – à l’aide du L4G semi-compilé et portable de la plate-forme AMTrix, Message Builder – des opérations de routage complexe any-to-any s’appuyant sur l’enveloppe des échanges et sur le contenu des données échangées. Grâce à son poste client de supervision, Monitor, AMTrix permet de tracer l’intégralité des échanges. Signalons sa capacité de mettre en œuvre des dispositifs d’alerte et de gestion des exceptions à travers des remontées SNMP vers des consoles de supervision ou à travers les connecteurs de messagerie, SMS et fax.

81

EAI

De l’intégration à l’e-business / M a r c h é d e l ’ E A I e t o f f r e s d e s é d i t e u r s

Données Les connecteurs disponibles sont : • SGBD – Oracle, DB2/400, Sybase, SQL Server. • ERP – SAP (iDoc), JDEdwards (Zfiles), QAS. • MOM – MQSeries. • ORB – Corba. • Protocoles Internet – HTTP (XML, Edifact), FTP, SMTP. • Autres – X.400, X.420, X.435. Un atelier de développement de connecteurs permet à chaque entreprise d’élaborer ses propres adaptateurs.

Synthèse Montée en charge

AMTrix permet, avec une configuration système adaptée, de résoudre une problématique d’échange de flux dans un environnement temps réel.

Transactions et moniteurs transactionnels

Grâce à sa plate-forme de développement de connecteurs (CDP), AMTrix est à même d’intégrer les blocs d’échange manipulés par les API des moniteurs transactionnels. Ceci n’est cependant pas une offre standard à ce jour.

Administration

À travers son poste client de supervision, Monitor, AMTrix permet de paramétrer et de tracer l’intégralité des échanges, tant en termes de communications qu’en termes de transformation et de manipulation des données.

Tolérance aux pannes

AMTrix peut être exploité dans des configurations à tolérance aux pannes à travers la mise en œuvre de clusters et d’outils de bascule automatique tels que HP MC Service Guard.

Sécurité

AMTrix sait gérer la confidentialité des données par le biais de certificats à clé publique, dans les protocoles X.435, HTTPS (certificats à clé publique), S/MIME.

XML

Plate-forme de développement CDP : le connecteur est fondé sur XML. Tout type de DTD est lu, ainsi que XDR. Metadata Browser sait lire ces documents et en permet le mapping et le routage.

Ouverture

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

Portabilité

Disponible sur les plates-formes Unix, Windows NT et AS/400. AMTrix utilise Message Builder, langage pseudo-compilé multi-plate-forme.

Productivité de développement

Utilisation de Message Builder.

Déploiement

La durée de mise en œuvre d’une solution fondée sur AMTrix est de l’ordre de quelques jours.

Formation

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

82

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

Marché de l’EAI et offres des éditeurs

Vignette-OnDisplay OnDisplay Siège social

Bureaux français

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 Siège social

Bureaux français

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), OnDisplay emploie actuellement 400 collaborateurs.

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

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

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

Architecture technique du produit La stratégie d’éditeur d’outils d’infrastructure logicielle pour les portails et les places de marché d’OnDisplay couvre la mise en place de frameworks B2B en partenariat avec des groupements comme Harbinger, Ariba et Commerce One. Le récent rachat par Vignette apporte la composante computer-to-consumer. Pour ces deux sociétés ayant 10 % de leurs clients en commun, il était plus logique de converger que d’évoluer vers une situation de concurrence.

EAI

De l’intégration à l’e-business / M a r c h é d e l ’ E A I e t o f f r e s d e s é d i t e u r s

Leur gamme de produit s’appelle CenterStage. L’offre est composée de briques distinctes formant un tout unifié et cohérent mais dont les modules peuvent être acquis séparément. Ces modules sont : • eContent, le produit phare, tourné vers les portails et les places de marché. Il fonctionne par création d’agents intelligents. • eIntegrate, qui est l’offre d’EAI. OnDisplay a intégré la technologie d’Oberon. • eBizXchange, qui est la couche B2B de la solution.

Le modèle EAI de Vignette-OnDisplay B2B

XML Connect - eBizExchange

Processus

eIntegrate

Moteur d'intégration

eIntegrate

Composants Données

Building Blocks

Transport Figure 24 - Modèle EAI de Vignette - OnDisplay

B2B : XML Connect – eBizXchange eBizXchange XML Server effectue la transformation et l’agrégation des formats XML, EDI, texte structuré, ODBC et JDBC afin de gérer des transactions avec d’autres sites. Des agents vont aller chercher des informations sur un site et éventuellement procéder aux transactions et aux transformations nécessaires selon les règles établies. Ces agents sont créés avec l’Agent Builder. Trois moteurs d’échange peuvent être utilisés : • Agent Engine – Moteur monothread en mode batch. • Agent Server – Moteur multithread en mode temps réel. • XML Server – Moteur de gestion de transactions avec moteur de règles (ContentBroker).

84

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 mode sécurisé avec accusés de réception.

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

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

Marché de l’EAI et offres des éditeurs

Données : Building Blocks Là aussi, l’unité de base est le Building Block. Certains Building Blocks sont prépackagés : • SGBD – JDBC, ODBC. • ERP – SAP, JDEdwards, PeopleSoft. • CRM – Siebel. • MOM – MQSeries, MSMQ, Oracle AQ. • ORB – COM, Corba (Iona Orbix), Java (bean client, bean server). • Protocoles Internet – HTTP, FTP. • Autres – Gestion de projet (Primavera Project Planner, MS Project), B2B (Extricity), Lotus Notes, Microsoft Office. OnDisplay, ou un intégrateur qualifié sur le produit eIntegrate, peut effectuer des prestations de services pour le développement de Building Blocks. Pour la création d’agents, l’Agent Builder permet de spécifier les données d’une base de données, d’un fichier XML, d’un format EDI ou d’un fichier HTML (en ligne ou non). Les transformations se font visuellement, par glisser-déposer de la source vers la destination. Ces agents sont la base de la plupart des applications de la ligne CenterStage. Le Building Block paramétré est ensuite récupéré dans eIntegrate, prêt à être inséré à une chaîne de processus. Les agents XML sont « mappés » sur des DTD.

Synthèse Montée en charge

Agent Server gère la montée en charge. Le système est ouvert pour dédier ce volet aux applications du système d’information.

Transactions et moniteurs transactionnels

Définition de règles d’activation et de désactivation. Mécanismes de routage conditionnels.

Administration

Définition visuelle des traitements à effectuer en cas d’erreur. Génération de fichiers et génération d’un événement lançant un nouveau processus. Actions de substitution. Suivi pas à pas de l’exécution d’un événement en mode débogage.

Tolérance aux pannes

La tolérance aux pannes s’appuie sur les mécanismes propres aux platesformes de déploiement sur lesquelles la solution s’exécute.

Sécurité

Prise en compte des mécanismes de sécurité standard (cryptographie SSL, certificats, non-répudiation).

XML

eBizXchange, XML Connect et Agent Builder utilisent beaucoup la technologie XML.

Ouverture

Grande ouverture de la solution avec des possibilités de déploiements dans des environnements très variés et au choix de l’utilisateur.

Portabilité

Le système de développement des agents tourne sous NT, mais le système de production existe pour NT et pour Unix AIX, HP-UX et Solaris. Il existe une version Linux d’eIntegrate.

Productivité de développement

Grâce aux interfaces graphiques, il est très facile de recréer un agent en cas de modification d’une source de données. Le système de développement tourne sous NT.

Déploiement

L’Agent Server permet de configurer les agents (JAR). Architecture distribuée. Mise en mémoire et précompilation des agents pour optimiser les performances 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.

85

EAI

De l’intégration à l’e-business / M a r c h é d e l ’ E A I e t o f f r e s d e s é d i t e u r s

webMethods Siège social

Bureaux français

3930 Pender Drive

75008 Paris

Fairfax, VA 22030 54, avenue Hoche

Tél. : +33 156 605 859

Contact : Rémy Dubois, directeur France. http://www.webmethods.com Nous avions prévu de présenter ActiveWorks, la solution d’EAI d’Active Software. Le rachat, en juin 2000, d’ActiveSoftware par webMethods apporte une solution B2B reconnue et crée une plate-forme complète couvrant toutes les couches du modèle EAI sous l’« enseigne » unique de webMethods.

Présentation Création Créée en 1996. Implantation internationale. Plus de 750 collaborateurs. Une équipe de Recherche et Développement de 220 collaborateurs.

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

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

Historique Travaillant sur les spécifications du modèle Corba pour le compte de l’OMG, Jim Green et Rafael Bracho constatent que les technologies objet s’avèrent peu efficaces pour communiquer en asynchrone avec un existant. Ils proposent un Extended-Corba, refusé par l’OMG, ce qui les conduit à développer un prototype pour concrétiser leur vision. Celui-ci est financé par le Java Funds, fonds d’investissement de la Silicon Valley auquel participent IBM, Oracle, Sun Microsystems, KPMG, etc. Ce prototype est la première version de ce qui deviendra le produit phare d’Active Software : la suite ActiveWorks, élue produit de l’année 1999 par DataMation. Dédiée à l’intégration EAI, elle est aujourd’hui renommée webMethods Enterprise.

86

De son côté, webMethods s’intéresse depuis sa création en 1996 aux échanges B2B et justifie aujourd’hui d’une solide expérience autour des e-marketplaces, organisées autour de la solution webMethods B2B Server, comme celles de Dell (25 000 acheteurs) et d’Ariba (30 000 fournisseurs). Son connecteur B2B pour SAP R/3 est utilisé par Oracle pour sa suite Oracle Applications et pour OIS (Oracle Integration Server), et son Business Connector (invocation de fonctions SAP via HTTP et SMTP et retour des données au format XML) équipe aujourd’hui SAP R/3 en standard. D’une façon générale, webMethods croit énormément à la propagation des standards XML à la conception desquels il participe ; webMethods est ainsi directement impliqué dans le groupe de travail ebXML. webMethods fournit aussi deux niveaux complémentaires de service : Trading Network (monitoring et audit des échanges entre partenaires) et B2B.com, un portail dédié aux échanges B2B, à partir duquel une entreprise est en mesure d’inclure rapidement un partenaire potentiel à son réseau d’échange (téléchargement des adaptateurs applicatifs requis, mise en relation avec des intégrateurs qualifiés…). Enfin, l’intégration de webMethods Enterprise et de webMethods B2B sera effective au premier trimestre 2001, via l’utilisation d’ un référentiel et d’un environnement de développement communs.

Marché de l’EAI et offres des éditeurs

Le modèle EAI de webMethods WebMehods B2B Server

Processus Moteur d'intégration Composants Données Transport

webMethods Enterprise

B2B

Visual Integrator / Integration Process Information Broker Agents / Designer Intelligent Adapters Information Broker

Figure 25 - Modèle EAI de webMethods

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

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

87

EAI

De l’intégration à l’e-business / M a r c h é d e l ’ E A I e t o f f r e s d e s é d i t e u r s

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

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

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

Transport : Information Broker Information Broker gère ses propres files d’attente en utilisant en mode publish and subscribe et reply-request.

88

Marché de l’EAI et offres des éditeurs

Synthèse Montée en charge

La montée en charge se traite de façon traditionnelle, en deux points : d’une part par une configuration matérielle appropriée et par la répartition géographique, d’autre part au niveau des connecteurs, ceux-ci étant « multithreadés ». Une configuration multi-hub peut être mise en place sans compliquer l’administration : les brokers sont logiquement liés entre eux, et toute modification du broker principal est répercutée sur les brokers liés. Tout service B2B de webMethods B2B est « multithreadé », limitant la charge machine.

Transactions et moniteurs transactionnels

La multiplication des brokers de part et d’autre d’un point réseau sensible peut permettre au système de continuer à fonctionner même en cas de rupture réseau. Application Transaction Coordinator permet de définir graphiquement des transactions longues avec conservation du contexte dans des bases de données Oracle ou Microsoft et rollbacks globaux sur l’ensemble de chaque transaction. Active Integration Monitor affiche le contenu des transactions et permet de les reprendre dans l’état dans lequel elles étaient lors de leur interruption.

Administration

Les outils disponibles pour administrer et superviser la plate-forme d’EAI, les connexions avec des agents réseaux SNMP (Simple Network Management Protocol).

Tolérance aux pannes

Les Information Brokers et les Intelligent Adapters peuvent être placés en clusters.

Sécurité

Signature digitale pour les enveloppes de messages, certificats digitaux à base de clé, cryptage SSL géré au niveau des connecteurs applicatifs. Information Broker peut rejeter toute production d’événement non autorisé provenant d’un Dynamic Adapter (Client Grouping). ActiveWorks garantit la délivrance des messages au destinataire.

XML

La communication B2B est essentiellement XML. La communication B2B est essentiellement XML. XML est aussi un des formats pris en charge par les Intelligent Adapters. Le Data Transformation Agent est capable de transformer des données non-XML (comme des données EDI) en données XML.

Ouverture

webMethods Enterprise fournit des connecteurs applicatifs pour moteurs de workflow externes. Les Agents peuvent s’interfacer avec des composants externes. WebMethods B2B Server est ouvert à LDAP et à NIS (Network Information Service).

Portabilité

ActiveWorks est disponible sur plates-formes Windows NT, Sun Solaris, HPUX, Irix, Digital Unix et Compaq Tru64.

Productivité de développement

ActiveWorks propose un grand nombre d’outils dotés d’une interface graphique conviviale qui permet un paramétrage fin en limitant la production de lignes de code. Certains éléments, comme Integration Components, sont réutilisables au travers de plusieurs Integration Processes. Le module optionnel Designer est intéressant mais nécessite des applications externes (Visio Professionnel 5.0).

Déploiement

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

Formation

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

89

EAI

De l’intégration à l’e-business / C o n c l u s i o n

C H A P I T R E

5 Conclusion En France, les produits d’EAI inspirent encore une certaine méfiance, ce qui ralentit leur implantation, alors que d’autres pays européens, comme l’Italie, semblent les adopter plus largement. Étant donné l’envergure des besoins couverts par l’EAI et le B2B, ces produits vont inévitablement s’imposer à moyen terme en France et l’EAI va devenir un marché extrêmement important dans les prochaines années. Pour favoriser l’acceptation des plates-formes d’EAI, la démarche de développement consistant en une personnalisation des fonctionnalités apportées par une plate-forme éditeur offre un compromis qui concilie la robustesse de ces outils avec les besoins de « sur mesure » des premiers projets d’intégration. En effet, il peut être intéressant de réaliser un projet d’intégration interne afin de consolider son propre système d’information et d’être ensuite en mesure de s’insérer efficacement à une chaîne d’échange interentreprises. Comme les plates-formes d’EAI du marché sont aujourd’hui des offres matures et fiables, on peut donc investir sans risque. Les bénéfices sont immédiats, entraînant un retour sur investissement réel et rapide, même si le coût d’un projet EAI est généralement élevé et sa mise en œuvre complexe. Le monde de l’échange B2B est à l’heure actuelle en pleine consolidation. Comment arbitrer au mieux la confrontation entre des technologies en cours de maturation et le besoin d’implémenter une solution d’e-business, outil désormais indispensable en matière d’avantage concurrentiel ? Il est déjà possible de se tourner vers des plates-formes capables d’implémenter sans risque des solutions fondées sur des langages stables, comme cXML, xCBL, etc., pour lesquels il existe de vrais retours d’expérience. Ceux qui mettront dès aujourd’hui en œuvre une politique d’e-business bénéficieront d’un avantage certain sur leurs concurrents, avance qu’ils pourront conserver car, comme l’affirme Sam Laufer, vice-président d’une compagnie tournée depuis 2 ans vers le B2B : « Nous avons compris que l’Internet changerait radicalement les modes de distribution et qu’il fallait s’employer à en faire notre force plutôt que d’attendre qu’il devienne notre faiblesse. » Pour en savoir plus, vous pouvez consulter : http://www.eaijournal.com Un ensemble d’articles rédigés par des consultants ou des éditeurs de solutions, des interviews, des fiches produits : une mine d’informations.

90

http://www.intelligenteai.com Le portail du groupe CMP. http://eai.ittoolbox.com/ Un portail riche des informations les plus récentes. http://b2b.ebizq.net/ http://eai.ebizq.net/ http://www.messageq.com/ Trois facettes d’un site riche en articles rédigés par des consultants ou des éditeurs de solutions d’EAI, d’eAI et de B2B.

Créé en 1988, Cosmosbay est un groupe de conseil en e-business et de mise en œuvre de e-services. Sa mission est d’accompagner les entreprises dans la définition et la réalisation de leurs solutions métiers pour le e-business. Trois pôles d’activités complémentaires constituent son offre globale : Cosmosbay consulting (stratégie & organisation), Cosmosbay agency (communication & design) et Cosmosbay systems (technologie & ingénierie). Cosmosbay maîtrise l’ensemble des problématiques de la chaîne de valeur électronique : gestion de la chaîne logistique (Supply Chain Management), intégration d’applications d’entreprise (Enterprise Integration Application), gestion de la connaissance (Knowledge Management) et gestion de la relation client (Customer Relationship Management). Cosmosbay est également un groupe français reconnu pour son expertise des technologies du web, notamment XML et Java.

C o n t a c t PARIS LYON 10, rue du Faubourg Poissonnière 84, rue du 1 er mars 1943 75010 Paris 69625 Villeurbanne Cedex Tél : +33 1 53 24 67 80 Fax : +33 1 53 24 67 89

Tél : +33 4 72 65 21 00 Fax : +33 4 78 85 58 24

MARSEILLE Bâtiment William Carr 263, Boulevard Michelet 13009 Marseille Tél : +33 4 91 77 07 91

Web : www.cosmosbay.com • E-mail : [email protected]