Pour savoir où on va, il faut savoir d'où l'on vient

Vous avez
une question ?
Un projet ?

Contactez nous !
 

Contactez-nous

Vous avez une question ? un projet ? 
Vous souhaitez plus d'informations sur un produit ? sur notre offre ? 
Contactez-nous, on vous répond sous 4H.

retour

ESB : Entrprise Service Bus

ESB : Entrprise Service Bus

Nous avons vu dans les chapitres précédents toutes les pièces qui ont permis l'émergence des ESB. Nous allons maintenant les assembler.

Origines

Toutes les architectures successives évoquées précédemment, mainframe, client /serveur, n-tiers, cloud, ont révélé plusieurs défauts :

  • Application monolithique : une application réalise l'ensemble des fonctionnalités, stocke l'ensemble des données afférentes et met à disposition une UI pour interagir avec celles-ci. Cette architecture est en général difficilement maintenable et évolutive.
  • Couplage fort : un client est lié à son serveur via un protocole, un format propre, des adresses potentiellement fixées en dur. Toute modification de l'un des composants peut nécessiter une nouvelle livraison des autres pour que le système puisse continuer à fonctionner. On appelle cela souvent le « syndrome du plat de spaghetti. »
  • Silo applicatif : Une ou plusieurs applications sont réalisées pour un métier donné. Elles sont capables uniquement de communiquer entre elles. Cependant, la structure d'une entreprise vit et donc évolue. Le SI sous-jacent doit évoluer également pour répondre aux attentes des utilisateurs. Les silos empêchent cette évolution et ne permettent pas de partager des informations et des fonctionnalités entre les différents métiers. Cela a pour conséquence des duplications, des problèmes de communication, des évolutions disparates et finalement une augmentation des coûts.

EAI - Entrprise Application Integration

Screenshot from 2015-04-10 10:24:46

C'est en arrivant sur ce constat simple que le concept architecturale d’Entreprise Application Integration ou EAI est apparu au début des années 2000. Ce terme a fait un énorme buzz marketing à son époque mais la fièvre est retombée rapidement...

En cause, les solutions proposées par les différents éditeurs (Oracle, SAP, Tibco, WebMethods, IBM, etc.) et la jeunesse de la
vision architecturale.

L'EAI, à la base un pattern architectural décrivant les principes d'intégration applicative, est devenu une famille de produits middleware appliquant ce pattern. Ces produits sont basés sur

la topologie d'hub and Spokes. L'EAI, en son centre, ou hub, interagit avec l'ensemble des applications avec un connecteur propriétaire, le spoke. L'EAI est un Single Point of Failure de l'ensemble du SI.
En 2003, plusieurs études sur les projets de mise en œuvre d'un EAI révèlent que la majorité, on parle de plus de 70 %, des projets a échoué. Les principales causes observées5 :

  •  Un projet en perpétuelle évolution : un EAI est par nature une application dynamique qui doit évoluer en permanence. De nombreuses entreprises l'ont considéré comme une application comme une autre sans prendre en compte, et budgéter, une maintenance importante dans le temps.
  • Expertise en EAI rare : un EAI est un composant applicatif complexe qui interagit avec de nombreux sous-systèmes et est généralement basé sur des principes et des technologies propres à chaque éditeur. Les compétences dans le domaine sont donc extrêmement restreintes.
  • Des standards concurrents : A l'origine basé sur des protocoles communs, les éditeurs de solutions d'intégrations ont petit à petit ajouté leurs propres normes et spécifications pour gérer des cas particuliers. cela a rendu les différents systèmes non interopérables entre eux.
  • Utiliser un EAI comme un outil : un EAI n'est pas un outil qui vit seul dans son monde. C'est un composant au cœur d'un système d'information et ce système doit être  pensé et organisé pour l'utiliser de manière efficiente. Une vision réductrice a des conséquences graves sur l'ensemble du SI.
  • Créer des interfaces est un art : Concevoir simplement techniquement une interface de communication ne suffit pas ; il faut avoir la vision top-down de l'intégration et faire discuter ensemble les différents interlocuteurs, fournisseurs de données, consommateurs de données, utilisateurs finaux pour embrasser l'ensemble du sujet et concevoir une interface simple et surtout utile pour tous.
  • Le manque de détail : Une information négligeable au départ peu se révéler extrêmement coûteuse par la suite si elle n'est pas connue et prise en compte. Un référentiel clair des interactions, de leur mode de fonctionnement et de leurs objectifs doit être défini et surtout maintenu au cours du temps.
  • La responsabilité budgétaire mal définie : un EAI, étant au cœur du SI, est employé par de nombreux services et métiers de l’entreprise qui ont chacun leur propre budget. La question de la responsabilité et des coûts induits se pose donc.

La genese des DES ESB

