Sortie du logiciel libre WSO2 ESB en version 1.7

Posté par  . Modéré par Nÿco.
Étiquettes :
0
2
juil.
2008
Technologie
L'Enterprise Service Bus (ou ESB) de la société WSO2 est sorti en version 1.7.

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

  • # Question de néophyte.

    Posté par  (Mastodon) . Évalué à 3.

    Pour situer un peu ce dont on parle, est-ce que c'est comparable à ce genre de projet : http://www.tls.cena.fr/products/ivy/ ou pas du tout ?
    • [^] # Re: Question de néophyte.

      Posté par  . Évalué à 3.

      oui sauf que wso a l'air plus complexe/puissant et a priori permet plus de combinaisons
  • # Juste pour ouvrir le débat

    Posté par  (site web personnel) . Évalué à 3.

    WSO2 fait sans doute ici un bon travail mais pourquoi ne pas suivre la norme JBI 1.0 ( cf http://fr.wikipedia.org/wiki/Java_Business_Integration ) ?

    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  . Évalué à 2.

    Je suis du genre "tout naze en matière d'ESB", bien que j'en comprenne les mécanismes et en ai déjà fréquenté (ou "traversé"). Une question me viens à l'esprit à chaque fois que j'entends des gens causer ESB ... un ESB ne peut-il pas devenir un point individuel de défaillance [1] d'un SI ?

    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  . Évalué à 1.

      Oui un ESB est souvent un SPOF ;)
      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  . Évalué à 4.

    Foutaises !

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.