Dossier réalisé en partenariat avec Dreamsoft
Origine et évolution de la solution
Sonic Business Integration Suite appartient
à cette nouvelle catégorie de solutions dites d'ESB (pour Enterprise Service Bus).
Un type de solution consacré par les analystes qui, à l'instar du Gartner, estiment
que les ESB vont se répandre dans la majorité des entreprises d'ici à 2005. Comment
caractériser ce "bus de service d'entreprise" ? Une définition minimale pourrait
tenir dans ces quelques mots : un ESB combine une technologie de transport asynchrone
éprouvée et des services techniques à valeur ajoutée (de routage, de transformation
)
dérivés des standards de l'industrie.
Cette définition à l'appui, il est aisé de comprendre pourquoi un acteur tel que
Sonic Sofware a presque naturellement inauguré la voie de l'ESB. "Presque", car
il aura aussi fallu aussi en passer par un rachat, en l'occurrence celui de l'éditeur
de eXcelon, pour permettre à l'éditeur de monter en puissance sur les standards
XML. C'est en 2002 que SonicXQ devient Sonic ESB au sein de la plate-forme d'intégration
Sonic Business Integration Suite. Un virage pris au bon moment puisque l'arrivée
de l'ESB coïncide avec l'engouement pour les architectures orientées services.
A tel point qu'aujourd'hui bon nombre d'acteurs de l'EAI tentent de monter dans
le train de l'ESB. Partie avec une avance certaine, l'ESB de Sonic Software compte
aujourd'hui une quinzaine de références.
Principes de l'offre
|
La
structure technique de la solution
|
|
SonicMQ
Il s'agit là du pilier historique de l'offre de Sonic. Middleware
Orienté Message, fondé sur le standard JMS (Java Message Service)
du modèle J2EE, il représente la technologie de transport de la
plate-forme. SonicMQ est réputé pour être bien adapté
à des environnements d'entreprise décentralisés. A noter
que ce MOM est accompagné d'un outillage d'administration et de supervision
particulièrement complet.
|
Sonic ESB
Sonic ESB s'apparente à un bus applicatif dédié à
la mise en œuvre d'architectures de services. C'est lui qui garantit l'enchaînement
des services exécutés dans le cadre de containers de services (voir
ci-après), que ces services soient des fonctions exposées (depuis
un progiciel ou un développement spécifique) ou encore des services
techniques de transformation et de routage. Sans surprise, les communications
entre les services et les composants techniques de l'ESB s'appuient sur Sonic
MQ. Et l'installation de Sonic ESB vient d'ailleurs mettre à jour les consoles
d'administration de SonicMQ. Quand aux enchaînements de services, ils sont
conçus via l'outil Stylus Studio. |
Stylus Studio
Integration Edition
C'est l'outil de développement clef de la suite d'intégration.
Son champ d'action est assez large : conception des enchaînements de services,
manipulation et conversion des différents schémas XML intervenant
dans les opérations de routage et transformation… Bref, c'est à
travers Stylus Studio que le développeur conçoit les services et
les assemble. |
Sonic Orchestration
Server
Attention ici au malentendu. Contrairement à ce que pourrait laisser
entendre son nom, Sonic Orchestration Server n'est pas conçu pour orchestrer
les services (c'est le rôle de Sonic ESB) mais des processus fonctionnels
longs qui appellent par exemple des mécanismes de compensation ou encore
des interventions humaines. Dans le contexte de l'offre Sonic, il faut donc prendre
garde de bien dissocier les processus ESB (l'enchaînement des services techniques)
des processus fonctionnels. Différence fondamentale entre ces deux types
de processus : les premiers sont stateless (leur statut ne fait pas l'objet d'une
persistance, le service est clos aussitôt consommé) tandis que les
seconds sont statefull. Autrement dit, si Sonic ESB est avant tout un moteur d'exécution
de services techniques, Orchestration Server s'apparente pour sa part à
ce que l'on nomme habituelle un moteur d'états. A noter que Sonic Orchestration
Server dispose de sa propre console d'administration depuis laquelle les états
des processus peuvent être consultés et les processus administrés.
|
Sonic XML Server
Cette brique sert à la fois à optimiser l'ensemble des traitements
XML (on pense notamment aux tâches de transformation) mais aussi à
stocker une représentation d'une base de données ou encore à
assurer la persistance de messages à des fins de supervision. Sonic XML
Server tutoie nativement des standards tels que XSL ou encore XQuery. |
Sonic ESB Adapters
Concernant le catalogue de connecteurs, Sonic Software a dans ce domaine
procédé comme beaucoup d'autres en nouant un partenariat avec iWay
Software. Cet accord lui permet d'afficher une large connectique (ERP, CRM, bases
de données) qui s'appuie notamment sur le standard JMS pour le transport
et sur XML pour le format des messages. Ajoutons que la plate-forme supporte les
standards des Web Services (SOAP et WSDL) dans des modalités d'implémentation
variées (SOAP sur http, SOAP sur JMS, etc). |
|
Les
concepts clefs de la solution
|
|
" Tout est service"
Bien comprendre l'esprit de la solution de Sonic demande de bien assimiler
que tout est "service" : des fonctions exposées depuis l'existant
jusqu'aux traitements de transformation ou de routage fondés sur le contenu
même des messages échangés. La mise en correspondance d'une
structure de données entre deux fonctions exposées sous la forme
de services donnera donc elle-même lieu à la création d'un
service. Autrement dit, un processus de type ESB est un enchaînement de
services techniques d'assez bas niveau. La définition de ces différents
services débouche sur la formalisation de "endpoints", lesquels
permettent de s'abstraire des couches de transport et de connectique utilisées.
Ces "endpoints" peuvent être des destinations au sens JMS ou encore
des connecteurs de type JCA (fichier, mail, etc.).
|
"Tout
est distribué"
La force indéniable de la suite Sonic réside dans son aptitude
à gérer les processus ESB de façon réellement distribuée.
Les services définis sont versés dans des containers qui peuvent
accueillir un ou plusieurs services, participant ou non aux mêmes processus.
L'idée, bien entendu, est de localiser ces containers de services au plus
proches des applications avec lesquelles ils traitent. Localement, ces containers
sont associés à un mini-référentiel qui leur permet
d'identifier que, dans le cadre d'un processus ESB donné, la consommation
du service A débouche sur la consommation du service B. Autrement dit,
l'exécution de ces processus ESB n'est pas suspendue à une communication
permanente avec un référentiel central. Le caractère distribué
de cette architecture de services permet de tenir la charge en multipliant localement
les instances de ces derniers. |
 L'avis
de l'expert
(Mariano Boni, directeur technique de Dreamsoft)
Quelques minutes suffisent pour comprendre que Sonic Business Integration Suite
appartient à cette catégorie de solutions fondée à
la fois sur les standards, qu'ils viennent de l'univers J2EE ou XML et sur une
conception de l'intégration totalement orientée service. La plate-forme
impressionne par sa capacité à concevoir et à définir
des services très finement. Trop peut-être penseront certains. Et
ce pour deux raisons. Primo, cette technicité dans la définition
des services appelle des compétences larges (MOM, Java, standards XML…).
Secundo, cette technicité destine clairement la solution à des projets
conçus dans une approche bottom-up, et notamment pour des entreprises désireuses
d'élaborer leur propre framework de services techniques et fonctionnels.
Un framework dont l'élaboration demandera beaucoup de rigueur. A défaut,
il deviendra vite délicat d'anticiper les impacts lorsque des modifications
devront être apportées dans les services. En revanche, si elle est
bien maîtrisée l'élaboration d'un tel framework donnera tout
son sens à travers l'Orchestration Server qui permettra de capitaliser
pleinement sur la réutilisation des services ESB. Reste la question inévitable
: cette solution est-elle ou non concurrente des plates-formes EAI ? Notre réponse
est nuancée. Dans certains contextes d'intégration (exemple : propagation
de référentiels en environnement centralisé), ces deux types
de solutions sont clairement concurrents. En revanche, une complémentarité
peut être identifiée dans des architectures d'intégration
délocalisées. En effet, combiner la performance de l'architecture
de services distribuée de Sonic avec une solution d'EAI traditionnelle
nous semble pertinent.
Terminons avec quelques détails concernant
l'outillage : si l'on apprécie fortement la complétude de l'outillage
associé à SonicMQ et Sonic ESB, l'ergonomie de Stylus Studio doit
en revanche encore pouvoir progresser pour gagner en productivité. De même,
nous attendons avec impatience un installateur unique pour l'ensemble des composants
de la solution- installateur qui figure au menu d'une prochaine version. Au final,
des péchés de jeunesse pour une plate-forme d'ores et déjà
fort prometteuse.
|
Points
forts
La maturité technique
Point
faibles
[