in 2002, Sonic, une filiale de Progress Software Corporation, propose le premier logiciel sous la terminologie Enterprise Service Bus (ESB), SonicMX. Tous les éditeurs concurrents lui emboîtent le pas les années suivantes. Vendus comme une révolution par rapport à la lourdeur et la complexité des EAI, les ESB ne sont en réalités bien souvent qu'un simple re-branding de ceux-ci. Ce n'est à partir de 2005-2006 que le terme ESB prend pleinement consistance et que les solutions éditées se démarquent ouvertement de leurs prédécesseurs, notamment poussées par des solutions émergeant dans le monde Open Source.

Définition

L'ESB est comme la SOA ou les EAI une notion qui possède plusieurs définitions plus ou moins complètes selon les organismes et éditeurs de solution.
Roy Schulte de Gartner en donne l'une des premières définitions en 2003 : « Un Enterprise Service Bus (ESB) est une nouvelle architecture qui exploite les services web, les
systèmes orientés messages, le routage intelligent et la transformation. L'ESB agit comme une colonne vertébrale légère et omniprésente de l'intégration à travers laquelle les services logiciels et les composants applicatifs dialoguent »

En 2007 Anne Thome Manes de Burton Group définit l'ESB de cette manière : « Un Enterprise Service Bus (ESB) est une solution middleware qui permet l'interopérabilité
d'environnements hétérogènes utilisant un modèle orienté service (SOA). Bien que fréquemment associé avec des concepts comme l'intégration et la médiation un ESB fournit également une plate-forme de service comparable à un serveur d'application. En réalité les ESB représentent l'unification du monde de l'intégration et des serveurs d'application. La vrai avancée des ESB est sa capacité à virtualiser des services. Un conteneur de services ESB abstrait un service et l'isole de son protocole de communication, de ses méthodes d'invocations, de ses patrons d'échange de message, de ses exigences en termes de qualité de service et d'autres besoins
d'infrastructure. »

Screenshot from 2015-04-10 10:34:50

Si l'on essaye de faire la synthèse de ces définitions et des produits existants sur le marché, on peut dire que les ESB sont des composants middlewares basés sur le principe d'un bus de messages permettant la communication entre applications hétérogènes, facilitant l’implémentation des concepts de la SOA en favorisant l'utilisation de web services et de standards et en mettant en œuvre les EIP.

ESB légers et ESB lourds

Dans la littérature concernant les ESB, vous trouverez souvent la notion d'ESB légers et d'ESB lourds pour caractériser les différentes solutions existantes sur le marché. Cette différenciation très obscure est due à ce problème de définition d'un ESB. En général, on parlera d'un ESB lourd pour un ESB descendant directement des solutions d'EAI et ayant une couverture fonctionnelle très importante, mais, revers de la médaille, qui seront complexes et lourds à mettre en place. Les ESB légers, quant à eux, ont en général fait le choix de réduire leur périmètre fonctionnel et de se baser sur des architectures logicielles agiles et simples et donc, par définition, plus légères à mettre en place.

On remarquera que les solutions propriétaires sont presque exclusivement des ESB lourds et les solutions open source presque exclusivement des ESB légers.

Caractéristiques principales

Les solutions ESB ont toutes plusieurs caractéristiques fondamentales qu'elles se doivent d'implémenter :

  • Connectivité et communication : Un ESB doit permettre de communiquer avec de multiples protocoles et formats basés sur des standards reconnus par tous (SOAP, REST, XML, JSON, EDI, JMS, CORBA, etc.) et ce de manière synchrone ou asynchrone (le deuxième étant à privilégier). Pour ce faire, il doit notamment être capable d’interagir avec un Middleware Orienté Message (MOM) embarqué ou non au sein de l'ESB.
  • Routage : Un ESB doit permettre de découpler fournisseurs et consommateurs de données. Il doit ainsi mettre à disposition un mécanisme permettant de distribuer les messages depuis un fournisseur vers un ou des consommateurs de manière transparente pour l'un et l'autre. On retrouvera ici un certain nombre d'implémentations de patrons EIP.
  • Transformation : un fournisseur et un consommateur ne dialoguant pas forcément dans un même langage, un ESB doit mettre à disposition des moyens de transformation des messages. (cf EIP)
  • Orchestration : l'orchestration peut être de deux ordres :
    • Technique : Les ESB légers n'appliquent que la partie technique en mettant en œuvre des pipes, des filtres et une forme basique de gestion de processus réduite à l'instant présent.
    • Fonctionnelle : Les ESB lourds incorporeront en plus l'orchestration fonctionnelle capable de gérer une longue traîne que l'on retrouvera également dans les applications de BPM.
  • Outil de Surveillance :
    • Technique : Les ESB doivent permettre de surveiller l'acheminement des messages et de fournir un ensemble de métriques techniques afférentes aux flux et à la plate-forme. (Service Activity Monitoring – SAM)
    • Métier : En sus certains ESB vont permettre de réaliser un contrôle fonctionnel et métier des messages qui transitent (Business Activity Monitoring – BAM)

