Un  ESB est un composant essentiel de l'architecture SOA ou architecture orientée services, une architecture  logicielle apparue à la fin des années 1990. L'architecture SOA  définit un moyen de rendre les composants logiciels réutilisables par le biais d'interfaces de services. Ces services utilisent généralement des interfaces standard (c'est-à-dire des  services Web) de telle sorte qu'ils peuvent être rapidement incorporés dans de nouvelles applications sans avoir à dupliquer la  fonctionnalité  exécutée par le service dans de nouvelles applications.réutilisables via des interfaces de service.

Chaque service d'une architecture  SAO  comprend le code et les  données  nécessaires à l'exécution d'une fonction métier complète et distincte (par exemple, la vérification de la solvabilité d'un client, le calcul d'une mensualité de prêt ou le traitement d'une demande de prêt immobilier). Les interfaces de service offrent un couplage lâche, ce qui signifie qu'elles peuvent être appelées avec peu ou pas de connaissances sur la façon dont le service est implémenté en dessous, réduisant ainsi les dépendances entre les applications. Les applications derrière l'interface de service peuvent être écrites en  Java ,Microsoft .Net, Cobol ou tout autre langage de programmation, fournies en tant qu'applications d'entreprise empaquetées par un fournisseur (par exemple,  SAP), applications  SaaS  (par exemple, Salesforce CRM) ou obtenues en tant qu'applications  open source .  

