J'ai entendu parler du NServiceBus , mais je n'ai pas vraiment compris ce que c'est. Ils prétendent être "Le bus de services open source le plus populaire pour .net".
Alors; qu'est-ce qu'un «bus de service» et quand en ai-je besoin?
J'ai entendu parler du NServiceBus , mais je n'ai pas vraiment compris ce que c'est. Ils prétendent être "Le bus de services open source le plus populaire pour .net".
Alors; qu'est-ce qu'un «bus de service» et quand en ai-je besoin?
Réponses:
Vous pouvez considérer un bus de service comme Ethernet de SOA.
Tout d'abord, il introduit un langage d'identification des choses, comme une adresse IP dans Ethernet. Ce nom n'est pas quelque chose de physique en soi.
Ensuite, vous avez quelque chose de physique impliqué sur chaque nœud, comme une file d'attente dans le cas d'un bus pour prendre en charge une communication semi-connectée, ou une carte Ethernet dans la métaphore.
Au-delà du simple physique, il y a la partie "protocole" de la communication, comme la pile OSI pour Ethernet. Avec le bus, ce sont les bibliothèques clientes utilisées par le code d'application.
En fin de compte, vous pouvez voir un bus de service comme fournissant le niveau d'abstraction supérieur suivant pour la création de systèmes distribués. Vous pouvez également l'utiliser pour la communication client-serveur afin de vous offrir une messagerie unidirectionnelle durable, ainsi que pour le serveur pour renvoyer les notifications au client.
Plus précisément, vous constaterez que NServiceBus est assez léger et facile à utiliser une fois que vous avez fait la paix avec son utilisation de la technologie de mise en file d'attente - votre choix parmi RabbitMQ, MSMQ, Regular SQL Tables, Amazon SQS, Azure Storage Queues et Azure Service Bus.
Consultez l'article Wikipédia sur Enterprise Service Bus .
Un bus de service agit comme une couche supplémentaire d'abstraction dans la quête sans fin de la mise en œuvre d'une bonne architecture orientée services. Le bus de service peut gérer certaines des tâches lourdes qui se cachent derrière une bonne architecture orientée service comme la messagerie, le routage et la coordination des services.
Si vous ne savez pas pourquoi vous voudriez quelque chose comme ça, je vous suggère de lire ce qui fait une bonne architecture orientée services. Le livre qui m'a vraiment ouvert les yeux et a prouvé la différence entre le simple fait d'avoir des services Web et une véritable architecture orientée services était l'architecture orientée services de Thomas Erl : concepts, technologie et design.
Ce terme a été introduit avec SOA qui est en quelque sorte le successeur (en tant que mot à la mode) d' EAI .
Quand en avez-vous besoin? C'est une bonne question. Cela vient avec beaucoup de complexité.
Une règle de base pourrait si cela résout plus de problèmes qu'il n'en cause.
Être sérieux si vous avez un environnement hétérogène et que vous souhaitez aligner (différentes) applications (utilisant une technologie différente) avec les processus métier. Ensuite, il pourrait être utile d'utiliser BPEL (mais cela pose des problèmes par migration) pour l' orchestration et la chorégraphie
EDIT: Ce qui n'est pas sur wikipedia, c'est la pratique: un ESB peut s'adapter à l'aide de connecteurs spéciaux, d'anciennes applications de terminal à utiliser avec Corba ou Java Enterprise, c'est-à-dire l'interopérabilité. L'inconvénient est la centaine de «standards» autour de SOAP qui ne coopèrent pas sans un effort énorme.
Vous en avez certainement besoin si vous devez interconnecter des systèmes informatiques dans les six mois suivant la fusion de 2 grandes compagnies d'assurance.