Succédant sans rupture au concept d’EAI (Enterprise Application Integration), l’ESB constitue aujourd’hui le meilleur moyen de construire des Architectures Orientées Services, nouveau modèle conçu pour rendre le Système d’Information facilement alignable sur les processus métiers. Quels sont les composants d’un ESB ? Comment choisir ? Si les éditeurs gardent une nette longueur d’avance, il est clair que les ESB Open Source commencent à apporter une alternative crédible. Au-delà de l’outil ESB, comme pour la plupart des projets applicatifs, la qualité d’industrialisation du développement sera un facteur clé du succès.

Dans le monde ouvert d’aujourd’hui, la flexibilité des systèmes d’information devient essentielle en matière d’avantage concurrentiel. Ceci conduit un grand nombre d’entreprises vers une stratégie informatique s’appuyant sur un découpage en grands "services" applicatifs et métiers", facilement combinables et interopérables. Toutefois, pour garantir le succès de cette stratégie, il faut pouvoir configurer, connecter et administrer ces services rapidement tout en veillant à la rentabilité de l’opération.
Les Architectures Orientée Services (SOA), nouveau modèle architectural pour les applications, sont conçues pour rendre le Système d’Information agile, flexible et gouvernable, faciliter les déploiements et aligner technique et métier. Les services sont alors exposés par des interfaces facilitant l’accès et l’exécution de traitements applicatifs modulaires.
L’objectif d’un Bus de Services d’Entreprise (ESB) est de fournir, de façon intégrée et en s’appuyant sur des standards, l’infrastructure nécessaire pour rendre accessibles les services techniques et applicatifs. Et ce pour l’ensemble du système d’information de l’entreprise ou d’un écosystème multi-entreprises.
Succédant sans rupture au concept d’EAI (Enterprise Application Integration, popularisé à la fin des années 1990), l’ESB aujourd’hui va plus loin en apportant des mécanismes de simplification (même si l'approche reste encore complexe) et en s'appuyant sur des standards : services Web, connecteurs d’applications, langage XML, transformation et routage intelligent des messages, etc. C'est le fruit d’une industrialisation, qui a pour conséquence la baisse des coûts de mise en œuvre .
Les gains de l’ESB sont nombreux et tangibles : amélioration de l’efficacité de l’intégration applicative, possibilité de multiplier les accès et les traitements, réduction des coûts liés à la maintenance et aux évolutions, amélioration des performances, etc.

Les domaines de l’ESB
Quels sont les composants d’un ESB ? On trouve aujourd’hui six domaines majeurs dans les suites logicielles d’intégration des principaux éditeurs :

Le registre et le référentiel
Au cœur de l’ESB, le registre et le référentiel facilitent la gestion, le déploiement et la découverte des services, la gestion de leur cycle de vie et des composants associés : gestion des versions, notifications des usagers en cas de changement, gouvernance par une gestion des politiques. Une solution intégrée et standard est souhaitable, pour interopérer avec plusieurs registres et référentiels qui apparaîtront comme un seul élément virtuel. Les standards sont actuellement ebXML (registre et référentiel) et UDDI (registre), sous-ensemble du standard ebXML de registre.

L’environnement de développement
L’environnement de développement intégré est un point très important de l’ESB de par sa capacité à apporter flexibilité et réactivité au système d’information. C’est le domaine qui va assurer et faciliter, via des consoles IDE, le développement, l’intégration, les tests, le déploiement et la gestion du cycle de vie des services.

La gestion
Les architectures SOA ont un objectif de gouvernance axé sur une prédominance du fonctionnel par rapport au technique. La technologie doit s’aligner sur le métier pour que la réactivité du SI à s’adapter aux changements devienne une réalité.
Un système de gestion et d’administration centralisé, fonctionnel et technique, automatisé par des processus, de préférence pilotés par les événements (event-driven), assurant une visibilité grâce aux tableaux de bord (dash-boards) et aux reportings, est l’instrument indispensable à la gouvernance. Selon les éditeurs, les systèmes de gestion sont intégrés ou externes à leur offre ESB. Mais dans tous les cas, les ESB sont proposés avec un tel système.

La sécurité
Le système de sécurité repose sur des politiques et des processus et peut avoir une portée multi entreprises (fédération d’identité par exemple). C’est un outil indispensable à la gouvernance car il constitue un pilier de l’intelligence économique de l’entreprise et doit être conforme à la réglementation (comme Sarbanes-Oxley). Un ESB a des caractéristiques de sécurité qui lui sont propres pour répondre aux risques auxquels il est exposé et aux besoins de sécurité des utilisateurs ; il doit disposer de mécanismes de sécurité réseau, de gestion des vulnérabilités, de sécurité de contenu et de gestion des identités et des accès.

La gestion des processus
• Le workflow diminue le codage dans les applications en permettant de décharger le code de l’application du code comportemental. Il peut être complété par un moteur de règles pour décharger le code de l’application du code décisionnel. Le workflow apparaîtra également dans le niveau applicatif des systèmes de management et de sécurité qui exécutent des processus de plus en plus pilotés par événements.
• L’orchestration des processus dépasse le cadre d’une orchestration applicative de services Web. Un ESB contient un mécanisme d’orchestration interne des services à majorité technique qui entrent dans la composition des flux. Le but est de rendre la partie technique flexible et agile comme le sera la partie fonctionnelle. Ne plus programmer, composer ses flux avec une console graphique, tel est l’objectif. Dans ce domaine, on retrouve encore l’objectif propre aux SOA d’aligner technique et métier et d’augmenter l’agilité en unifiant les mécanismes.

L’intégration et le transport
• L’intégration de composants s’effectue via un bus de services qui sert d’interface et normalise les échanges de messages entre les composants intégrés. Les composants sont de deux types : soit ils rendent des services fonctionnels ou techniques, soit ce sont des connecteurs pour assurer des échanges avec l’extérieur : services externes, mainframes, clients (humains/programmes).

Réduction et normalisation des échanges par un bus de service

• Le transport, enfin, joue un rôle important car il assure la distribution pour déployer un système sur des réseaux IP de type Intranet, Extranet, Internet. Il le rend également extensible (scalable) en augmentant le nombre de bus de service pour absorber la charge ou pour faciliter la modularité des traitements fonctionnels.
La fiabilité, la performance et la continuité de service qui suppose une gestion de la persistance, du support des transactions, du partage de charge et de la haute disponibilité, sont des points essentiels. Un ESB supporte différents types de transports orientés message : synchrones ou asynchrones (MOM) avec un mode publish/subscribe (event-driven) correspondant à des types fort, faible ou zéro couplages entre les entités communicantes. Le couplage faible et le zéro couplage sont les couplages privilégiés d’un ESB.
Notons que le bus ne se contente pas de transporter seulement des messages. Il assure également des services de routage intelligents, en s’appuyant sur le contenu et les services de médiation (translations, transformations). Ces services facilitent les échanges entre des composants qui utilisent différents types d’accès et formats de données. Ainsi, une application Cobol qui utilise un format de message structuré et MQSeries comme système de messagerie pourra communiquer avec un EJB d’une application Java qui traite des données au format XML et utilise JMS comme système de messagerie. La construction de ce type de flux pris avec ses systèmes de messagerie hétérogènes, la médiation pour la translation des protocoles et la transformation des données Cobol en XML et vice versa, se fera sans codage à l’aide d’une console graphique.

Déployer un ESB : quelles alternatives ? Quelles tendances ?
Face au besoin croissant de flexibilité des SI, les ESB connaissent aujourd’hui un développement rapide. Selon Gartner, plus de la moitié des grandes entreprises auront un ESB en service fin 2006. Les éditeurs et les intégrateurs ne s'y trompent pas : la plupart d’entre eux ont intégré l'ESB au cœur de leur offre. Aux éditeurs pionniers comme Axway, BEA, Cape Clear, Fiorino, Iona, Sonic Software, SeeBeyond, Tibco ou Web Methods, se sont joint les grands éditeurs de logiciels d’entreprise comme Oracle, SAP, IBM et d’autres.
A leur tour, les acteurs du monde ouvert comme Apache, Codehaus, JBoss et ObjectWeb font une entrée en force, avec des solutions non seulement fiables et peu coûteuses, mais offrant également une grande souplesse d’adaptation grâce à l’ouverture du code libre : Celtix, Mule, Petals, ServiceMix, Synapse, etc.
Confrontées à une multiplicité de choix, les entreprises peuvent retenir des solutions éditeurs intégrées et clé en main, ou faire leur marché parmi des composants individuels. Une grande liberté que favorise l’interopérabilité de nombreux éléments, et qui peut parfois autoriser une approche ‘best of breed’ pour certains domaines. Dans le domaine du registre, par exemple, celui de la société SYSTINET, conforme au standard UDDI, constitue une référence et est commercialisé en OEM par plusieurs éditeurs. De même, L’état de l’art actuel dans le domaine des IDE est constitué par des environnements de développement intégré basés sur ECLIPSE, avec les plug-ins couvrant l’ensemble des besoins des services techniques et métiers. WTP (Web Toolkit Platform) et STP (SOA Toolkit Platform) sont des exemples d’IDE du monde ouvert. Enfin, on l’a vu, les composants Open Source commencent à offrir des alternatives attractives.
Comment choisir ? Outre les paramètres techniques propres à chaque projet et à chaque contexte, deux facteurs doivent être particulièrement pris en compte : l’ouverture, et l’interopérabilité. La montée en puissance de l’Open Source est significative de cet état de fait, même si les solutions libres sont encore surpassées pour de nombreuses fonctionnalités par les solutions propriétaires.
C’est un domaine sur lequel Bull s’implique significativement, à la fois comme contributeur et comme intégrateur. Expert de longue date de l’intégration des middleware dans des projets complexes, puis contributeur important au développement des middleware libres (serveur d’application, moniteur transactionnel, workflow, orchestration de services web, etc.), Bull est intégrateur des grands ESB éditeurs au travers de nombreux projets, et participe au développement des ESB libres, d’une part en collaborant en terme de R&D avec diverses communautés, et d’autre part au travers de projets clients orientés vers le libre.

Au-delà des plates-formes ESB, l’expérience montre en outre que l’industrialisation des développements, joue un rôle clé dans le succès des projets. Car un projet ESB s’insère bien souvent dans un projet d’ensemble, qui requiert des développements applicatifs spécifiques. Dans ce contexte, de nombreux éléments doivent être gérés avec une grande attention : la gestion de la qualité (gestion des tests, des bogues et des correctifs, gestion des processus de validation, de sauvegarde, etc.), la capitalisation (méthodologies, processus et règles de réutilisation de composants, référentiel documentaire, etc.) et un partage efficace d’information entre intervenants (gestion des sources, reporting, alertes, traçabilité des décisions prises, etc.).

C’est la raison pour laquelle Bull a développé, au cœur de son dispositif et de ses centres de services, NovaForge™ : une plate-forme sécurisée de gestion de projet et de développement intégré distribué. L’objectif : rationaliser et mutualiser les moyens de développements de nos clients pour améliorer la productivité, la qualité et la maintenabilité de leurs applications.
Au-delà de l’outil ESB choisi, comme pour la plupart des projets applicatifs, la qualité d’industrialisation du développement s’avère ainsi un facteur clé du succès, à prendre fortement en compte. L’enjeu est important, à la fois en terme de qualité, de délais et de coûts. Il doit être bien pris en compte dans tout projet.

Plus d’information sur les contributions de Bull au développement des middleware libres >>