Enterprise Service Bus et Architecture orientée aux service

Qu'est-ce que c'est?

Un bus de services d’entreprise (An enterprise service bus ou ESB) et une architecture orientée services (SOA) sont les piliers de l’intégration d’entreprise et des modèles d’intégration d’entreprise. Comme son nom l’indique, nous associons normalement la technologie à des implémentations de grandes entreprises de processus et de services d’intégration. Historiquement, ce sont aussi des technologies et des approches que nous associons à des coûts élevés en termes de licences ou abonnements et de leurs services associés.

La prévalence des normes à ce sujet a cependant conduit au développement d’un certain nombre de technologies open source qui réduisent considérablement les coûts associés aux licences et aux abonnements. La fondation Apache a un certain nombre de projets dans son portefeuille. Il existe également de nombreux autres projets soutenus par des fournisseurs et par la communauté. Cela a considérablement réduit les barrières à l’entrée pour les petites organisations souhaitant déployer cette fonctionnalité et cette technologie.

Proposition de valeur de la capacité

Nous associons généralement un ESB aux modèles d’intégration d’entreprise classiques. La plupart des produits et projets sont conçus pour y être conformes. Cela permet une approche standard de la livraison dans toutes les technologies. Cela devrait signifier que les solutions sont relativement portables à travers les technologies. Ce n’est pas toujours nécessairement le cas lors de la mise en œuvre, mais il est courant que de nombreux artefacts d’une implémentation soient réutilisables.

La valeur d’un ESB réside dans l’approche normative de la mise en œuvre. Cela permet d’abstraire l’architecture et la conception de la solution de l’implémentation technique. Les architectes peuvent se concentrer sur la conception de solutions en termes d’un ensemble standard de modèles d’intégration. L’architecture orientée services est bien comprise sur le marché, ce qui signifie également que les ressources sont généralement facilement disponibles sur le marché. Étant donné que nous associons ces implémentations aux déploiements de grandes entreprises, nous les associons également à des services hautement robustes, critiques et évolutifs.

L’avènement des technologies open source dans cet espace signifie que les petites organisations peuvent tirer parti de cette approche d’intégration et de la robustesse et l’évolutivité associées d’un ESB.

Les cas d'utilisation

Nous voyons généralement des ESB employés dans des organisations gérant des intégrations de nature hautement critique. Les organisations qui se connectent à des systèmes anciens, des services SOAP, des structures de données XML, des processus asynchrones, un transfert de fichiers géré ou qui ont besoin d’une livraison de messages garantie s’appuient souvent sur un ESB pour ces capacités. Les cas d’utilisation qui impliquent d’exposer des services discrets dans une organisation dans le cadre d’un catalogue de services global bénéficient grandement de cette approche.

Nous voyons souvent la nouvelle génération de projets ESB open source provenant d’Apache Foundation ou soutenus par des fournisseurs utilisés dans des projets de migration. Les entreprises dont les coûts permanents sont élevés associés à des services d’intégration très stables transfèrent activement leurs services vers des plateformes à un coût plus bas. Avec l’avènement de l’IPaaS et des ESB à un coût plus bas avec des racines open source, la proposition de valeur pour les implémentations ESB coûteuses s’est rapidement érodée.

En tant que partenaire WSO2, nous voyons souvent le WSO2 ESB associé au produit leader de gestion des APIs de WSO2 comme une alternative aux approches plus coûteuses du marché. Nous avons un certain nombre de clients qui profitent de cette approche robuste et hautement évolutive à un coût nettement inférieur. Dans de nombreux cas, nous prenons souvent en charge l’ensemble de la solution pour eux et occultons la complexité inhérente à ces types de déploiement. Nous appelons cela une offre d’intégration en tant que service.

Les meilleures pratiques de mise en œuvre

En termes de mise en œuvre, il existe une voie très bien tracée en ce qui concerne la livraison d’un ESB. La collecte des exigences, l’établissement de l’architecture, de l’architecture / des modèles / des schémas de données, des règles d’affaires, des mappages de données, etc. sont des activités préalables communes à tous les projets d’intégration. Un domaine dans lequel nous pouvons voir une différence d’approche concerne les rôles au sein d’un projet. Il est courant que l’approche de la solution ou le modèle d’intégration à déployer soit décidé par une personne autre que le développeur qui fournit l’intégration. Nous pouvons également voir une ségrégation dans les rôles en ce qui concerne la livraison de certains des artefacts d’intégration, par exemple XSLT pour la transformation de données sur des schémas XML peut être effectué par un développeur XML dédié.