Les interfaces de services sont souvent définies à l'aide du WSDL  (Web Service Definition  Language), qui est une structure de balises standard basée sur XML  (extensible markup language).  Les services sont exposés à l'aide de protocoles de réseau standard, tels que SOAP (protocole d'accès simple aux objets)/HTTP ou JSON/HTTP, pour envoyer des demandes de lecture ou de modification de données. La gouvernance des services contrôle le cycle de vie du développement et, au stade approprié, les services sont publiés dans un registre qui permet aux développeurs de les trouver rapidement et de les réutiliser pour assembler de nouvelles applications ou des  processus métier.

Les services peuvent être créés à partir de zéro, mais ils sont souvent créés en exposant les fonctions des  systèmes d'enregistrement  existants. Les entreprises peuvent choisir de fournir une interface de service basée sur des normes devant les systèmes existants, d'utiliser l' ESB  pour se connecter directement au  système existant  par le biais d'un  adaptateur  ou d'un  connecteur, ou l'application peut fournir sa propre  API. Dans tous les cas,  le  bus de service d'entreprise  protège la nouvelle application de l'interface existante. Un  ESB  effectue la transformation et le routage  nécessaires pour se connecter au service des  systèmes existants .

Il est possible d'implémenter une architecture  SOA  sans architecture  ESB , mais cela reviendrait à n'avoir qu'un ensemble de services. Chaque propriétaire d'application devrait se connecter directement à un service dont il a besoin et effectuer les  transformations de données  nécessaires pour répondre à chacune des interfaces de service. Cela représente beaucoup de travail (même si les interfaces sont réutilisables) et crée des problèmes de maintenance importants à l'avenir, car chaque connexion est de type point à point.

En théorie, un  ESB  centralisé offre la possibilité de normaliser, et de simplifier considérablement, la communication, la  messagerie et l'intégration entre les services de l'entreprise. Les coûts en matériel et logiciel peuvent être partagés, en approvisionnant les serveurs selon les besoins de l'utilisation combinée, fournissant ainsi une solution centralisée évolutive.  Une seule équipe de spécialistes peut être chargée (et, si nécessaire, formée) de développer et de maintenir les intégrations.

applications logicielles  se connectent simplement (« parlent ») à l' ESB  et laissent à l' ESB  le soin de transformer les protocoles, d'acheminer les messages et de les transformer dans les  formats de données  requis, assurant ainsi l'interopérabilité nécessaire à l'exécution des transactions. L'approche architecturale du  bus de service d'entreprise  prend en charge des scénarios  d'intégration d'applications,  d'intégration de données et  d'automatisation des processus métier par  l'orchestration  de service .  Les développeurs peuvent ainsi consacrer beaucoup moins de temps à l'intégration et beaucoup  plus de temps à la distribution et à  l'amélioration de leurs applications. Et la possibilité de réutiliser ces intégrations d'un projet à l'autre offrait la possibilité de réaliser des gains de productivité et des économies encore plus importants en aval.

Mais si les  ESB  ont été déployés avec succès dans de nombreuses organisations, dans beaucoup d'autres, les  ESB  ont fini par être considérés comme un goulot d'étranglement. Le fait d'apporter des modifications ou des améliorations à une intégration pourrait déstabiliser les  autres utilisateurs de cette même intégration. Les mises à jour du  logiciel intermédiaire  ESB  ont souvent eu un impact sur les intégrations existantes,  de sorte que des tests importants ont été nécessaires pour effectuer toute mise à jour. Comme l' ESB  était géré de manière centralisée, les équipes chargées des applications se sont vite retrouvées à attendre leurs intégrations. À mesure que le volume d'intégrations augmentait, l'implémentation de la haute disponibilité et de la reprise après incident pour les serveurs  ESB  devenait plus coûteuse. Et comme il s'agit d'un projet inter-entreprise, l' ESB  s'est avéré difficile de le financer, ce qui a rendu ces problèmes techniques encore plus difficiles à résoudre.

En fin de compte, les défis liés à la maintenance, à la mise à jour et à la mise à l'échelle d'un  ESB  centralisé se sont révélés si écrasants et si coûteux que l' ESB  a souvent retardé les gains de productivité qu'il était censé produire, tout comme l'architecture  SOA, frustrant ainsi les équipes des secteurs d'activité qui s'attendaient à un rythme d'innovation plus soutenu.

Pour en savoir plus sur la montée et la chute  d'EBS, lisez « Le destin  d'EBS. »

L'architecture de microservices permet de diviser les éléments internes d'une application unique en petits morceaux qui peuvent être modifiés, mis à l'échelle et administrés de manière indépendante. Les microservices  sont apparus et ont pris de l'ampleur avec l'essor de la virtualisation, du cloud computing, des pratiques de développement Agile et du DevOps. Dans ces contextes, les  microservices  offrent les avantages suivants :

• Amélioration de l'agilité et de la productivité des développeurs  en leur permettant d'intégrer de nouvelles technologies dans une partie de l'application sans toucher ou « rattraper » le reste de l'application. 
• Une  évolutivité plus simple et plus rentable en permettant à chaque composant d'être mis à l'échelle indépendamment des autres, afin de répondre le plus rapidement possible aux demandes de charge de travail et d'utiliser les ressources informatiques le plus efficacement possible.
• Une plus grande résilience,  car la défaillance d'un composant n'a pas d'incidence sur les autres, et chaque  microservice  peut répondre à ses propres exigences de disponibilité sans que les autres composants soient soumis à une exigence de « plus grande disponibilité commune ».

La même granularité que les  microservices  apportent à la conception des applications peut être apportée à l'intégration, avec des avantages similaires. C'est l'idée qui sous-tend l'intégration Agile, qui décompose l'ESB  en composants d'intégration fins et décentralisés, sans interdépendances, que les équipes d'application individuelles peuvent posséder et gérer elles-mêmes.

Pour en savoir plus sur tout ce qui concerne les  microservices, consultez « Microservices : guide complet », « SOA vs. les microservices : Quelle différence ? » et visionnez la vidéo de Dan Bettinger , « Que sont les   Microservice ? » :

Alors que votre entreprise fait évoluer son infrastructure informatique vers une approche de cloud hybride , il est fort probable que vous transformerez diverses charges de travail, y compris celles basées sur des modèles SOA et ESB, en modèles de déploiement plus légers et plus souples.

Ces transformations ne sont  qu'une partie  de la modernisation des applications, car la demande d'une meilleure expérience client et d'un plus grand nombre d'applications a un impact sur les opérations business et informatiques. Lorsqu'il s'agit de répondre à cette demande, l'évolution vers une automatisation plus large est également utile. L'idéal serait de commencer par de petits projets au succès quantifiable, que vous pourrez ensuite adapter et optimiser pour d'autres processus et dans d'autres parties de votre organisation.

En travaillant avec IBM, vous avez accès à des fonctionnalités d'automatisation optimisées par l'IA, y compris des flux de travail préconfigurés, pour accélérer l'innovation en rendant chaque processus plus intelligent.

Pour aller plus loin :

• Découvrez comment vous pouvez exploiter, étendre et moderniser vos investissements en logiciel intermédiaire avec IBM Cloud Pak for Integration, une solution d'intégration hybride qui fournit un cycle de vie automatisé et en boucle fermée pour plusieurs styles d'intégration d'entreprise.
• Découvrez comment vous pouvez connecter toutes vos applications et données dans plusieurs clouds  privés  et publics pour des expériences client personnalisées en consultant les solutions d'intégration IBM Cloud.
• Obtenez le document IBM Application Modernization Field Guide pour apprendre comment accélérer la modernisation, améliorer la productivité des développeurs et renforcer l'efficacité opérationnelle et la standardisation.
• Réalisez notre évaluation de la maturité de l'intégration pour évaluer votre niveau de maturité de l'intégration à  travers des dimensions critiques et découvrez les actions que vous pouvez entreprendre pour atteindre le  niveau suivant.
• Téléchargez notre guide d'intégration Agile qui explore les mérites d'une approche d'intégration des solutions basée sur les conteneurs, décentralisée et en adéquation avec les microservices. 
• Découvrez les cinq « indispensables » pour le succès de l'automatisation (lien externe à ibm.com)  dans ce rapport HFS Research.

Commencez dès aujourd'hui avec un compte IBM Cloud.