Bases techniques

Techniquement un Enterprise Service Bus est composé de :

  • Un framework d'intégration, qui réalise les opérations de médiation sur les flux de messages. Il en existe plusieurs sur le marché :
    • Spring
    • Apache Camel
    • Apache Synapse...
  • Un framework de services, qui permet de concevoir les web services qui pourront être utilisés par les applications du SI. Il en existe plusieurs sur le marché :
    • Apache CXF
    • pache Axis2...
  • Un système de gestion de composants, qui permet de gérer dynamiquement l'installation, le démarrage, l'arrêt, la désinstallation à chaud de composants techniques. Il en existe plusieurs sur le marché :
    • OSGi
    • SCA...
  • Un serveur d'application, qui est un conteneur de contexte d’exécution pour application qui va notamment gérer toutes les connexions. Il en existe plusieurs sur le marché :
    • Apache Tomcat
    • Jboss...
  • Un Middleware Orienté Message, qui permet de gérer des files d'attentes de messages dans le cadre d'échanges asynchrones. Il en existe plusieurs sur le marché :
    • Apache ActiveMQ
    • RabbitMQ
    • Apache Qpid...
  • Un registre, qui permet de stocker et gérer des informations contextuelles nécessaires aux composants pour fonctionner (par exemple l'adresse d'un service)

Les ESB de la Fondation Apache

La fondation Apache possède 2 ESB à son catalogue :

  • Apache ServiceMix (2005 – LogicBlase/FuseSource)
    • framework d'intégration : Apache Camel
    • framework de service : Apache CXF
    • système de gestion de composant : OSGi → Apache Karaf
    • MOM : Apache ActiveMQ
  • Apache Synapse (2006 – WSO2)
    • framework d'intégration : Apache Synapse
    • framework de service : Apache Axis2

Ces deux projets sont de très bonne qualité mais sont livrés bruts. En général on préférera donc utiliser une version packagée avec un set d'outils de développement et d'administration comme ceux que l'on retrouvera dans les solutions RedHat Jboss Fuse ESB, Talend ESB ou WSO2 ESB.

Les nouveaux courants

La vision ESB est une tendance de fond qui accompagne notre société vers son souhait de plus de rapidité, plus d'interaction, plus de dématérialisation. L'ESB est devenu la base de nouvelles offres commerciales ces derniers mois pour répondre à ces besoins.

ESB à la demande (iPaaS)
Screenshot from 2015-04-10 10:55:25

Avec l’avènement du cloud, le besoin de toujours plus de connectivité et le souhait des entreprises d'externaliser
leur infrastructure se sont démocratisés. Il existait jusqu'à présent un vide pour lier toutes ces nouvelles applications et services dans
un environnement déporté. Les Infrastructures Plateform as a Service, ou IpaaS, sont là pour y combler ce vide.
Gartner en donne la définition suivante :
« Integration Platform as a Service (iPaaS) est une suite de services cloud permettant le développement, l'exécution et la gouvernance de flux d'intégration rendant possible la connexion de n'importe quelle combinaison de processus, services, applications et données locales ou dans le cloud au sein d'une organisme ou entre plusieurs organismes. »

Screenshot from 2015-04-10 10:59:45

Éditeur : MuleSoft
Site internet de la solution : http://cloudhub.io
Date de création : 2010

En février 2010, MuleSoft est la première société à entrer sur ce marché avec sa plate-forme  Cloudhub. En 2012, Cloudhub est pleinement intégré dans le cycle de release de Mule Studio et Mule ESB. Aujourd'hui, MuleSoft axe clairement son développement sur l'enrichissement de cette plate-forme.

Cloudhub met à disposition sa plate-forme au travers de 3 offres et donne la possibilité de tester ses possibilités durant 30 jours.

Pour utiliser pleinement les capacités de cette plate-forme il est recommandé de lui adjoindre les services d'Amazon SQS pour la partie MOM.
OpenShift

Screenshot from 2015-04-10 11:01:28

Éditeur : Red Hat
Site internet de la solution : https://www.openshift.com/
Site de la version Open Source : http://openshift.github.io/
Date de création : 2011
OpenShift est la plate-forme PaaS de RedHat et est pleinement opérationnelle depuis juin 2013 avec :

  • OpenShift Origin : projet open source
  • OpenShift Online : Public Cloud
  • OpenShift Enterprise : Cloud privé

Cette plate-forme repose en version publique sur Amazon AWS avec RHEL et SeLinux. La version open source et la version Entreprise peuvent également reposer sur l'IaaS OpenStack.