L’approche, le degré de séparation des rôles, etc. Dépendent généralement de la taille ou de l’échelle de la mise en œuvre et de l’organisation dans laquelle elle est mise en œuvre. Certaines organisations, par exemple, ont déjà un rôle de gardien XML défini ou des développeurs XML au sein de l’organisation qui ont défini des schémas et créeront XSLT pour les modèles d’intégration déployés. Ils géreront également ces artefacts en continu. Dans d’autres organisations plus petites, le développeur d’intégration fournira la solution ou le processus complet de bout en bout. Ce qu’un acheteur devrait trouver, c’est que l’approche de la livraison est assez cohérente entre les produits de l’espace ESB.

Comment ces technologies se différencient-elles?

Les acheteurs et les utilisateurs de la technologie ESB doivent trouver ou rechercher un support cohérent pour les modèles d’intégration d’entreprise bien définis dans les produits qu’ils évaluent. Un échec à soutenir ces modèles remettra généralement en question la proposition de valeur de la technologie. Certains fournisseurs sur le marché ont fait beaucoup de travail en termes d’interface utilisateur pour masquer la complexité des modèles. Certains ont même complètement changé la façon dont ils utilisent le bus de service et ont fait la transition de leurs produits vers des technologies de style IPaaS. Dans ce cas, ils s’appuient généralement sur la robustesse de la technologie comme base de leur pile.

L’expérience utilisateur, la couverture des connecteurs SaaS et les connecteurs technologiques basés sur le cloud sont des domaines clés de différenciation. Les compartiments Amazon S3, le stockage Azure Blob, Amazon SQL, Google Pub / Sub, Apache Kafka sont tous des exemples de technologies de connecteur dans lesquelles les produits ESB peuvent chercher à se différencier. Dans le monde d’Azure, le bus de services n’est qu’un composant d’Azure Integration Services. C’est une base pour fournir une livraison de messages garantie prise en charge par des sessions pour grouper les messages associés. Les modèles d’intégration d’entreprise ne sont plus vraiment pertinents dans une implémentation d’intégration basée sur Azure.

L’expérience utilisateur et la flexibilité des options de déploiement sont un autre domaine clé. WSO2, par exemple, a déployé beaucoup d’efforts pour pouvoir déployer la fonctionnalité ESB en tant que microservices conteneurisés. Il en va de même pour Tibco sur le marché. C’est là que nous pouvons voir les fournisseurs s’adapter aux nouveaux styles de déploiement de la technologie d’intégration.

Les considérations

L’adoption d’un ESB doit être ancrée dans l’adoption d’une approche orientée services. Si l’architecture s’intéresse peu aux modèles d’intégration d’entreprise (EIP), le choix de cette technologie sera discutable. L’exception sera là où la technologie s’est adaptée d’une façon ou d’une autre pour apporter des avantages qui rendent les EIP non pertinents dans le déploiement. Les organisations qui adoptent un ESB devraient rechercher la robustesse inhérente à l’approche et être disposées à adopter la discipline qui va avec ou à engager une organisation qui peut fournir la discipline comme Chakray.

Les organisations qui sont nouvelles dans le domaine de l’intégration ou qui ont une première approche cloud / SaaS peuvent trouver qu’un ESB représente une surcharge inutile en termes d’approche d’intégration. Pour ces organisations, une solution de style IPaaS peut être une meilleure technologie d’intégration à déployer et plus facile à adopter. Pour de nombreuses organisations, confrontées à des processus asynchrones ou à exécution longue, l’exigence d’une banque de messages fait de la technologie une partie inhérente de leurs besoins architecturaux.

Les technologies ESB open source les plus accessibles, qu’elles soient ouvertes ou disponibles avec un abonnement au support fournisseur, sont désormais presque la voie de fait pour le déploiement d’ESB. Ignorer cette option est généralement considéré comme ignorant la valeur de vos opérations informatiques.

Comment Chakray peut vous aider?

Chakray a été fondé à l’origine sur son expertise des technologies d’intégration open source. Si une organisation recherche une technologie ESB, nous proposerons une solution ESB open source ou basée sur la consommation soutenue par le commerce. Nous considérons ce noyau comme nos valeurs en termes de création de valeur pour nos clients. Cela ne signifie pas que nous ne déployons pas au-dessus d’autres technologies de fournisseurs propriétaires ou que nous recommandons un ESB open source où une technologie IPaaS est plus appropriée. Notre entreprise repose sur le principe de faire les bonnes choses pour nos clients et nous aidons nos clients à faire des choix d’intégration pragmatiques.