Un ESB est un produit logiciel qui a pour but de faciliter la communication d'applications basées sur des technologies souvent différentes.
Les ESB s'inscrivent la plupart du temps dans une démarche d'architecture orientée services (ou SOA) pour un système d'informations d'une entreprise ou les applications disposent de points d'entrée servant de pilotage ou d'intégration de données et de points de sorties passifs (évènements internes exposés ou public) ou actifs (capables d'interroger d'autres sources de données).
WSO2 ESB permet de se connecter, d'administrer et de transformer différents type de services (Ws-*, REST/POX, Legacy...) sur différentes couches de transport (HTTP/HTTPS, JMS, système de fichier, mail).
Il supporte les normes WS-Security et WS-Reliable Messaging ainsi que plusieurs formats de message (SOAP 1.1/1.2, PoX/REST, Hessian, MTOM ou encore SwA).
Une interface graphique d'administration ainsi qu'une interface JMX permet de configurer et surveiller les différentes communications des services gérés par l'ESB.
NdM : cet ESB est publié sous licence Apache 2.0. Les ESB permettent dans les architectures de type SOA de proposer un cadre de communication de services et de centraliser les problématiques liées à la communication événementiels :
- Centralisation des services et exposition, support de documentation
- Gestion d'abonnement aux services
- Filtrage à la source, à l'enrichissement ou à la consommation
- Enrichissement d'évènements avant propagation aux consommateurs
- Gestion des évènements en erreur - problématique de recyclage et interface de traitement des erreurs
- Orchestration et composition de service (BPEL)
- Gestion et surveillance de la consommation des services
Les fonctionnalités principales de WS02 ESB sont :
- support des protocoles http/s, JMS, FIX, Apache VFS (s/ftp, fichiers, zip/tar/gz, webdav, cifs..), POP3/IMAP/SMTP, AMQP
- support des formats SOAP 1.1/1.2, PoX/REST, Hessian, texte et payloads binaires
- possibilité de programmer des tâches de manière cyclique dans le temps ou à la suite d'évènements
- possibilité d'étendre les fonctionnalités de l'ESB par l'intermédiaire de classes Java
- support des langages de scripts comme Javascript, Ruby, ou encore Groovy
- possibilité de déploiement en cluster
- cache, répartition de charge et bascule en cas d'erreur
- support des standards "WS-Reliable Messaging", "WS-Security" ou encore "WS-Policy attachment"
- intègration du produit "WSO2 Registry" avec un support pour les registres externes
Nouvelles fonctionnalités de la version 1.7 :
- support des messages binaires Hessian
- support du protocole de transport FIX (Financial Information eXchange)
- support du standard WS-Reliable Messaging avec "WSO2 Mercury"
- possibilité de contrôler le serveur (arrêt, redémarrage) du serveur à travers JMX
- intègration du produit "WS02 Registry"
- support de l'encodage GZIP
- support du code d'erreur "HTTP 100 continue"
- support de l'échange de messages sur double canaux grâce à WS-Addressing
- support du clustering avec répartition de charge en mode "sticky".
- flux de données non bloquant pour les messages de grande taille et consommation stable de mémoire
- support des clauses de type "ELSE" pour les filtre de type Mediator
- possibilité de spécifier des expressions XPath pour l'enveloppe ou le corps des messages
- possibilité d'utiliser des politiques différentes pour les messages entrants ou sortants
- support de l'utilisation d'une séquence obligatoire avant la médiation des messages
- nouveau médiateur "Router"
- possibilité de redéployer les services proxy
Aller plus loin
- Page de téléchargement (31 clics)
- Documentation (28 clics)
# Question de néophyte.
Posté par soulflyb (Mastodon) . Évalué à 3.
[^] # Re: Question de néophyte.
Posté par jeffcom . Évalué à 3.
# Juste pour ouvrir le débat
Posté par franck villaume (site web personnel) . Évalué à 3.
Autre question, WSO2 offre un ESB standalone, quid de son intégration dans un serveur d'applications libre ? Je pense à JonAS, JBoss AS, Glassfish.
# Single Point of Failure
Posté par Paul . Évalué à 2.
Ok, les connecteurs à droite à gauche pour faire causer tout un bordel de services entre eux c'est lourd à maintenir ... mais, de mon point de vue, ça permet au SI composé de ces différents services de mettre en oeuvre des modes dégradés si un connecteur déconne. Lorsque c'est l'ESB qui déconne ... toutes les interconnections en dépendant sont impactées.
Existe-t-il des solutions (libres!) à ce genre de problèmes aujourd'hui ? Allègent-elles le cout de maintenance par rapport aux multiples connecteurs ?
[1] http://fr.wikipedia.org/wiki/Single_point_of_failure
[^] # Re: Single Point of Failure
Posté par Olivier MARTIN . Évalué à 1.
Le but est de capitaliser ces connecteurs au sein d'un applicatif transverse et de pouvoir avoir un point central pour trouver des services, les documenter, les surveiller au lieu de redévelopper les mêmes couches sur chacun des applicatif d'un SI.
# Business loto
Posté par titi toto . Évalué à 4.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.