La spécificité de ce PaaS est qu'il n'est pas centré sur une technologie ou un langage. Vous pouvez aussi bien y déployer du Java, du Ruby, du PHP ou du NodeJS.

OpenShift met à disposition des Cartridges contenant une technologie ou un framework installable par un simple clic. L'ensemble des produits de Jboss, et donc également de Fuse, y sont disponibles.
Le Cartridge Fuse ESB existe depuis début 2014. Il est uniquement distribué en version Alpha et évolue régulièrement. Malgré son jeune âge, le produit est déjà extrêmement complet et stable.

WSO2 Cloud / Stratos

Screenshot from 2015-04-10 11:03:43

Éditeur : WSO2
Site internet de la solution : http://wso2.com/cloud/
Site de la version Open Source :
http://wso2.com/cloud/private-paas/
Date de création : 2011
Après avoir publié une première version de Stratos en décembre 2010, WSO2 sort en juillet 2011 sa plate-forme SaaS StratosLive qui permet d'exploiter dans le cloud l'ensemble des produits de la stack WSO2. En juin 2013, WSO2 reverse à la fondation Apache Stratos, renomme son service en WSO2 Cloud et revoit toute sa stratégie dans ce domaine.

WSO2 se base sur OpenStack pour fournir ses services et met à disposition une AMI Amazon EC2. WSO2 Cloud est en réalité 3 offres :

  • WSO2 Public Cloud : une infrastructure cloud partagée entre utilisateurs. Actuellement seul deux produits sont disponibles mais cette offre devrait s'étendre dans le futur avec App Cloud, API Cloud
  • WSO2 Managed Cloud : une infrastructure dédiée mais gérée par WSO2
  • WO2 Private Cloud : une plate-forme cloud pouvant être installée et gérée entièrement par le client.

Cette plate-forme n'est pas encore considérée comme « production ready ».

API Management

Le 7 février 2000 Salesforce lance la première API publique et très rapidement d'autres acteurs lui emboîtent le pas comme Ebay. Depuis 2010, nous assistons à une véritable explosion du nombre de services exposés sur le web.

Screenshot from 2015-04-10 11:06:34

Depuis peu, une véritable monétisation des APIs prend forme et ce développement nécessite de nouveaux outils pour répondre aux défis de ce marché. Ainsi, en novembre 2006, Mashery lance le premier service de gestion d'API. Depuis, de nombreux concurrents sont entrés sur le marché comme 3scale, Apigee, Layer 7 ou Vordel (Axway). Le monde de l'Open source a suivi le courant et s'attaque aux marchés depuis plusieurs mois.

Un API Manager est concrètement une solution permettant :

  • d'exposer des APIs (en REST et/ou en SOAP)
  • des transformations légères et d'appliquer des policies
  • de gérer le cycle de vie des services
  • de présenter, documenter et/ou vendre des APIs
  • de surveiller les usages des APIs

Anypoint Platform for API

Screenshot from 2015-04-10 11:09:03

Éditeur : MuleSoft
Site internet de la solution : http://cloudhub.io
Date de création : 2013

MuleSoft a lancé sa Plateforme Anypoint for APIs courant 2013. Disponible, pour le moment, uniquement sur sa plate-forme cloud, cette offre, utilisant pour cœur son ESB, s'est enrichie d'un véritable gestionnaire d'API, d'outils complétant son studio et d'un générateur de portail.

Mulesoft ne s'est pas contenté d'apporter des outils mais a souhaité réellement mettre sa touche personnelle dans le domaine. Mulesoft a ainsi racheté en 2013 le site
ProgrammableWeb qui est la référence de l’information sur le sujet, et s'est investi dans la création d'un nouveau langage de description des APIs REST, le RAML.

Pour le moment, la plate-forme ne gère officiellement que des APIs REST.
Il est à noter qu'en plus d'investir dans le domaine, MuleSoft a su s’attirer l'attention de grands noms du domaine comme Salesforce qui y a investit plusieurs millions de dollars en 2013.

WSO2 API Manager
Screenshot from 2015-04-10 11:11:55

Éditeur : WSO2
Site internet de la solution : http://wso2.com/
Date de création : 2012

WSO2 API Manager, sorti en 2012, a été la première solution open source sur le marché. Basée sur son ESB, utilisant son service d'identification WSO2 Identity Server et son service de monitoring WSO2 Business Activity Monitor, WSO2 API Manager est une solution complète
et en phase avec le marché. Cette solution est disponible à la fois en « on premise » et dans le cloud.

WSO2 API Manager a été reconnu en 2013 par Gartner comme une solution innovante sur le marché. Comme tous les produits de WSO2, celui-ci est sous licence Apache 2.0.