Professional Documents
Culture Documents
octobre 99
© 1999 O CT O Tech no log y. To us dr oi ts rés er vés
Les informations contenues dans ce document représentent le point de vue
actuel d’OCTO Technology sur les sujets exposés, à la date de publication.
Dans la mesure où les éditeurs cités doivent s’adapter aux conditions chan-
geantes du marché, OCTO ne peut pas garantir l’exactitude des informations
présentées après la date de publication.
Les noms de produits ou de sociétés dans ce document peuvent être les
marques déposées de leurs propriétaires respectifs.
Au te urs :
Les auteurs de ce document sont des consultants d’OCTO Technology, par
ordre alphabétique L. Avignon, T. Brethes, C. Devaux, P. Pezziardi.
Pour tous renseignements complémentaires, veuillez contacter P. Pezziardi
(ppezziardi@octo.fr).
Constat d’évolution
Une solution EAI contient un ensemble d’outils que l’on peut classer dans les
catégories suivantes :
Le spectre des offres actuelles est en pleine ébullition, mais le marché com-
mence à se structurer. La bataille se joue à coup d’annonces, d’alliances et
acquisitions, afin de pouvoir proposer le plus rapidement possible une offre
intégrée globale. A ce jeu, le NASDAQ devient rapidement le baromètre des
stratégies.
Nous vous souhaitons une excellente lecture, en espérant que vous prendrez
autant de plaisir à le lire que nous en avons eu à le rédiger.
Sommaire
INTRODUCTION 8
2.A RC HI TE CTU RE E AI 16
2. 1.M ÉCA NI SME S D’É CHA NGE 16
2.2 .ECH ANGE EN MODE MESSAG E 19
2. 3. LES SER VICES FO ND AMEN TA UX DE L’ EAI 23
2. 3 .1.Tr an sforma tio ns e t con ne cteu rs 23
2.3 .2.Pa sse rell es tec hn iqu es 27
2. 3. 3. La gestio n d e proce ssu s ou Work flo w 30
2.4 .L’ INTÉGR ATI ON D ES APP LICAT IONS 31
2.4 .1.L es app lic ati ons cl ie nt /ser veu r 31
2.4 .2.Le s ap plic ations 3- ti ers 32
2.4 .3.Le s ER P et autres prog icie ls mét ier 33
2. 5. AD MINI STRA TI ON ET EXPLO I TA TION 34
2. 6. GES TIO N D E LA S ÉCURIT É 36
2.7.CONCLUSION 37
3. ACT EURS D U M AR CH É 39
3. 1. ACTIVE SOFT WAR E 40
3.2 .BEA SYST EMS 42
3.3.CROSSWORLDS 44
3.4.FORTÉ 46
3.5.IBM 48
3.6.MICROSOFT 50
3.7.NEON 52
3. 8. SO FTW AR E TE CHNOL OGIE S CO RPO RATIO N 54
3.9.SOPRA 56
3.10.TEMPLATE 58
3.11.TIBCO 60
3.1 2. TS I SOFT WARE 62
3.13 .VI EWLOC IT Y (E X F RO NT EC) 64
3.14.VITRIA 66
Table des figures
Les six questions A partir de ces éléments, mettons nous par exemple à la place d’un consul-
fondamentales pour tant externe et évaluons par une note de 1 à 10 les six points suivants :
évaluer l’agilité
• Flexibilité du système
d’un SI.
Dans quelle mesure peut-on faire évoluer un projet (une application)
indépendamment des autres ? Quelle réactivité peut-on espérer pour la
mise en œuvre de projets futurs (Time to Market) ?
• Capacité d’administration et d’exploitation
Capacité de suivi des flux, maîtrise de l’intégrité transactionnelle de son
système: est-on capable de s’assurer que tel achat de produit par le
client a bien été comptabilisé, envoyé au datawarehouse, etc. ?
• Capacité du système à diminuer les délais d’échange
Le système est-il capable simplement d’évoluer vers du Straight Through
Processing (STP)1, c’est à dire de propager instantanément les événe-
ments se produisant dans l’une des applications vers les cibles ?
• Sécurité
Quel est le niveau de sécurité de ces échanges : authentification, contrô-
le d’accès, intégrité, confidentialité ?
• Coût de développement et de maintenance
Dans le coût global de ces applications (conception, développement,
intégration, exploitation), quelle est la part liée aux échanges inter-appli-
catifs ?
• Qualité de service vu du client
Est-on capable simplement de fournir au client une vision synthétique de
ces avoirs dans l’entreprise fusionnée A+B, quelle est la fraîcheur de ces
informations ?
1 La notion de STP vient historiquement du monde de la finance et des réseaux de compensation (comme Swift par exemple).
Par exemple, l’achat de titres dans une application bancaire de back-office générait une impression qui était ressaisie dans l’ap-
plication de clearing, puis envoyé sur le réseau Swift. Aujourd’hui, le processus peut s’automatiser, l’application envoie directe-
ment un message formaté au point d’entrée Swift qui le propage.
L’urbanisme
De la même manière qu’un architecte conçoit un bâtiment en fonction des
besoins exprimés par ses futurs occupants à un instant donné, un urbaniste
prend en compte les exigences d’une communauté à faire évoluer dans le
temps.
A l’origine du concept d’urbanisme, Jacques SASSOON fait l’analogie avec
une ville comme Paris et assimile les quartiers aux groupes d’applications
qui ont été conçues à peu près au même moment avec une architecture simi-
laire. On trouve alors des groupes pour les applications Mainframe en mode
Batch ou interactif, les mini-ordinateurs, le client/serveur, et maintenant les
nouvelles applications Web. Les urbanistes n’aspirent pas à démolir les
anciens quartiers à l’émergence de chaque nouveau style architectural. Mais,
ils s’efforcent de maintenir certains standards d’infrastucture dans tous les
quartiers. L’approvisionnement en eau et en électricité est nécessaire
quelque soit le quartier. Les nouveaux besoins de la communauté provoquent
parfois certains travaux d’aménagements des quartiers existants afin d’y
apposer une canalisation plus grosse par exemple. Alors que les modèles
d’architecture sont statiques, l’urbanisme doit savoir évoluer à travers le
temps et prendre en compte les besoins non seulement du présent, mais éga-
lement du passé et du futur.
De cette analogie avec la gestion de la ville, ressort un ensemble de règles
et de principes :
• Le processus métier global d’une entreprise est découpé en domaines,
contenant chacun des districts, comprenant à leur tour des blocs.
• Chaque bloc est autonome et capable d’assurer seul l’accomplissement des
fonctions qui lui sont attribuées.
• Il ne doit pas y avoir de dépendance temporelle entre les blocs, chacun opé-
rant de manière asynchrone par rapport aux autres.
• Chaque bloc encapsule les données dont il a la charge et qui ne peut être
directement accédé par un autre bloc (principe de la technologie objet)
• Chaque bloc produit des résultats et des rapports avec un format standard
sans présumer des destinataires
• Chaque bloc doit avoir un gestionnaire d’évènements d’entrée et un géné-
rateur d’événements en sortie
• Toutes les communications entre les blocs doivent s’effectuer indirecte-
ment au travers d’un gestionnaire de flux.
Les contraintes d’interactions asynchrones entre les blocs n’interdisent
cependant pas d’utiliser des technologies synchrones temps réel pour l’invo-
cation de méthodes distribuées à l’intérieur d’un même bloc.
Si l’adjonction d’une application Web à un système existant nécessite un cou-
plage synchrone étroit entre les deux blocs, on assiste alors à une fusion des
deux. C’est un peu comme la nouvelle façade d’un bâtiment. On a alors inté-
rêt à ce que les deux blocs s’assemblent parfaitement et que les fenêtres
soient bien alignées. Si à l’intérieur d’un même bloc, il existe des fortes
contraintes de standardisation d’architecture, une certaine flexibilité entre
les blocs est de mise, tant qu’un certain formalisme dans les d’échanges d’in-
formation est respecté, par l’utilisation par exemple d’un format fédérateur
comme XML.
L’entreprise, pour pallier aux problèmes évoqués plus haut, doit s’équiper d’un
système performant pour faire communiquer ces applications.
En effet, le SI n’est malheureusement pas quelque chose de monolithique. Il
évolue dans le temps, et, comme tout autre objet sur ce bas monde, obéit aux
principales lois de la physique. En particulier son entropie ne cesse de croître,
i.e. le désordre en son sein augmente : évolution des technologies et coexis-
tence de différents paliers technologiques, choix différents selon les branches
de l’entreprise, fusions/acquisitions, ouverture de canaux de distribution vers
les partenaires, les clients, etc.
L’EAI répond à la Le décideur est donc confronté à une problématique complexe d’intégration de
problématique ces systèmes hétérogènes, cette intégration devant répondre aux cinq critères
d’intégration de évoqués plus haut : flexibilité, exploitabilité, capacité de gérer certains flux
hétérogènes au sein du au fil de l’eau, sécurité et maîtrise des coûts bien entendu. L’objectif prin-
SI mais aussi vers cipal est de se donner la capacité de fournir au client final un service de
l’extérieur : clients et meilleure qualité.
fournisseurs.
Le chapitre suivant se proposant de dresser un historique des offres en matiè-
re d’EAI, nous commencerons donc par plonger dans le passé de ce marché,
pour émerger ensuite dans l’actualité des offres, et tenter d’entrevoir leurs
futures évolutions.
1. Vers l’Integration des Applications d’Entreprise
Pour résumer le paragraphe précédent, le objectif de l’EAI est d’échanger de
manière performante des informations entre applications ou progiciels, sur
plates-formes hétérogènes, dans des Systèmes d’Information en constante
évolution.
Historiquement, l’EAI 2 a été le cheval de bataille d’éditeurs comme Sopra ou
IBM depuis les années 80.
L’éditeur Français Sopra avait développé une technologie de gestion de flux (Règle du Jeux)
SOPRA a été l’un des capable de gérer des transferts de fichiers de façon globale : inventaire,
précurseurs dans la contrôle de flux et transformations. Cette initiative innovante, unique sur le
gestion des flux de marché de l’époque, se positionnait au-dessus du transport des fichiers, pour
l’entreprise. fournir des services de transformation, de routage et d’exploitation grâce à un
dictionnaire des flux.
D’autres acteurs se sont IBM proposa aussi assez tôt (à partir de 1993) un middleware asynchrone en
positionnés à différents mode message (MQSeries), c’est à dire de la “tuyauterie3” permettant de
niveaux : IBM, Tibco, développer des applications s’échangeant des informations au fil de l’eau.
Microsoft... Cette technologie se positionnait précisément sur l’interopérabilité des appli-
cations, centrales dans un premier temps, puis sur l’ensemble des plates-
formes disponibles sur le marché.
D’autres éditeurs ont par la suite proposé des offres comparables à celle
d’IBM (DEC, Pipes et plus récemment Microsoft) voire plus évoluées, comme
Tibco par exemple.
Certains utilisateurs Enfin, beaucoup de clients ont réalisé eux-mêmes leur propre système de
ont développé leurs messagerie inter-applicative et de gestion de flux. Ces initiatives, justifiables
propres systèmes de dans le cadre de projets limités, apparaissent finalement peu rentables à
communication inter- terme par rapport à l’acquisition de produits, notamment sur les aspects sup-
applicatives. port multi-plate-forme, capacité d’administration et d’exploitation, gestion
transactionnelle, outils de développement...
Le modèle de communi- Probablement mal expliqué et mal compris, limité technologiquement et com-
cation de type «Publish plexe à mettre en œuvre, ces solutions ne se sont pas généralisées et sont
& Subscribe» est plus restées pour beaucoup des solutions techniques, locales à des besoins parti-
attrayant que le modèle culiers. L’exemple de Tibco est assez révélateur : sa technologie de Publish
«Point à point». and Subscribe, déployée à Wall Street en 1980, puis dans les salles de mar-
ché du monde entier, n’a pas réussi à s’imposer réellement ailleurs que dans
ces niches. Pourtant techniquement, l’offre était très attractive, le principe en
est le suivant :
• le publisher poste des messages sans en connaître les destinataires, il
publie sur un thème, par exemple trading.achat
• le susbscriber s’abonne aux messages de trading.* et reçoit ainsi au fil
de l’eau ce qui est publié sur les thèmes trading.achat, trading.vente...
Ce principe permet un réel découplage entre les applications, beaucoup plus
qu’un moniteur de message classique qui effectue ses envois en point à point
(directement de l’émetteur vers les N récepteurs finaux, via N files d’attente).
Dans ce dernier mode en effet, les applications émettrices doivent connaître
parfaitement l’adresse des applications destinatrices.
Quel est donc l’événement qui bouleverse aujourd’hui l’état du marché ?
Pourquoi donc la presse se fait-elle l’écho de cette problématique aussi
ancienne que les Systèmes d’Information ?
La réponse tient en deux points :
• d’un côté l’offre des éditeurs s’est enrichie de nouvelles fonctionnalités
Aujourd’hui, le marché a bénéficié à ces éditeurs bien sûr, mais surtout aux
clients : il serait inimaginable de nos jours de se priver de ces systèmes et des
outils de conception, de développement et d’administration qui les accompa-
gnent.
EAI : de puissants outils De la même manière donc, le marché de l’EAI se situe en France dans la
d’interconnexion en phase de “Début d’acceptation” (il est un peu plus avancé aux Etats-Unis). Il
phase d’acceptation est enfin perçu comme un puissant outil d’interconnexion capable de résoudre
des problématiques transactionnelles, sécurisées, à caractère critique et
d’améliorer la qualité de service des systèmes actuels.
Le positionnement est clair : fédérer l’ensemble des technologies qui aujour-
d’hui tissent des adhérences fortes entre applications et y apporter une valeur
ajoutée. Les échanges sont essentiellement de type :
• échanges de fichiers,
• échanges de messages,
• systèmes de réplication SGBDR,
• systèmes d’extraction de données orientés DataWarehouse.
4 Parfois douloureusement puisque certaines entreprises ont réalisé après coup la nécessaire prise en compte des programmes
d’interconnexion dans les projets An 2000...
tés de passage en mode fil de l’eau (STP).
La solution EAI : un bus Le stratégie étant précisée, la tactique d’implémentation consiste à fédérer les
d’échange central échanges d’information autour d’un Bus d’Echange. Le Bus (ou Hub) est un
fonctionnant en mode « élément focal du Système d’Information, il centralise les flux en assurant les
Publish & Subscribe «. transformations et les routages nécessaires.
Le système fonctionne par essence en mode “Publish and Subscribe”, c’est à
dire que dès qu’une information présente dans une application est susceptible
“d’intéresser” d’autres applications, elle est transmise, non pas aux destina-
taires finaux, mais au bus d’échange. Celui-ci a la charge d’en assurer ensui-
te le routage vers les applications “intéressées” en y appliquant éventuelle-
ment les transformations nécessaires à leur bonne interprétation. Nous
détaillerons plus loin les services supplémentaires qui peuvent se greffer au
niveau de ce Bus, c’est-à-dire son niveau d’“intelligence”.
5 A noter cependant que des acteurs comme Constellar, issus des premières générations d’ETL, ont abordé le problème dans
sa globalité et offrent aujourd’hui une intégration poussée avec les outils d’EAI.
Synch rone ou async hrone ?
Les architectures distribuées et l’émergence de technologies de com-
munication entre applications imposent des choix de conception archi-
tecturale. Une des décisions importantes à prendre reste le mode de
communication : synchrone ou asynchrone?
Dans un mode synchrone, l’émetteur doit localiser le destinataire sur
le réseau, se connecter à l’une de ses instances et attendre la répon-
se. Dans un tel mode, la requête n’est jamais perdue. En cas d’erreur
ou de rejet, l’application émettrice en est directement avertie.
Les technologies RPC, HTTP, Corba, COM, etc entrent dans cette caté-
gorie.
A l’inverse, dans un mode asynchrone, la disponibilité du destinataire
au moment de l’émission n’est plus indispensable. Celui-ci traitera la
requête en temps voulu. Charge au middleware utilisé de garantir alors
que la requête ne se perde pas.
Les technologies de Message Oriented Middleware comme IBM
MQSeries, Microsoft MSMQ, Tibco/Rendez-Vous entrent dans cette
catégorie.
Si l’émetteur de la requête a besoin de la réponse avant de passer à
une autre tâche, les technologies synchrones sont à privilégier, ce qui
nécessite alors un haut niveau de disponibilité à la fois du réseau et
des applications destinatrices.
Si une telle disponibilité n’est pas garantie ou si la réponse n’est pas
immédiatement nécessaire, il sera alors préférable de mettre en
œuvre des communications orientées sans connexion.
D’une manière générale, il est fortement conseillé de réduire les
besoins de synchronisation entre les applications afin d’améliorer leur
disponibilité et leurs performances.
Un mécanisme d’échan- L’idée de faire communiquer les applications en mode message est relative-
ge avec fort découplage: ment ancienne puisque avant d’apparaître dans les Message Oriented
le message. Middleware (MOM) actuels, elle est le fondement de la communication entre
objets, distribués ou non. Un message peut contenir plus que de la donnée
simple. Il pourra, comme dans le cas des communications entre objets, inclu-
re la méthode, c’est à dire l’action qu’il représente. Exemple : envoi d’un mes-
sage commander contenant la quantité, le code de l’article ; envoi d’un mes-
sage règler contenant la devise, le client et le montant, etc.
Pour assurer le transport de ces messages, nous avons deux principales tech-
nologies à notre disposition :
• les Message Oriented Middleware
Des produits comme MQSeries (IBM), Tib’Rendez-vous (Tibco),
MessageQ (BEA), MSMQ (Microsoft) proposent ce style d’offre.
• les Object Request Broker (ORB)
Visibroker (Inprise), Orbix (Iona), ou plus récemment les offres
d’Application Server (IBM WebSphere, BEA WebLogic, Microsoft MTS,
Sun, etc.) qui sont parfois bâties au-dessus d’un ORB.
L’interopérabilité soulève cependant une contrainte forte : ne pas lier les sys-
tèmes entre eux. En particulier, le fait que, pour échanger, deux applications
doivent être simultanément disponibles en permanence n’est clairement pas
acceptable.
En ce sens, la vision de l’OMG6 qui propose une communication synchrone
d’objets à objets est irréaliste dans le cadre de l’EAI.
Les services d’échanges Les systèmes doivent demeurer le plus indépendants possibles, et les méca-
asynchrones du stan- nismes qui les lient le plus asynchrone possible. Le système A doit fonc-
dard CORBA ne satis- tionner même si le système B n’est plus disponible ; à son retour, B récupé-
font pas aujourd’hui rera ce qui lui était destiné.
aux besoins complexes
Bien entendu, on rétorquera que les ORB disposent de mécanismes asyn-
de l’EAI.
chrones que sont les Event Services et autre Notification Services. Cependant,
on l’a vu, le simple transport ne suffit pas. La valeur ajoutée d’une architectu-
re EAI se situe au niveau des services de transformation et de contrôle de flux
qu’elle met en œuvre, voire au niveau d’autres services que nous détaillerons
plus loin.
Dans ce domaine, seules les offres se fondant sur des MOM sont aujour-
d’hui à même de couvrir ce besoin.
Routage et transforma- Que le lecteur ne conclue pas trop vite, les éditeurs d’ORB ou de serveurs
tion sont assurés par les d’applications commencent à intégrer ce type de technologie dans leurs pro-
Message Broker. duits.
Voir à ce propos Iona et le projet Warhol, Forté Fusion, BEA et son partenariat
avec TSI (l’éditeur du Message Broker Mercator), Jasmine de Computer
Associates, IBM avec WebSphere ou Microsoft COM+.
Du reste, même si l’asynchrone doit être privilégié dans la mesure du possible,
il est des cas où le mode synchrone question/réponse est nécessaire.
Par exemple dans le cas d’une consultation de référentiel externe, bloquante
pour un processus donné.
On verra donc dans l’avenir des produits s’appuyer indifféremment sur du
middleware synchrone (HTTP, IIOP, RMI, DCOM, etc.) ou asynchrone
(MQSeries, MSMQ, etc.).
Bien que le retard de l’offre EAI des éditeurs de serveurs d’applications soit
encore important, il est donc probable que les deux approches fusionnent à
moyen terme : les communications en entrée et en sortie du serveur d’appli-
cations seront pilotées par un moteur d’EAI, fournissant des services de bien
plus haut niveau que l’accès à un protocole technique comme HTTP ou IIOP.
Pour les entreprises, il n’y a donc pas de choix à proprement parler, pour
démarrer un projet d’EAI aujourd’hui, il faut se tourner vers les offres de MOM
et de Message Broker.
L’important étant de constater qu’il s’agit d’une trajectoire claire du marché,
c’est-à-dire dans laquelle s’inscrivent aussi bien les acteurs historiques du
monde de l’asynchrone que les ténors du moniteur transactionnel ou du ser-
veur d’applications.
Nous vous proposons donc au travers des prochains paragraphes de décrire
les briques d’architecture qui incluent le transport et les services à valeur ajou-
tée d’une architecture EAI : transformations, routages, passerelles, connec-
teurs, gestion de processus complexes (workflow).
Enfin, nous illustrerons les aspects liés au développement d’application et la
problématique d’administration et de sécurité.
6 Object Management Group, groupement d’éditeurs et d’utilisateurs publiant la standard CORBA (Common Object Request
Broker Architecture).
d’une file d’attente commue des deux parties. Si l’application émettrice doit
fournir l’information à un deuxième programme R2, elle doit poster le mes-
sage une seconde fois.
Fi gu r e 8: Ec ha nges v i a un MOM
La principale fonction Au-delà de la simple gestion de files d’attente, le MOM assure un certain
d’un MOM est de nombre de services pour sécuriser l’architecture :
transmettre des mes-
• Garantie de délivrance
sages de manière
sécurisée Un message, une fois soumis par l’application, sera forcément traité par
le système : soit l’application réceptrice le consomme (et il y a garantie
d’unicité) soit sa durée de vie expire et il est envoyé dans une file d’at-
tente particulière (dead-letter queue) où une action de l’exploitant est
requise.
• Notification
Il est possible de “simuler du synchrone” par l’utilisation de reply queue
dans laquelle l’application émettrice attend une réponse en retour de
son message.
• Priorité, groupage des messages
Il est possible de marquer les messages comme ayant une priorité par-
ticulière ou comme faisant partie d’un groupe de messages.
• Sécurité
Il est intéressant de pouvoir restreindre l’accès pour des files d’attente
particulières. Par exemple tout le monde ne doit pas pouvoir publier des
messages dans une file d’attente “paiement” sans contrôle. Un messa-
ge peut être authentifié, son contenu rendu intègre ou confidentiel. Nous
détaillerons ces points au paragraphe Sécurité.
• Triggering
Sur l’arrivée d’un message dans une file d’attente, il est possible de
déclencher automatiquement un programme. Par exemple, une transac-
tion, une mise à jour de base de données, etc.
• Transaction
Le MOM peut se comporter comme un Ressource Manager vu d’un
moniteur transactionnel ou d’un OTS. Ainsi, il est possible d’écrire des
composants s’exécutant dans un Application Server et qui réalisent une
mise à jour de base de données et un envoi de message, le tout de
manière transactionnelle.
Inversement, le MOM peut aussi jouer le rôle du Transaction Manager,
c’est le cas par exemple lorsque le MOM synchronise l’envoi d’un mes-
sage avec des mises à jour de plusieurs SGBDR
Un point sur les modèles de communication
L’habitude est de classer les méthodes de communication entre applications
en cinq modèles. Chacun de ces modèles repose sur l’un des deux principes
de base suivants :
• Le mode bidirectionnel souvent orienté connexion, correspond à la plupart
des implémentations de communication conversationnelle et
question/réponse
• Le mode unidirectionnel souvent orienté sans connexion, correspondant
généralement aux implémentations par messages.
Conversationnel : Dans ce mode, les deux applications communiquent à
l’intérieur d’une même connexion, un peu comme une conversation télépho-
nique entre deux personnes. Il suppose que les deux partenaires soient dis-
ponibles au moment de l’échange. L’émetteur initialise la connexion. Un dia-
logue sous forme de questions/réponses s’instaure. Puis la communication
prend fin sur demande explicite d’un des participants.
Request/Reply : Ce mode est également synchrone, impliquant par consé-
quent la disponibilité des deux partenaires. C’est le mode d’implémentation
des appels de fonctions distantes (RPC). Une application appelle une fonc-
tion qui s’exécute à distance, de manière transparente. L’application appe-
lante reste bloquée le temps d’exécution de la requête.
Message Passing : A l’inverse des deux modes précédents, ici l’échange
est généralement unidirectionnel et jamais bloquant, elle prend la forme d’un
échange de message, de la même manière que l’émission d’une lettre. Ce
mode étant sans connexion, la disponibilité du destinataire à l’instant de
l’émission n’est pas nécessaire.
Message Queuing : Ce mode est très similaire au mode précédent, il en est
une implémentation “sécurisée”. Entre l’émission et la réception, le messa-
ge est stocké sur disque. Comme précédemment, la disponibilité du desti-
nataire au moment de l’émission n’est pas nécessaire puisque le paradigme
de base est sans connexion.
Publish-and-Subscribe : C’est le troisième mode mettant en œuvre
l’échange de messages. Ici l’échange n’est plus 1 à 1 mais 1 vers N. Un mes-
sage est envoyé par un émetteur à plusieurs destinataires. Ce modèle repo-
se sur un échange de messages et présente donc les avantages liés au
modèle sans connexion.
Les applications pevent donc être directement liées à la couche transport (MOM,
fichiers, email ORB...). Dans le cas du MOM, les applications utilisent des verbes
très simples de type mq_put pour poster des messages et mq_get pour les retirer :
La différence fondamentale entre les 2 modes réside dans le fait que, pour le
premier mode, les applications embarquent du code pour publier et s’abonner.
Dans l’autre mode, les applications publient sur des files d’attente du Hub.
Elles utilisent encore l’API mq_put/mq_get du MOM comme dans le cas du
point à point, mais uniquement pour communiquer avec le Hub : N applica-
tions génèrent N flux possibles (configuration en étoile vers le Hub).
7 Exemple : tous les ordres de paiement de moins de 10 000 F sont routés vers tel réseau de compensation, ceux de plus de
10 000 F vers tel autre : le routage dépend du contenu du message.
Le mode centralisé du Concrètement, le publish/subscribe décentralisé s’applique à l’échelle
modèle Publish & d’une application (par exemple une application de Front Office qui “s’abonne”
Subscribe est adapté à à telle cotation de titres), mais n’est pas adapté à une architecture EAI à
la problématique d’EAI. l’échelle de l’entreprise étendue. Pour cela, le Publish/Subscribe centralisé, à
l’aide d’un Message Broker, va permettre d’assurer au niveau central un cer-
tain nombre de services additionnels tels que les transformations de mes-
sages, les passerelles vers d’autres systèmes ou middlewares, ainsi que la
gestion de processus complexe. Ces services vont permettre de diminuer la
part de code nécessaire à la communication dans les applications.
0 1 2 3 4
01234567890123456789012345678901234567890
0012670000DUPONT Gérard
0012671000DURANT Gabriel
...
<CLIENT><ID>0012670000</ID><NAME>DUPONT</NAME>
<FIRSTNAME>Gerard</FIRSTNAME></CLIENT>
<CLIENT><ID>0012671000</ID><NAME>DURANT</NAME>
<FIRSTNAME>Gabriel</FIRSTNAME></CLIENT>
...
Les éditeurs de format Dans une architecture à base de Message Broker, il est possible d’externaliser
sont de puissants outils totalement cette étape de transformation au niveau du broker. L’intérêt est
dédiés à la description multiple :
sémantique des
• Le développement est facilité par l’utilisation de l’éditeur de formats, qui
messages.
est en fait un AGL dédié à la conception de règles de formatage.
En particulier, l’outil va permettre de “parser” des messages, de définir
des champs, d’appliquer plusieurs règles sur un champ, de réorganiser
les champs, etc. pour produire un nouveau message.
• Les règles de transformation sont centralisées, les compétences néces-
saires minimisées.
Le développement de ces modules n’est plus à la charge des projets
applicatifs, mais devient l’affaire d’une équipe dédiée à la gestion des
flux. Un référentiel de “méta-données” décrivant les données de l’entre-
prise est constitué.
• Le système, dédié à cette tâche, est beaucoup plus robuste que la
somme des interfaces précédemment utilisées.
Les connecteurs Au-delà de cette possibilité de développement, un des grands intérêts des
standards (formats Message Broker du marché réside dans la disponibilité de connecteurs stan-
prédéfinis) augmentent dards. Un connecteur est un ensemble de règles de formatage destiné à inter-
fortement la facer des messages vers :
productivité et la
• des ERP8 : SAP, PeopleSoft, JD-Edwards, Baan, Oracle Applications, etc.
maintenabilité d’une
solution EAI. • des formats standardisés
■ finance : clearing Swift, Fix, CHAPS, EuroClear, ...
■ industrie, santé : réseaux EDIFACT, X.12 EDI, HL7, ...
■ autres domaines : télécom, transports, énergie, ...
• des progiciels orientés métier : facturation (Kenan, BSCS, etc.), gestion
de la relation client (Siebel, Vantive, Clarify, Remedy, etc.), ...
• des formats techniques : XML, SGML, copy book COBOL, …
Ces connecteurs réduisent considérablement l’effort nécessaire à l’intégration
de ces progiciels ou réseaux à valeur ajoutée dans le Système d’Information.
Cette économie est d’autant plus intéressante à long terme que la mainte-
nance est garantie par l’éditeur. Celle-ci, à défaut d’être gratuite, permet une
réelle maîtrise des coûts d’évolution du SI.
Reprenons l’exemple du chapitre 2, et comparons par exemple l’effort initial
puis récurrent nécessaire à l’intégration de l’ERP avec le reste du SI : le déve-
loppement des nombreux scripts d’import/export9, de transformation et de
transport est remplacé par la mise en œuvre de produits et leur paramétra-
ge. De plus, la compatibilité de ces produits avec les futures versions des pro-
giciels est garantie par l’éditeur. Ce point est fondamental, car même si les
coûts de maintenance du Message Broker ne sont pas négligeables, ils sont
connus. Ce qui n’est pas forcément le cas pour des projets de maintenance
nécessitant du développement interne.
Le schéma suivant positionne le service dans l’architecture, les transforma-
tions sont développées au niveau du Message Broker, où des connecteurs
Point clef de l’étape de Pour les nouvelles applications, il est important de ne pas continuer à réin-
formatage : passer par venter différents types de formats pour désigner le même type d’événement.
un format pivot . En ce sens, l’introduction d’un format pivot, dont XML pourrait constituer l’im-
plémentation, est fondamentale pour limiter le volume des transformations.
Le format pivot va définir de manière unique dans l’entreprise la représenta-
tion d’une donnée métier : un client, un paiement, une commande de produit,
un achat de titres, une compensation, etc.
Certains éditeurs ont bien perçu ce besoin, généralement ceux qui ont une
approche “top-down”, c’est à dire avant tout une vision métier, qu’ils implémen-
tent ensuite eux-mêmes. Le principe est beau... mais structurant !
Avant de standardiser toute l’entreprise, une approche incrémentale devra être
adoptée.
X ML : la s olutio n de l ’interopérabilité
Quand on parle de commerce électronique, l’image qui se dégage est celle
d’un site Web où l’on peut acheter des biens et des services.
Ce commerce électronique, appelé Business to Consumer (BtoC) ne repré-
sente en fait qu’environ 30% du chiffre d’affaire de ce secteur.
Où sont donc passés les 70% restants ?
Réponse : dans le commerce inter-entrerprises (Business to Business,
BtoB)... et encore peu sur Internet.
Jusqu’à présent, les entreprises utilisait l’EDI (Electronic Data Interchange)
pour se connecter avec leurs fournisseurs et leurs clients.
Mettant en œuvre des connexions de type point à point sur des réseaux pri-
vés (ou public) de type X.400, ces solutions se sont avérées coûteuses et
complexes. Seules de grandes entreprises ont pu investir et proposer (impo-
ser... !) ce type de système à leurs prestataires.
Aujourd’hui, les technologies Internet et le standard XML sont des alterna-
tives beaucoup plus simples et économiques, permettant à une multitude de
nouveaux acteurs d’y participer.
En fait, cette migration du trafic EDI vers des flux XML sur l’Internet va pro-
longer la vie des systèmes existants et répondre aux besoins d’intégration de
tous les partenaires (fournisseurs, clients, tiers,...) de manière beaucoup
plus ouverte.
L’exemple suivant donne une idée de la codification XML pour un échange
EDI, ici la commande d’un livre:
<?xml version=»1.0» encoding=»ISO-8859-1» standalone=»no»?>
<?xml-stylesheet href=»edi-lite.xsl» type=»text/xsl»>
<!DOCTYPEBook-Order SYSTEM «edi-lite.dtd»>
<Title>EDITEUR Lite-EDI Book Ordering</Title>
<Order-No>967634</Order-No>
<Message-Date>19990308</Message-Date>
<Buyer-EAN>5412345000176</Buyer-EAN>
<Order-Line Reference-No=»0528835»>
<ISBN>0201403943</ISBN>
<Author-Title>Bryan, Martin/SGML and HTML Explained</Author-Title>
<Quantity>1</Quantity>
</Order-Line>
<Order-Line Reference-No=»0528836»>
<ISBN>0856674427</ISBN>
<Author-Title>Light, Richard/Presenting XML</Author-Title>
<Quantity>1</Quantity>
</Order-Line>
</Book-Order>
XML représente un élément fédérateur important de l’EEI (Intégration Extra
Entreprise). Il permet aux compagnies de définir, pour les messages qui vont
constituer les flux entre les systèmes, des dictionnaires standards partagés
par les fournisseurs et des tiers tels que les portails ou les systèmes de paie-
ment. Des éditeurs de solutions de commerce électronique intégrent de plus
en plus des composants d’accès standards aux catalogues des fournisseurs.
Par exemple, le dictionnaire “Common Commerce Library” de CommerceOne
définit au format XML des objets et des transactions génériques élémen-
taires. Ariba annonce Commerce XML (cXML) qui est un ensemble de DTD
allégées pour des informations de catalogues et de transactions d’achat.
Parmi les initiatives de normalisation en cours, BizTalk de Microsoft offrira
des DTD pour tous les types de flux (commandes, personnel, comptabilité,...)
entre les principaux ERP (SAP, PeopleSoft).
Les éditeurs de progiciels intégrés n’ont pas attendu les organismes de stan-
dardisation et proposent déjà des solutions d’interopérabilité inter entreprise
basées sur l’emploi du format XML. C’est le cas notamment de SAP dont le
dernier module SAP B2B Procurement permet l’intégration dans le SI d’une
entreprise des catalogues de ses fournisseurs. Les éditeurs profitent de la
flexibilité et de la puissance de cette technologie à l’intérieur même de leurs
produits. En outre, la plupart des Message Brokers proposent une intégration
forte avec le format XML.
Les deux premiers points vont nécessiter l’utilisation d’une passerelle entre le
MOM et le SGBDR. Suivant les technologies, ces passerelles sont fournies par
l’un ou l’autre des éditeurs. A titre d’exemple, Oracle propose sa technologie
Oracle Gateways pour s’interfacer à MQSeries. Tibco fournit quant à lui sa
propre solution d’interfaçage aux dernières versions d’Oracle (Tib/Connect for
Oracle).
Ces passerelles permettent de déclencher des ordres SQL ou des procédures
stockées sur arrivée de message, et inversement d’émettre ou recevoir des
messages depuis le langage de la base de données (PL/SQL, TransacSQL,
Java, etc.). Nous aborderons un exemple concret d’un tel développement au
paragraphe Développement.
Concernant le troisième point, c’est à dire la capacité d’utiliser ou de mettre
à jour des données SGBDR dans le Message Broker, le besoin est plus ou
moins bien pris en compte selon les produits.
L’idée est de créer une règle qui prendrait par exemple un message du type
suivant :
0 1 2 3 4
01234567890123456789012345678901234567890
0012670000DUPONT Gérard
0 1 2 3 4
01234567890123456789012345678901234567890
0000993223DUPONT Gérard
Des efforts peuvent encore être réalisés pour traiter correctement ces aspects.
En effet, les éditeurs (IBM, Microsoft, etc.) peuvent améliorer l’intégration de
ces technologies qui demeurent complexes. On peut imaginer des processus
plus simples, qui éviteraient notamment de devoir programmatiquement
construire les messages pour les envois, et de les “déplier” à la réception.
Ces initiatives verront le jour dans COM+ et probablement dans les prochaines
versions d’EJB ou via des implémentations propriétaires (Iona, IBM, etc.).
l Le transfert de fichiers
La prise en compte des L’interfaçage de l’architecture EAI aux transferts de fichiers est fondamentale, en
transferts de fichier au particulier pour permettre une reprise de l’existant par étape. Les transferts de
niveau du Hub central fichiers existants seront petit à petit intégrés dans le Bus d’Echange, et éventuel-
permet une migration lement migreront définitivement pour certains d’entre eux vers un mode fil de l’eau.
évolutive vers un mode
Pour assurer cette évolution, le système doit offrir la possibilité d’intégrer bien
message.
sûr des transferts de fichiers, mais aussi d’offrir la possibilité :
• de passer du fichier au message,
Un fichier reçu dans le Bus d’Echange peut être séparé en autant d’enre-
gistrements qu’il contient, ces enregistrements étant réémis sous forme de
messages pour être traités normalement par le Bus. Exemple de besoin :
une application existante ne communique qu’en mode fichier, alors que de
nouvelles applications ont déjà été adaptées au mode message.
• de passer du message au fichier.
Des messages reçus peuvent être stockés par le Bus pour être transmis
en batch sous forme de fichier. Exemple de besoin : une application de
comptabilité, qui ne fonctionne pas (encore !) au fil de l’eau, reçoit la
consolidation des événements de la journée pour les traiter le soir.
BEGIN
— Ouvre la file d’attente QUEUE en lecture.
queue.OBJECTNAME := ‘QUEUE’;
PGM.MQOPEN@pg4mq(queue, PGM_SUP.MQOO_INPUT_AS_Q_DEF,
objectHandle);
Cet exemple de procédure stockée pourrait bien entendu être invoqué sous
forme de trigger et déclenché à chaque mise à jour de table.
Une seconde solution, sans impact sur l’application, consiste à utiliser un
outil de réplication. L’agent du moteur de réplication “surveille” certaines
tables et émet un événement dès qu’une mise à jour se produit.
Cet événement peut être utilisé pour propager la mise à jour de la table sur
d’autres bases, mais il peut aussi générer un message MOM (MQSeries,
MSMQ, etc.), qui pourra être traité dans le cadre de l’architecture.
Figu re 19: Ex emp le de pro gra mmat i on vi sue ll e avec Vi sua l Ba sic
Enfin, comme nous l’indiquions en introduction, il est fort probable que l’inté-
gration avec les serveurs d’applications se fasse encore plus étroite par la sup-
pression de l’étape de codage au profit d’une simple déclaration. Pour qu’un
composant émette un appel de méthode en asynchrone au travers du bus de
message, il suffira de le lui indiquer par paramétrage. Avec la sortie de COM+
sous Windows2000, Microsoft se lance déjà dans cette direction.
11 Uniquement dans le monde COM avec le composant MSMQ, les Enterprise Java Bean (EJB) MQSeries devraient sortir cette
année.
Exemple : création d’un fichier formaté demandant la liste des opérations
comptables de tel type, depuis telle date, soumission au progiciel qui renvoie
en retour un fichier formaté de réponse.
Ces interfaces en mode batch devront ainsi être utilisées en mode fil de l’eau,
en entrée du progiciel : l’arrivée d’un message (déjà formaté par le Message
Broker) déclenche un programme utilisant les interfaces batch du progiciel
pour importer le message.
On parle de connecteur léger, car c’est le Message Broker qui se charge de
toute la partie formatage, le connecteur sur la machine du progiciel cible ne fait
que soumettre un document au travers d’une API technique : submit(Idoc).
Une deuxième possibilité souvent employée est l’utilisation d’API publiées par
le progiciel : BAPI (SAP), BOI (Baan), Message Agent (PeopleSoft), Kenan,
etc. Ces API sont disponibles en C, en Cobol, en Shell, etc., mais aussi aux
normes des composants du marché : Corba (puis EJB dans le futur) et COM.
Des programmes, déclenchés à l’arrivée de messages spécifiques, pourront
utiliser ces API pour mettre à jour des données du progiciel.
Dans ce cas, on parle de connecteur lourd, car le programme en question
doit disposer de l’intelligence nécessaire au traitement de n’importe quelle
requête, ce en utilisant l’API métier du progiciel.
Dans le sens progiciel Pour intégrer un progiciel en mode fil de l’eau, et surtout pour toute commu-
vers l'extérieur, un nication en sortie du progiciel, celui-ci doit supporter la notion de “trigger”.
mécanisme de " trigger " C’est à dire la capacité de déclencher un programme sur apparition d’un évé-
est nécessaire. nement particulier à l’intérieur de l’ERP (création d’un nouveau client par
exemple).
A l’aide de ces triggers, un événement survenu dans le progiciel pourra aisé-
ment déclencher l’émission d’un message. Cependant, tous les ERP ne sup-
portent pas ce type de fonctionnement. Pour SAP, il s’agit par exemple de la
technologie Application Linking Enabling (ALE). Il est un des rares à proposer
des fonctionnalités de triggering. La méthode plus communément proposée
par les éditeurs reste le polling.
Les éditeurs de Message Broker supportant des connecteurs vers des progi-
ciels fournissent tous des solutions d’intégration diverses. Un des aspects
importants à retenir quant à la qualité de cette intégration est l’exhaustivité
des interfaces (des labels de compatibilité peuvent aider le décideur dans son
choix) et la capacité de fluidifier la communication (via le support de “trig-
gers”). Le support affiché d’un connecteur particulier ne signifie pas forcément
son adéquation dans un autre contexte ... souvent seules quelques fonction-
nalités mises en œuvre chez un client suffisent à l’éditeur pour proclamer le
support d’un progiciel !
XML se dégage comme Enfin, il est intéressant de noter que les ERP commencent à voir en XML un
le format standard format capable d’unifier ces différentes technologies d’accès. Une telle stan-
d'échange entre ERP. dardisation permettrait à terme de bénéficier d’une vision homogène des don-
nées et traitements disponibles dans ces systèmes, au travers de flux XML nor-
malisés. La première de ces initiatives est BizTalk de Microsoft ... mais sans
offre technique à l’heure actuelle, l’éditeur de Redmond tentant d’occuper le
terrain marketing !
12 Candle, BMC ou MessageQuest offrent des solutions de qualité pour MQSeries. Microsoft intègre l’administration de MSMQ dans
sa console d’administration : la MMC. Pour les couches Message Broker et Workflow, chaque éditeur propose sa propre solution.
13 On peut néanmoins citer les Monitoring Tools de TSI, Neon Track de NEON et saluons l’avance de Sopra en ce domaine, sa
solution de gestion de flux A&P étant destinée à cet usage.
sant des indicateurs de haut niveau sur les flux mis en œuvre.
L’administration d’un produit est souvent la chose par laquelle l’éditeur finit ...
compte tenu de la maturité moyenne du marché, cette fonction n’est pas
encore prise en compte dans sa globalité. Au vu des alliances en cours, nul
doute en revanche que les quelques acteurs qui vont se dégager proposeront,
eux, des solutions performantes dans un cadre intégré.
14 Les technologies de choix pour ce service et pour les autres sont bien entendues celles de l’Internet, et notamment les cer-
tificats X.509 et la cryptographie par clé publique et privée.
15 Exemple : cet ordre d’achat de titres, émis par le courtier XX est valide, mais dépasse le montant des risques alloués pour
sa division.
notamment. Ce produit gère l’authentification et l’intégrité/confidentialité des
messages et le contrôle d’accès doit être implémenté à la main. Microsoft MSMQ
inclut en standard les fonctions d’authentification (mécanisme NT), de contrôle
d’accès sur les files d’attente et la confidentialité et l’intégrité des messages.
2.7. Conclusion
Il est maintenant possible de représenter l’ensemble des briques techniques
d’une offre complète d’EAI :
16 La limitation actuelle tourne autour des 4 Mo pour certains produits (jusqu’à 100 MO pour MQSeries sur certaines plates-formes).
Au-delà, des solutions particulières de découpage doivent être mises en œuvre, FTF/MQ de MessageQuest par exemple.
17 C’est ce nouveau critère qui fait que des sociétés fortement déficitaires comme Amazon.com ou Yahoo! sont largement repré-
sentées en bourse.
3. Acteurs d u marché
Nous proposons dans ce chapitre d’effectuer un tour d’horizon des principaux
acteurs du marché de l’EAI. Ce chapitre a été rédigé à partir d’interviews des
éditeurs concernés et d’évaluations de leurs produits, soit en interne, soit pour
le compte de nos clients. Seuls Active Software et Vitria, qui ne sont pas repré-
sentés en France, n’ont pas fait l’objet d’une évaluation détaillée.
Avant les synthèses respectives des offres EAI, dressons un diagramme avec :
• Sur l’axe des abscisses, le niveau de finition de l’offre. L’éditeur propose-
t-il un outil intégré, des briques EAI ou un framework sur lequel bâtir des
solutions ?
• Sur l’axe des ordonnées, le degré de couverture de leur offre EAI actuelle.
En outre, des flèches indiquent la trajectoire suivie par l’éditeur et son poten-
tiel d’engagement. Le schéma s’inscrit donc dans le temps et fait notoirement
apparaître un regroupement du marché vers des offres globales.
Cette évaluation représente une photo du marché tel qu’OCTO Technology le per-
çoit en date d’écriture. Elle est donc sujette à certains changements (voire bou-
leversements !) à moyen terme. Enfin, compte tenu de la fragmentation actuel-
le du marché, cette liste ne se veut pas exhaustive... l’objectif est avant tout de
fournir au lecteur un positionnement relatif des principaux acteurs de ce marché.
Pour mieux apprécier cette vision globale, chaque éditeur mentionné fait l’ob-
jet d’une fiche descriptive dans les pages qui suivent. Pour chacun d’entre eux,
nous structurerons l’exposé en plusieurs points :
• Présentation de l’éditeur, analyse financière
Chiffre d’Affaire et Résultat Net pour l’année 1998, nombre d’employés,
données boursières le cas échéant
• Positionnement de l’offre en mettant en évidence les briques supportées
dans le schéma général de l’architecture EAI,
• Origine du produit et principales caractéristiques,
• Perspectives et stratégie de l’éditeur.
3.1. A ctive Software
ActiveWorks Integration System
www.activesw.com
CA / RN : 13,9 M$ / -10,9 M$
Valorisation boursière : 553,7 M$
Références : >80
Employés : 120
Pas présents en France (Allemagne)
Caractéristiques du produit
• L’offre ActiveWorks s’articule autour d’un gestionnaire d’évènements,
l’Information Broker. Celui-ci réalise le transport et le routage des mes-
sages, et supporte le routage sur contenu. Un bon support de la sécurité est
offert, au travers de la notion de rôles (client group) et d’autorisation, ainsi
que l’utilisation de SSL (utilisation des outils SecureWeb de Terisa Systems).
• Le module ActiveWorks Designer autorise le design graphique de processus
au standard UML. Ces processus sont modélisés au travers de diagrammes
de séquences d’évènements, et de diagrammes d’activité. Il est ensuite
possible de les tester directement, avant la phase de génération de code
Java à destination de broker.
• Ce code Java généré peut être aussi créé à la main par l’utilisation du modu-
le Integration Logic Agent, il permettra donc d’étendre les fonctionnalités du
broker. Le Business Rule Agent permet d’écrire des règles complexes au tra-
vers d’un moteur d’inférence (système expert). Enfin le Data Transformation
Agent permet de créer graphiquement des transformations entre évène-
ments de différents formats, c’est lui qui est responsable des transforma-
tions EDI ou SAP IDoc par exemple.
• L’Event Type Editor permet classiquement des définir graphiquement les for-
mats des évènements, qu’il gère dans un référentiel. A noter la possibilité d’uti-
liser des plug-in spécifiques pour faciliter l’utilisation de certains adaptateurs.
• Ces adaptateurs, les Dynamic Adapters, permettent une connectivité midd-
leware : fichiers, SGBDR, CICS, MQSeries et vers des applicatifs : SAP,
Clarify, PeopleSoft, Siebel, Vantive, Pivotal, etc. A noter la forte politique de
partenariats d’Active, qui permet d’étoffer rapidement ce catalogue
• La configuration du réseau Active et la gestion de la sécurité sont confiés au
module ActiveWorks Manager. Bien que le broker soit compatible SNMP
(permettant de le connecter à un framework d’administration plus global,
rare !), ActiveWorks Monitor propose du tracking d’évènements dans le bus.
• Enfin, en plus de ses activité d’éditeurs, Active propose de structurer les pro-
jets de mise en œuvre de son produit au travers d’une méthodologie : Active
Integration Methodology (AIM)
Forces Faiblesses
• Forte politique de partenariats (HP, • Pas de modélisation réelle de proces-
Oracle, Sun/Netscape, Vantive, Clarify, sus, il faut passer par les différents
Cisco, intégrateurs, etc.) permettant modules du système : Designer,
notamment d’offrir de nombreux adap- Broker et Agents (code Java).
tateurs • Taille de l’éditeur
• Offre autonome, fondée sur bus sécu-
risé
Positionnement et Stratégie
• Projets d’intégration de progiciels (bibliothèques d’adaptateurs)
• Optimisation du produit pour une meilleure montée en charge
Caractéristiques du produit
• BEA a acquis ses lettres de noblesse grâce au moniteur transactionnel
Tuxedo, c’est sur ce produit, et sur son moniteur asynchrone /Q (beaucoup
moins répandu ...) que se fonde l’offre eLink Platform.
• eLink Platform est l’assemblage de plusieurs technologies, d’origine BEA en
couches basse, puis TSI Mercator comme moteur de transformation (Data
Integration Option) et Xerox InConcert (Business Process Option) comme
gestionnaire de flux, ces offres étant “OEMisées” et packagées comme des
modules optionnels.
• Le transport de choix est Tuxedo, c’est à dire un mode synchrone. /Q peut
être utilisé, mais explicitement par API : TMQFORWARD() depuis la transac-
tion. C’est le cas pour l’adaptateur SAP, qui requiert une garantie de déli-
vraison, et où tous les IDoc transitant par Tuxedo sont sauvegardés dans des
queues /Q.
• Mercator est un des Message Broker leader du marché. Il propose toutes
les fonctions standards attendues dans ce type de produits, y compris la
capacité d’enchaîner des traitements (ici, seul le moteur de transformation
est utilisé). Les connecteurs de Mercator (ERP, finance et commerce élec-
tronique) ne sont pas utilisés, BEA développe ses propres interfaces, aujour-
d’hui SAP et PeopleSoft ; Vantive, Kenan et Clarify prévus pour la fin de l’an-
née.
• Le moteur de workflow, InConcert, permet de modéliser graphiquement des
flux complexes, en revanche il n’est pas encore intégré au reste de l’envi-
ronnement. L’offre pourrait également héberger un second moteur, celui de
HP (changeEngine).
• Ces différents partenariats ont permis à BEA de se constituer rapidement
une offre qui lui permet d’occuper le terrain.
• Il peut y avoir nécessité d’effectuer un travail d’intégration des différents
modules, notamment en terme d’outillage de développement et de réfé-
rentiel, puis en aval en ce qui concerne l’administration et la sécurisation
de l’ensemble.
Forces Faiblesses
• Segment stratégique pour BEA qui doit • Offre récente, susceptible de change-
faire face à IBM pour couvrir une ments
gamme qui va du serveur d’application • Offre orientée synchrone, et nécessitant
à l’EAI un déploiement lourd de Tuxedo.
• Capitalisation sur le moniteur L’asynchrone à travers /Q peut être utili-
transactionnel Tuxedo sé, mais nécessite l'écriture de code.
Positionnement et Stratégie
• A l’image du rachat de WebLogic pour asseoir sa présence sur le marché
des serveurs d’applications EJB, BEA poursuit une politique de croissance
externe... pour l’instant uniquement via des partenariats (TSI, Xerox, HP)
• BEA croit au développement d’une offre EAI basée sur des flux importants
supportant différents protocoles (synchrone, asynchrone, publish/subscribe,
…) nécessitant de réels projets d’intégration.
• Le futur de l’offre passera donc par une clarification de la stratégie, ce qui
sur ce marché signifie l’acquisition des technologies nécessaires, et leur
fusion au sein d’un produit.
Caractéristiques du produit
• Crossworlds est né en 1997 de l’idée qu’il y avait autant de valeur ajoutée
dans la mise en œuvre de progiciels (ERP et CRM notamment) que dans
les flux qu’ils généraient.
• La société a donc développé un système de gestion de ces flux, à un niveau
très élevé, et fondé sur un standard du monde objet : la méthode de
conception UML.
• Le produit met en œuvre le concept de collaboration qui définit un flux entre
N applications. Un tel flux peut être complexe, le moteur se chargeant de la
gestion des transactions longues.
• Chaque collaboration manipule des objets métier définis en UML et repré-
sentant des données issues des applications cibles. Un objet métier s’ins-
tancie sur un connecteur spécifique. Ces connecteurs sont relativement
nombreux : ERP, CRM, SCM, etc. bien que l’éditeur ne communique pas pré-
cisément leur niveau de support.
• Le point intéressant est que les règles de flux sont définies au niveau des
objets métier, c’est à dire à un niveau d’abstraction indépendant des appli-
cations cibles. Ainsi, ces collaborations sont potentiellement réutilisables
dans différents environnements.
• D’un point de vue technique, le produit se présente comme l’assemblage de
diverses technologies : MQSeries et l’ORB Visibroker en couche basses, TSI
Mercator ou Neon Formatter comme moteur de transformation, et enfin
Crossworld Interchange Server comme moteur du tout.
Forces Faiblesses
• “Beauté” du concept • Difficulté d’implantation, le produit et
• La valeur ajoutée du produit se situe le type de projet qu’il génère repré-
beaucoup dans l’expertise cumulée sentent des coûts élevés
autour des progiciels (connecteurs) et • Faible intégration de l’ensemble des
des différentes collaborations déjà technologies mises en œuvre, notam-
écrites. ment en termes d’exploitation.
• Partenariat avec IBM.
Positionnement et Stratégie
• Tout d’abord, la société Crossworlds devrait s’introduire en bourse cette
année. Compte tenu du bon niveau de communication sur le produit et ses
dirigeants, cette introduction devrait s’avérer fructueuse, et donc d’une part
dégager des liquidités, et d’autre part éloigner (un peu) les menaces de
rachat.
• Au vu de la taille minimale d’un projet CrossWorlds, et donc du caractère
structurant qu’il revêt, la société devra montrer son aptitude à durer, soit à
l’aide de partenariats du type IBM, soit par sa capitalisation boursière ... ou
soit par un rachat.
• Crossworlds devrait par ailleurs poursuivre ses investissements au niveau
des couches “hautes” : nouveaux connecteurs, solutions packagées d’inté-
gration, etc.
Caractéristiques du produit
• Depuis 1991, Forté propose des solutions complètes de développement.
Fondé sur le langage Tool et un middleware spécifique, l’éditeur fut un des
premiers à proposer des solutions en architectures 3-tiers.
• Dans la logique de développement autour de ce produit, un premier ges-
tionnaire de Workflow, Forté Conductor, est mis au catalogue en 1997. Ce
produit permet de décrire graphiquement un diagramme de séquence, et de
générer du Tool intégrant les différents traitements dans un processus.
• Fusion est ensuite le packaging de Conductor, avec un moteur de règles, et
des adaptateurs vers du middleware (MQSeries, bases de données, Corba,
RMI et DCOM) et des applicatifs (SAP, Siebel, Vantive, PeopleSoft et Baan).
• Comme le montre le schéma d’architecture fourni par l’éditeur, de nouveaux
connecteurs pourront être développés à l’aide d’un kit de développement C++
ou Tool. Ils utilisent HTTP et XML comme unique mode de communication.
• XML est le fondement de l’outil. Le moteur de règles utilise des fichiers XSL
pour les transformations et le routage. Aujourd’hui l’environnement ne per-
met pas d’éditer ces règles ni de les intégrer dans le gestionnaire de work-
flow. Il faudra donc d’une part décrire à la main les règles de routage ou de
transformation dans des fichiers XSL, et d’autre part faire manuellement le
mapping entre les processus et les objets qu’ils manipulent, et les messages
XML qui transitent effectivement.
• Par défaut, toute l’interopérabilité se fonde sur du middleware synchrone
(HTTP), le moteur ne prend pas à sa charge les éventuelles indisponibilités
des applications participantes. Cette gestion d’erreur devra être prise en
compte au niveau des processus (retry sur chaque tâche)
• Le suivi d’exploitation des flux n’est pas disponible en standard. Cependant
Conductor peut externaliser sa trace dans une base de données, consul-
table ensuite par une application spécifique
Forces Faiblesses
• L’outil autorise une approche dévelop- • L’intégration de Conductor et Fusion
pement (intégration avec le reste de la reste à faire entre le gestionnaire de
gamme, Forté et SynerJ) et une formats et de règles et le workflow
approche intégration d’application, ce • Quelques connecteurs... mais un seul
de manière autonome (middlewares format (Swift), de fait, par l’absence
intégrés), et à l’aide d’une gestion de d’un réel moteur de transformation
processus. (fichiers XSL à éditer manuellement)
• Le rachat par Sun devrait pérenniser • L’interopérabilité synchrone nécessite
la gamme Fusion, seule brique EAI dis- la prise en compte de problématiques
ponible dans son nouveau catalogue... techniques dans les processus
à suivre !
• Pas d’outils d’exploitation
Positionnement et Stratégie
• L’offre Fusion ne sera réellement crédible que si elle fait partie des priorités
de Sun en termes d’investissements et de marketing. Ces informations
seront disponibles d’ici à la fin de l’année.
• Développement de l’offre (moteur de transformation, référentiel, intégration
du workflow), et intégration avec le reste de la gamme Sun : iPplanet, etc.
Caractéristiques du produit
• IBM est venu sur le marché de l’EAI à partir de son offre middleware
MQSeries, aujourd’hui leader sur le marché du MOM.
• Conscient de la nécessité de proposer une offre de plus haut niveau, l’édi-
teur crée une branche Business Integration, et étoffe sa gamme par de
nombreux rachats et alliances technologiques.
• C’est ainsi que le Message Broker MQSI provient en fait de la société NEON
qui offre maintenant des produits complémentaires autour de ce message
broker (NEON Track pour le suivi des flux, Enterprise Adapter pour les
connecteurs base de données, fichiers, etc., ainsi que des solutions verti-
cales dans la finance, la santé ou les telcos). MQSI est aujourd’hui proprié-
té d’IBM, qui en délègue à NEON le développement du moteur de règles et
de transformation.
• En Europe, IBM propose une alternative entre MQSI et l’offre Bus Applicatif
de Sopra. Idem pour la gestion des flux métiers, où le client choisira entre
le produit maison MQWorkflow (anciennement FlowMark) et le partenariat
avec l’éditeur CrossWorld... En outre, A&P de Sopra est la seule offre de
suivi de flux au catalogue IBM, en concurrence donc avec NeonTrack.
• Le Message Broker repose sur une base de données jouant le rôle de réfé-
rentiel des données et formats, facilitant ainsi la gestion des règles de trans-
formation.
• Le gestionnaire de flux utilise également cette base pour ses règles de rou-
tage, qui peuvent être basées sur le contenu. Ce moteur fonctionne en “fire
and forget”, c’est à dire par déclenchement de règles sur l’arrivée d’un mes-
sage. Il adresse donc de manière très performante une logique 1 vers N
mais ne permet pas de gérer simplement des flux N vers M.
• Les connecteurs sont tous issus des bibliothèques Neon, l’offre est aujour-
d’hui centrée sur quelques progiciels (SAP, PeopleSoft, Siebel, I2, etc.), la
finance (Swift, Oasys et FIX) et l’EDI.
• A noter le support de flux de type terminaux interactifs (3270, 5250, VT,
etc.) par le produit Neon Adapter for Terminals.
Forces Faiblesses
• Base installée MQSeries comme levier • Pas de fusion simple multi-source
de l’offre • Produits très orientés MQSeries en
• Référentiel des formats et règles standard, faible ouverture vers
• Gamme complète, par produits compa- d’autres systèmes
gnons chez des tiers • Instabilité potentielle des partenariats
• Pérennité à moyen terme.
Positionnement et Stratégie
• Offre complète construite à partir de briques d’origines diverses (IBM, Neon,
Crossworld, Candle pour l’administration MQSeries, Sopra, etc.)
• Axe stratégique chez IBM, garant d’une pérennité de la gamme. En
revanche, les nombreux accords qui fondent aujourd’hui l’offre sont suscep-
tibles d’évoluer, impactant de fait la portabilité des produits sur le long
terme.
Caractéristiques du produit
• Biztalk Server est l’héritier de Commerce Server, la plate-forme de commer-
ce électronique de Microsoft. La future offre s’architecture autour du moteur
qui s’appuie sur un référentiel et des connecteurs.
• Les connecteurs permettent de recevoir et d’envoyer des messages :
connecteurs techniques SMTP, HTTP, MSMQ, ADO (SGBDR), etc. A noter
également un connecteur pour SAP.
• Le référentiel contient :
■ la description de la structure de l’ensemble des messages (les sché-
mas XML) au format XML.
■ les règles de transformation syntaxiques et sémantiques des schémas
entre eux (stockés au format XSL : eXentsible Stylesheet Language).
■ Les règles de routage et de workflow à appliquer lorsqu’un message
arrive : c’est le concept de “pipeline”, un ensemble de composants
ActiveX qui s’enchaînent de manière séquentielle pour mener à bien
l’ensemble des opérations à effectuer sur un message. Ces compo-
sants pipeline pourront être développés à l’aide d’add-in (wizard) dans
les outils de développement de la gamme Visual Studio.
• L’architecture interne de Biztalk Server repose entièrement sur la plate-
forme Windows2000 et sur DNA : le serveur d’applications MTS, le serveur
Web IIS et le MOM MSMQ.
• Biztalk Server permet de gérer le routage en fonction du contenu du messa-
ge, ainsi que la prioritisation des messages. Ce dernier point permet d’avoir un
fonctionnement quasi-synchrone pour les messages les plus importants.
• En terme de sécurité, Biztalk Server supporte l’encryption de tous les messages,
le support de SSL et les certificats à clé publique intégrés à Windows 2000. La
sécurité applicative repose sur la notion de rôle déjà existante dans MTS.
• En terme d’outils, BizTalk fournira un éditeur graphique de schémas XML
(Biztalk Editor), ainsi qu’un outil de mapping : Biztalk Mapper qui permettra
d’éditer les règles de transformation des schémas XML (au format XSL).
• Les formats supportés en standard seront XML bien sûr (XML Data et DTD),
l’EDI (X.12 et EDIFACT), et SAP Idoc.
• L’administration du serveur se fera par l’intermédiaire de la MMC (Microsoft
Management Console).
• Biztalk Server fournit également des fonctions d’archivage et d’analyse des flux
de messages échangés au travers de l’outil DTA (Document Tracking and
Activity).
Forces Faiblesses
• Basé entièrement sur XML et sur les pro- • L’offre n’existe pas encore et a beau-
tocoles Internet (SMTP, HTTP, SSL, etc.) coup de retard sur la concurrence, on
• Intégration à la plate-forme Windows ne connaît pas encore la réelle capa-
2000 : sécurité, administration, DNA cité du moteur de transformation ni de
la gestion de pipeline
• Pérennité de l’offre
• Pas de réelle gestion de processus
• Repose sur des outils et langages de
prévue
développement très répandus (Script,
Visual Studio) • Peu de connecteurs prévus
Positionnement et Stratégie
• BizTalk Server est la nouvelle offre Microsoft en terme de Message Broker,
avec un positionnement stratégique double :
■1) Le commerce Electronique B to B : offrir une solution d’interopérabi-
lité entre entreprises via XML et Internet entre système d’informations
hétérogènes
■2) Interopérabilité inter-applications au sein d’une même entreprise :
intégrer les différentes sources de données, applications et progiciels
d’une entreprise via XML.
• Pour soutenir ce positionnement (et surtout occuper le terrain !), Microsoft a
lancé l’initiative BizTalk (www.biztalk.org) qui vise à fusionner l’ensemble des
initiatives métiers de Microsoft (DNAfs pour la banque, ObjX pour la santé,
ainsi que la communication inter-ERP) en vue de définir un ensemble de sché-
mas XML standardisés et librement accessibles sur Internet. Les définitions de
ces schémas s’appuieront en partie sur une simplification de la norme EDI
existante et impliquent un nombre important de partenaires (SAP, Baan ou
PeopleSoft par exemple) et de clients. Dans ce schéma, les ERP fourniront les
connecteurs techniques (AIC : Application Integration Connector), les schémas
XML et les règles de mapping (XSL) avec leurs types de données.
• Si Microsoft réussi son pari, il aura réussi à modéliser l’équivalent des objets
métier ERP présents dans CrossWorlds.
• A terme, Biztalk Server devrait servir également de fondation pour MSN, qui
est en train de devenir le portail B2B et B2C de Microsoft et de rassembler
acheteurs et vendeurs échangeant leurs ordres et commandes. Ce posi-
tionnement stratégique s’apparente à l’offre MySAP ...
Caractéristiques du produit
• NEON MQSeries Integrator est l’un des produits principaux de NEON. C’est
un Message Broker doté d’un référentiel SGBDR et fonctionnant sur un
MOM, MQSeries. NEON propose également son propre transport, NEON
EMQ (Extended Messaging and Queuing), et distribue alors son offre sous
l’appellation NEONet.
• Le module de formatage emploie une technologie brevetée lui permettant
de garantir des temps de réponse stables, quelque soit le nombre de règles,
de façon similaire à la gestion d’un index dans une base de données.
• Le moteur de règles fonctionne en mode “fire and forget” sur des flux de
messages de type 1 vers n. Pour la collection de message (n vers 1 et n
vers m), NEONadapter for Protocols gère la collecte de messages en amont
du broker.
• NEON a réussi à soutenir une croissance externe relativement élevée, lui
permettant d’acquérir des technologies tierces (CAI, VIE Systems, Convoy,
MicroScript, etc.) qu’elle intègre à son catalogue, ainsi que des sociétés
d’ingénierie (SLI).
• L’offre, initialement issue du monde la finance (Swift, FIX, NEON Trading
System, Rapport, etc.), a donc pu se consolider autour de nombreux formats :
EDI, XML, SAP, PeopleSoft, Siebel, i2, etc. et de connecteurs de protocoles :
NEON Enterprise Adapter pour les modes fichiers et base de données,
NEONadapter for Protocols pour les passerelles de transport, NEONadapter for
Terminal pour l’intégration “non-intrusive” en mode revamping, etc.
• L’exploitation est confiée sur le plan de plan du suivi des messages à
NEONtrack qui supporte aussi bien MQSeries que NEON EMQ.
• Pour offrir des fonctionnalités évoluées de gestion de flux et une meilleure
intégration de l’offre, NEON a annoncé la sortie de E-Biz Integrator, qui
consolidera dans un même produit Enterprise Process Executive (le moteur
de gestion de processus métier), MQSI, NEON Web (ex produit de CAI,
connexion aux serveurs d’application et serveurs Web) et certains formats
(XML, EDI).
• La prochaine étape consistera à unifier l’ensemble de cette gamme dans un
produit unique OpenBroker. Cette version permettra notamment d’intégrer
nativement d’autres transports que MQSeries et EMQ (MSMQ et autres
middlewares synchrones ou asynchrones).
Forces Faiblesses
• Offre complète, grâce aux différents • OpenBroker permettra une meilleure
produits de la gamme intégration des flux autres que mes-
• Le broker est bâti sur un référentiel sages MQSeries et EMQ
• Dynamique de l’éditeur, malgré les • Jeunesse du produit de gestion de
récents incidents du NASDAQ processus (EPE), permettant de créer
des flux complexes.
• Références nombreuses dans la finan-
ce, dans une moindre mesure chez les
telcos et dans l’industrie/distribution
Positionnement et Stratégie
• Neon va continuer à revendre son offre soit directement, soit au travers
d’accords OEM, comme ceux déjà passés avec IBM ou Crossworlds.
• Par ailleurs, l’offre va continuer à évoluer, d’une part sur le plan architectu-
ral (OpenBroker, NEON Common Standard Architecture qui intègre NEON
Impact et NEONet), et d’autre part avec l’arrivée de solutions adaptées à
des environnements métier (finance bien sûr, mais aussi telco, industrie,
etc.)
Caractéristiques du produit
• e*Gate est un moteur d’EAI historiquement issu du milieu hospitalier. Doté
de très nombreuses références dans ce domaine, l’éditeur s’ouvre aujour-
d’hui plus largement au monde de l’industrie et de la finance.
• L’offre STC s’articule donc autour du moteur de transformation et de routa-
ge, incluant son propre transport sécurisé ainsi que des connecteurs de
base.
• Le moteur de transformation permet de traiter la plupart des cas standards,
pour des transformations avancées, un langage interne (le monk) est utili-
sé, donc sans nécessité de bibliothèques externes en C.
• Le moteur se connecte aux différentes cibles du SI au travers de e*Ways,
celles-ci sont de différents types : DART pour les bases de données,
MQSeries, SAP, PeopleSoft, Siebel, Clarify, Swift, Kondor+, HL7, HTTP,
ScreenScripter, X.12, EDIFACT, XML, etc.
• Un des aspects particuliers du produit concerne le nombre de ces passe-
relles : plus de 500 e*Ways ont été mises en œuvre, sur tous types de
plates-formes et applicatifs.
• Cela ne signifie pas pour autant que STC dispose du plus large catalogue de
connecteurs, mais dénote plutôt la simplicité de mise en œuvre de celles-
ci, une e*Way simple (COM client) pouvant être développée très simplement
dans tous types d’environnement (TCP/IP, SNA, IPX, DecNet,etc.)
• Le produit Universal Index permet de gérer des tables de cross-références
de manière intégrée au moteur.
• L’outil de suivi inclus dans e*Gate couplé au produit Alert Notifier, qui per-
met de diriger des évènements d’exploitation vers une base de données,
permettent un suivi d’exploitation global, jusqu’aux e*Ways
• Enfin, STC a réalisé pour un de ses clients une solution complète dans le
monde dentaire, DataDental : suivi de dossier, paiements, etc.
• La nouvelle mouture du produit, e*Gate 4.0, est prévue pour le 1er
novembre 1999. Elle inclut notamment un moteur de gestion de flux, un
référentiel centralisé autorisant une architecture distribuée s’appuyant sur
un transport en mode publish/subscribe, et une intégration plus fine de
MQSeries.
Forces Faiblesses
• Offre pragmatique et autonome • Cohabitation de plusieurs technolo -
• Nombreuses références, y compris sur gies, Java, Windows et X
de fortes volumétries
• Facilité d’intégration de connecteurs
spécifiques
• EGate 4 augmente notoirement les
capacités de l’outil pour les architec-
tures complexes.
Positionnement et Stratégie
• L’offre eGate s’ouvre plus simplement à de nouveaux transports (MQSeries
notamment), mais demeurera une offre autonome par essence.
• La société STC devrait s’introduire en bourse cette année, ce qui lui procu-
rera une marge de manœuvre intéressante en termes d’investissements. En
effet, le produit étant relativement complet aujourd’hui, cette somme pour-
ra financer un meilleur marketing.
• L’axe de développement de STC est aujourd’hui de croître en dehors du
milieu hospitalier : finance, industrie et opérateurs télécom.
Caractéristiques du produit
• SOPRA est le premier éditeur Français avec un CA de 700 MF (1.800 MF
au total pour la société en ajoutant le CA de la division Service) qui a orga-
nisé son activité édition en 2 branches :
■une branche métier qui offre des progiciels verticaux pour différents
secteurs d’activité, essentiellement Banque (progiciel de gestion des
crédits), RH (logiciel de Paie) et Immobilier
■une direction Progiciels Outils en charge des progiciels horizontaux qui
s’est vu accrédité de la 3ième place mondiale dans le (petit) monde de
l’EAI par la dernière étude du GIGA Group, et la première en Europe
selon le Gartner.
• SOPRA est un acteur historique de la gestion des flux en entreprise. Les
rachats des sociétés Credintrans (CFT) et Pelican (InterPel) lui fournissent
aujourd’hui environ 80% des parts de marché du transfert de fichier en
France, cette offre est regoupée sous le terme eXtended File Broker : XFB.
• Pour le formatage, le produit phare Règles du Jeu est disponible depuis plus
de 10 ans, et en production dans de très nombreux environnements,
notamment en gestion comptable (un module est dédié à cette fonction)
• Ce produit est par ailleurs au catalogue d’IBM Europe car il peut exploiter
dans sa dernière version le middleware MQSeries. Il est donc en concurren-
ce directe avec le produit MQSI (au catalogue IBM... US). SOPRA a arrêté
le développement de son MOM propriétaire, Interset, dont il n’assure plus
que la maintenance.
• Enfin, SOPRA propose depuis 2 ans une nouvelle brique à son offre d’urba-
nisation des SI : A&P. Ce produit offre des fonctions de routage simple, de
cartographie des flux, et de suivi métier (module A&P Tracker).
■La fonction de routage est implémentée par des règles qui examinent
le type du message comme élément de décision. Les flux sont marqués
par les agents A&P, ce n’est donc pas un routage basé sur le contenu
du message. Pour cela, il faudra rediriger le flux vers RDJ.
■Ce suivi métier impose alors l’utilisation des A&P Agents et leur API sur
les plates-formes cibles. L’A&P Agent pouvant utiliser indifféremment
un transport Transfert de fichiers, un MOM ou une messagerie X.400.
• Ces solutions sont indépendantes les unes des autres mais peuvent évidem-
ment se combiner pour couvrir l’ensemble des besoins d’échange de l’entre-
prise : transfert de fichier, outils de translation (formatage) ou Message Broker.
L’offre globale est packagée sous l’appellation Bus Applicatif.
• Les principales références d’A&P sont PSA, Natexis, UNEDIC, ou EDF. Elles
sont nettement plus nombreuses pour RDJ (plus de 500 en Europe) et XFB
(4000 dans 80 pays).
Forces Faiblesses
• Précurseur sur le thème de • Peu de dynamique sur le produit : pas
l’Urbanisation, avec des solutions de formats standards (ERP, CRM, XML,
proches du besoin utilisateur : suivi etc.) hormis l’EDI,
métier et gestion comptable notamment • Produit ancien, éloigné des nouvelles
• Base RDJ et transferts de fichiers technologies : HTTP, XML, MSMQ, etc.
importante en Europe, • Pas encore de réelle intégration entre
• Partenariat IBM, mais à l’échelle A&P et Règle du Jeux
Européenne uniquement.
Positionnement et Stratégie
• Sopra communique peu sur les évolutions de son produit, qui sont essen-
tiellement liées aux besoins de ses clients. La société doit néanmoins
annoncer au plan Europe ses nouvelles offres (dont XML, formats ERP et
package A&P + RDJ) début novembre 1999 (IT-Expo du Gartner Group).
• Les accords avec IBM peuvent aider à la pénétration de la solution, dans un
périmètre Français compte tenu du marketing actuel.
Caractéristiques du produit
• Template Software est une société spécialisée dans la réalisation et la com-
mercialisation de composants logiciels réutilisables basés sur une technolo-
gie “orientée objet”.
• EIT (Enterprise Integration Template) représente l’offre EAI de Template et
peut s’utiliser de façon autonome pour satisfaire à des besoins de routage
simple des données entre applications et progiciels, ou s’utiliser de maniè-
re intégrée avec les autres produits de la gamme (Workflow Template,
Business Process Template ou Process Monitor Component).
• Bâti sur SNAP, la plate-forme de développement commune à l’ensemble des
outils, EIT permet une vue intégrée du SI de l’entreprise par l’utilisation des
3 composants suivants :
■ Le modèle objet opérationnel : ce modèle décrit les objets métiers et
les flux d’information décrivant l’organisation d’une entreprise, EIT gère
un référentiel de ces données
■ Les services de connexion aux ressources : fournissent à EIT le moyen
de se connecter aux sources de données et aux applications pour ali-
menter le Modèle Objet Opérationnel et gérer la persistance des infor-
mations
■ Les services de distributions : ces services prennent en charge la pro-
pagation des informations et des événements dans l’entreprise ainsi
que de la délivrance des réponses aux requêtes des applications
clientes. Cette couche de transport s’apparente à un ORB permettant
la communication entre composants, au travers du protocole proprié-
taire SNAP ou de COM ou CORBA.
• Toute nouvelle application peut ensuite facilement se connecter au serveur
EIT et bénéficier des objets déjà modélisés pour échanger de l’information
avec le reste du SI.
• Template dispose de nombreux connecteurs, techniques : IMS/CICS,
MQSeries, Tuxedo, SGBDR, XML, etc. et applicatifs : SAP, PeopleSoft, Siebel,
Vantive, Kenan, etc.
Forces Faiblesses
• Savoir faire technique éprouvé • Maîtrise nécessaire de la fondation
• Modèle unifié des objets de l’entreprise SNAP et des concepts objets
• Offre verticale dans le domaine des • Positionnement floue de EIT entre une
télécommunications. plate-forme de développement (voire
une serveur d’application) et un pro-
duit d’intégration.
Positionnement et Stratégie
• Template offre avec SNAP, EIT et les autres modules (WFT, BPT...) un AGL
complet, voire complexe, couvrant des besoins du monde EAI (routage,
connexion directe avec les progiciels...).
• EIT trouve naturellement sa place dans les projets d’intégration pour les-
quels l’effort de modélisation et de développement en environnement objet
représente une part importante.
• De fournisseur de solution de développement, Template tente de se reposi-
tionner, ainsi que quelques-uns de ses concurrents (Forté, Compuware...),
comme un fournisseur de solution globale d’interopérabilité.
Caractéristiques du produit
• Depuis 1980 et l’informatisation de Wall Street avec la technologie de publi-
sh/subscribe TIB/Rendez-vous, Tibco a élargi sa gamme pour couvrir les dif-
férentes briques de l’EAI
• La gamme TIB/Adapters fournit des passerelles techniques (MQSeries,
MSMQ, SGBDR, Web, etc.) et vers des progiciels : SAP, PeopleSoft, Vantive,
Siebel et Clarify notamment.
• Le gestionnaire de flux et de transformation, TIB/Message Broker, est une
brique récente sans référence à l’heure actuelle.
• L’administration et l’exploitation d’un réseau Tibco et des adaptateurs est
assurée par l’outil TIB/Hawk.
• A l’image de NEON, mais ici avec le soutien direct de la maison mère
Reuters, Tibco propose des solutions clés en main pour la finance, et
notamment les salles de marché au travers de la gamme Financial
Enterprise Application Integration
• Tibco fournit également des solutions de haut niveau pour la gestion de por-
tails (TIB/Portails, utilisé Yahoo!, Altavista, Netcenter et bientôt mySAP.com
par exemple) et réseau d’information à valeur ajoutée (Tibco.net)
Forces Faiblesses
• Editeur spécialisé sur le secteur depuis • Pas de Message Broker réel dans
1980, l’offre aujourd’hui
• Son assise garantit une dynamique
autour de son offre : passerelles et
offres packagées notamment,
• Fourniture de solutions clé en main :
finance et eBusines
Positionnement et Stratégie
• Fourniture de solutions totalement intégrées dans la finance, avec l’appui de
la maison mère Reuters,
• Fourniture de solutions clés en main pour les grands sites portails,
• Tibco devra également se doter d’un réel Message Broker ou afficher un par-
tenariat clair avec un des éditeurs leader sur ce créneau.
Caractéristiques du produit
• Mercator est le produit phare de la société TSI. Constitué de 4 éditeurs gra-
phiques différents qui permettent respectivement
■ de modéliser les formats (Type Tree Editor) ou de les importer (Idoc,
XML),
■ de générer automatiquement des formats à partir de tables ou de pro-
cédures stockées (Database Editor),
■ de mettre en correspondance ces flux, après transformation éventuel-
le, entre différentes sources d’entrée et de sortie (Map Editor),
■ de créer de véritables flux d’information métiers (System Editor), c’est
à dire d’enchaîner des maps.
• A ces modules GUI, viennent se rajouter le moteur du Message Broker à pro-
prement parlé (Command Engine), associé au Launcher Module qui per-
mettra de déclencher le moteur suite à l’apparition d’un événement (dépôt
d’un message, de plusieurs fichiers, timer, etc.). Cette approche est inté-
ressante car elle permet nativement de gérer des flux complexes en entrée.
• L’offre ne dispose pas de transport spécifique et peut donc s’appuyer indif-
féremment sur MQseries, MSMQ, Tuxedo ou /Q, Oracle AQ ou Tibco
RendezVous. Des passerelles existent également vers les principaux SGBDR
• Des connecteurs applicatifs existent dans trois domaines :
■les ERP (Mercator for R/3, for PeopleSoft)
■la finance (Mercator FS), avec les formats FIX, SWIFT/ISITC, ACH, BAI,
et ETC. Mercator propose également une solution packagée à l’aide de
progiciels de gestion de transactions et de paiements.
■le commerce électronique (Mercator for EC) avec le support de l’EDI
(X.12 et EDIFACT), HL7 et XML
• D’un point de vue exploitation, TSI propose l’outil Monitoring Tool qui offre
un suivi temps réel de l’exécution des maps, ainsi que l’affichage de diverses
statistiques de base (nombre de maps déclenchées depuis le lancement du
moteur, le nombre de maps en erreur, en attente de déclenchement, etc.)
Forces Faiblesses
• Prise en main aisée • Pas de référentiel, nécessité de gérer
• Ouverture : nombreuses passerelles manuellement l’ensemble des fichiers
techniques vers les middlewares du décrivant les méta-données,
marché • SAP est à la fois une force et une fai-
• Qualité du moteur de routage (gestion blesse, il phagocyte l’image du pro-
du N vers M) et de transformation duit.
• Gestion de processus nativement dans
le produit (System Editor)
• Nombreuses références en intégration
SAP
Positionnement et Stratégie
• Mercator se retrouve assez souvent intégré, comme brique de transformation,
dans des offres plus globale d’autres éditeurs (E-link de BEA ou Crossworlds
par exemple), ce qui prouve la pertinence de son moteur de transformation.
• La version 2.0 du produit, disponible en fin d’année, se focalisera sur l’amé-
lioration de l’administration (outils de déploiement pour palier à l’absence
de référentiel), diverses optimisations de performance (gros fichiers, gestion
de connexions SGBDR, etc.), le support de transactions imbriquées, etc. Pas
de refonte du marketing produit, avec toujours les éditions Mercator for SAP
ou PeopleSoft, for FS et for EC.
• Concernant l’édition Mercator for EC, l’offre va s’agrémenter du récent
rachat de la société Novera, qui édite un outil d’intégration d’applications
Web multi-canaux.
• La 2.1 devrait amener l’année prochaine les adaptateurs HTTP et LDAP, un
meilleur support de XML, des interfaces vers les progiciels d’administration
du marché, et le support de nouvelles plates-formes et SGBDR.
• Le récent rachat de la société BRAID devrait faciliter l’axe finance et concur-
rencer Tibco ou NEON sur ce créneau (TSI utilisera des applicatifs externes
de Braid comme Nimbus ou Gemini)
• La force du produit autour de l’intégration SAP devrait également tirer le pro-
duit vers un support plus poussé des ERP concurrents.
Caractéristiques du produit
• Le produit AMTrix est issu de la société Suédoise FrontecAB qui a capitalisé
sur des développements spécifiques depuis 1990. Le produit n’est vendu
comme tel que depuis 4 ans.
• La société Frontec AB a séparé son activité d’ingénierie de celle d’éditeur,
en renommant cette dernière Viewlocity, avec l’arrivée de capitaux externes
(groupe Battery)
• AMTrix est un message broker classique, issu des technologies de l’EDI :
X.12 et EDIFACT, X.400 pour le transport
• Le Message Broker stocke ses informations dans un référentiel, par défaut
sous Informix
• Le moteur de transformation utilise le référentiel pour stocker ses formats
(Message Builder), un langage de programmation spécifique peut être utili-
sé pour les cas les plus complexes
• En plus du transport propriétaire interne, des passerelles (Communication
Server : CSE) existent vers les transferts de fichiers, MQSeries et les bases
de données (DataMapper)
• Outre l’EDI, il supporte aujourd’hui des connecteurs vers les ERP SAP et
JDEdwards, se positionnant de fait sur les créneaux de la gestion logistique
(AMTrix est également au cœur du SCM Manugistics)
Forces Faiblesses
• Capacité d’intégration de flux EDI dans • Pas de gestion de processus com-
des ERP, fournit une solution viable de plexes
SCM (cf. signature récente de • Produit relativement “ancien” et très
Carrefour) marqué EDI
• Référentiel SGBDR • Seulement deux connecteurs applica -
• Grosses références dans l’industrie et la tifs aujourd’hui (SAP et JDE), bien que
distribution : Volvo, Mars, DHL, d’autres soient planifiés (autres ERP
Castorama et SCM).
Positionnement et Stratégie
• Focalisation sur le marché de la chaîne logistique : industrie, distribution
• Accord OEM avec des éditeurs, déjà au cœur de Manugistics
Caractéristiques du produit
• L’offre BusinessWare se compose de plusieurs modules. La définition des
processus est réalisée à l’aide du Process Modeler Client. Le Message
Broker (Automator) exécute ces processus, qui peuvent être suivis en exploi-
tation par l’outil Analyzer.
• Vitria offre une couche de transport spécifique (Communicator), fondée sur
une architecture CORBA (IIOP ou IP multicast), mais peut aussi se connec-
ter à d’autres infrastructures à l’aide de Connectors.
• Ces connecteurs techniques existent pour MQSeries, MSMQ, Oracle AQ, les
SGBDR, les fichiers, les messageries, etc.
• Des connecteurs applicatifs, nombreux, sont disponibles pour SAP,
Peoplesoft, Vantive, Clarify, Kenan, Remedy, et XML, EDI. Nous ne connais-
sons pas le niveau de support réel qu’ils offrent.
• Le connecteur est responsable de la transformation de ce qu’il émet comme
événement métier dans le serveur, ceux-ci sont au format CORBA IDL. A ce
titre, le connecteur SAP se chargera de la transformation d’IDoc en IDL par
exemple. Le cas échéant, Vitria peut s’ouvrir à des moteurs de transforma-
tions externes pour les cas complexes.
• Les processus se définissent graphiquement dans le BusinessWare Modeler,
ces processus empruntent une syntaxe compatible UML. Un point intéres-
sant est la capacité de passer directement du modèle aux tests dans
Automator.
• Toutes les interfaces graphiques de développement et d’administration sont
des applications Java
Forces Faiblesses
• Gestion de processus intégrée dès le • Petite société, une trentaine de réfé-
départ rences
• Catalogue de connecteurs important • Pas de moteur de transformation
• Offre très “moderne” : UML, IDL/IIOP,
Java, SSL,... trop ?
Positionnement et Stratégie
• L’introduction en bourse va permettre à la société de développer ses pro-
duits et sa stratégie.
• Un des axes annoncés est la verticalisation de l’offre, en premier lieu sur le
marché des opérateurs télécom (connecteurs aux applicatifs spécifiques,
processus prédéfinis, etc.)
• Vitria souhaite également ouvrir son moteur de workflow applicatif à des
acteurs humains, proposant ainsi une offre unique sur le marché, synthèse
des offres EAI les plus à la pointe et des produits de workflow/GED clas-
siques (FileNet,etc.)