Panorama 2003 des
outils d'EAI (3): Sunopsis au crible
Par JDNet
Solutions (Benchmark Group)
URL : http://www.journaldunet.com/solutions/0303/030312_sunopsis.shtml
Lancer l'impression
Mercredi 12 mars 2003
Dossier réalisé en partenariat avec
Dreamsoft
Origine et évolution de
la solution
Fondé en janvier 1998, Sunopsis
se positionne à l'origine sur le marché de l'ETL (Extract,
Transformation and Loading) en jouant notamment la carte des standards
Java. En 2001, à l'heure où les plates-formes EAI s'imposent
dans le paysage de l'intégration logicielle, l'éditeur affiche
à son tour des ambitions dans ce domaine, jouant sur un angle d'attaque
du marché cohérent avec sa technologie. A savoir celui de
"l'intégration par les données", par opposition
aux pure players de l'EAI, qui se veulent plus centrés sur l'intégration
par les processus.
La plate-forme de Sunopsis appartient donc
à ces solutions que l'on classe habituellement dans la catégorie
(plus ou moins bien nommée) des "EAI tactiques". Au-delà
des débats théoriques (voire sémantique), un fait
s'impose : la solution de Sunopsis répond à des besoins
d'intégration d'applications - même si cette intégration
est très orientée données comme nous allons le voir.
A ce titre, elle trouve sa place dans ce panorama 2003 de l'EAI. D'autant
qu'il serait dommage de ne pas s'arrêter sur l'un des rares acteurs
français de ce secteur. Français mais en voie d'expansion
à l'international puisque Sunopsis, adossé à un porte-feuille
d'environ 200 clients, a ouvert deux filiales, à Boston et à
Singapour, l'année dernière.
Principes et structure
de l'offre
Parce qu'elle est centrée
sur l'intégration des données, la solution de Sunopsis oblige
à abandonner les schémas habituellement utilisés
pour analyser et structurer une plate-forme d'EAI traditionnelle. Il n'est
en effet point question ici de serveur d'intégration ou de broker.
La logique est tout autre : au lieu d'exploiter un moteur d'intégration
au sein duquel s'opèrent les opérations de transformation
et de routage, Sunopsis v3 (la version que nous avons évaluée)
s'appuie sur les capacités de traitement des applications source
et cible.
Le concept clef à saisir ici est celui
d'espace de travail. Quand un traitement est élaboré à
travers Sunopsis, le développeur précise l'espace de travail
dans lequel il va s'exécuter. Cet espace peut être réservé
dans l'espace de l'application source, de l'application cible ou éventuellement
dans le "Memory Engine" de la solution (nous y reviendrons).
Concrètement, des tables temporaires sont créées
dans les applications concernées (bases de données, progiciels
).
Autrement dit, Sunopsis distribue le traitement des opérations
auprès des applications concernées et s'appuie à
cette fin sur leurs capacités natives (SQL, PL/SQL, Java, etc.).
In fine donc, tout se termine avec Sunopsis par des traitements
SQL. Conséquence directe (à bien sous-peser) : les performances
des intégrations élaborées à travers Sunopsis
dépendent directement des performances des applications sources
et cibles et non de celles d'un moteur d'intégration qui s'interposerait
entre ces éléments.
Côté transport, si, dans l'esprit
Sunopsis, les applications initient et prennent en charge elles-mêmes
les échanges de données, elles peuvent aussi publier leurs
messages dans un MOM - l'éditeur fournira d'ailleurs prochainement
son propre bus (Sunopsis MQ). Pour la connectique, précisons que
la solution s'appuie sur les standards Java : JDBC en premier lieu, mais
aussi JMS et JCA.
Pour comprendre la structure de la plate-forme,
distinguons les principaux outils proposés et les composants mis
en uvre.
Les
outils
|
Sunopsis
Topology Manager
|
Cet outil est utilisé
pour identifier l'architecture physique, puis logique du système
d'information. Bref, il s'agit ici d'identifier et de référencer
l'ensemble des ressources. C'est aussi à l'aide du Topology
Manager que sont définis des contextes de développement,
de recette, de production, etc. Il est ensuite très simple
d'indiquer dans quel contexte l'on souhaite travailler.
|
Sunopsis
Designer
|
Comme
son nom l'indique, le designer est l'outil de développement
principal. Ici, l'essentiel s'orchestre via des glisser-déposer.
Données sources et données cibles sont glissées
dans une fenêtre afin d'être mises ensuite en correspondance.
Des déclencheurs sont paramétrés (modification
d'une données, arrivée d'un email, publication d'un
fichier dans un répertoire, arrivée d'un message dans
une queue
), des contrôles sont définis et les
opérations de mapping (transformation) sont précisées.
Pour chaque traitement, un espace de travail est nommé.
|
Sunopsis
Security
|
Cet
outil permet d'éditer les habilitations des différents
utilisateurs de la plate-forme.
|
Sunopsis
Designer
|
Comme
son nom l'indique, le designer est l'outil de développement
principal. Ici, l'essentiel s'orchestre via des glisser-déposer.
Données sources et données cibles sont glissées
dans une fenêtre afin d'être mises ensuite en correspondance.
Des déclencheurs sont paramétrés (modification
d'une données, arrivée d'un email, publication d'un
fichier dans un répertoire, arrivée d'un message dans
une queue
), des contrôles sont définis et les
opérations de mapping (transformation) sont précisées.
Pour chaque traitement, un espace de travail est nommé.
|
Sunopsis
Operator |
Outil
destiné à l'exploitant, ce module permet à l'opérateur
de planifier, surveiller, et de diagnostiquer les problèmes
d'exécution. |
Les
principaux composants mis en uvre
|
Les référentiels
|
Sunopsis distingue
le référentiel maître (forcément unique)
et les référentiels de travail, tous hébergés
sur un SGBDR. A titre d'exemple, un agent (voir ci-après)
peut embarquer localement un référentiel dit de travail
afin de limiter les risques d'une rupture de communication avec
le référentiel maître.
|
Les
modules de connaissance
|
Au nombre d'une quarantaine,
ils s'apparentent à des méta-modèles de données.
Ces modèlent décrivent la logique qui permettra de
générer ensuite des scripts dans des langages propres
à chaque application. Les principaux SGBDR et ERP du marché
sont aujourd'hui couverts par ces modules de connaissance.
|
Les agents
|
Dans la philosophie
de Sunopsis, les agents doivent être vus comme des ordonnanceurs.
En effet, ces agents ne véhiculent pas les données
(même si cette possibilité existe) : ils exécutent
des scénarios qui créent (et suppriment) les espaces
de travail dans les applications concernées au fur et à
mesure des traitements demandés. Et ce sont les applications
qui s'échangent les données, quelque sorte en direct.
A noter qu'un agent peut faire appel aux scénarios associés
à un autre agent.
|
Le
Memory Engine
|
La plate-forme dispose de son
propre moteur de transformation Java qui peut donc être exploité
comme un espace de travail intermédiaire entre les données
source et cible, même si ce n'est pas vraiment l'esprit de
la solution. Ce Memory Engine s'avère notamment utile quand
les applications sources et cibles ne possèdent pas de capacités
de transformation. L'éditeur indique que l'emploi du Memory
Engine est préférable quand le volume de chaque échange
à traiter est faible car tout s'opère en mémoire.
En revanche, pour de grandes volumétries (plus de 10 000
lignes par minute), le recours aux environnement sources et/ou cibles
apporte plus de performances.
|
Le journal
|
Toutes les opérations
(création d'un espace de travail, transformation, publication
d'un message, etc.) sont historisées dans un journal, stocké
dans le référentiel auquel l'agent est connecté
en permanence.
|
L'avis
de l'expert
(Mariano Boni, directeur technique de Dreamsoft)
Reconnaissons-le, avec l'outil de Sunopsis la frontière entre ETL et EAI
devient floue. Certes, les puristes déduiront de l'absence d'un moteur
d'intégration que Sunopsis ne peut figurer aux côtés des offres EAI traditionnelles.
Cependant, dans les faits, la puissance et l'ergonomie de cet outil d'intégration
par les données répond bel et bien aux enjeux fonctionnels que l'on associe
à la problématique EAI. Les règles d'intégration sont centralisées dans
un référentiel et la plate-forme est suffisamment riche pour couvrir la
plupart des scénarios d'intégration. Mais "la plupart" seulement : en
l'absence de moteur d'intégration, le champ des possibles est forcément
limité par les fonctions même des applications
impliquées.
Reste la question des processus. Là où les
solutions d'EAI habituelles permettent d'opter pour une approche Bottom-Up
(par les flux techniques) ou Top-Down (par les processus), Sunopsis impose
la première. L'éditeur, dont nous avons apprécié le discours clair et
direct, revendique d'ailleurs cette approche. Ces représentants estiment
en substance que l'engouement des éditeurs d'EAI pour le BPM (Business
Process Management) est en décalage avec la réalité du terrain. Un point
de vue que nous nuancerons : certes l'effervescence autour du BPM est
probablement décalée au regard de la maturité de l'urbanisation des systèmes
d'information. Toutefois, Sunopsis ne devrait pas perdre de vue que tendre
vers le processus représente bien le sens de l'histoire
[Rédaction, JDNet]
Pour tout problème de consultation, écrivez au Webmaster
Copyrights
et reproductions . Données
personnelles
Copyright 2006 Benchmark Group - 69-71 avenue Pierre Grenier
92517 Boulogne Billancourt Cedex, FRANCE
|
|