Pourquoi utiliser des services (REST / SOAP) au lieu d'une bibliothèque?

22

Imaginons que vous envisagiez de diviser vos applications en services. Existe-t-il de bonnes raisons d'adopter une approche SOA par rapport à la simple création d'une API de bibliothèque pouvant être chargée par les applications qui en ont besoin?

Nate Reed
la source
6
Hé Nate, lisez Google Platforms Rant de Stevey , cela donne un excellent aperçu de la question plateforme (services) vs produit (bibliothèque) ...
yannis

Réponses:

11

La différence peut être subtile entre les deux. Par exemple, dans le monde .NET, vous pouvez avoir une application qui semblerait monolithique pour un utilisateur final et qui fonctionnera sur une même machine, mais à l'intérieur, serait séparée en un tas de services WCF. Vous pouvez également avoir des architectures où les bibliothèques ne sont pas fortement liées (compléments / plugins) et suivent simplement un protocole lorsque vous vous parlez.

Si nous évitons de parler de ces cas intermédiaires et ne traitons que la bibliothèque d'API fortement liée par rapport à un service REST distinct, vous pouvez considérer les points suivants:

  1. Une API de bibliothèque est appelée sur la même machine. Les services peuvent être hébergés n'importe où et être appelés de n'importe où. Si vous comptez héberger l'application sur plusieurs machines pour des raisons de performances / évolutivité / sécurité, vous aurez probablement besoin d'utiliser des services.

  2. La situation est similaire lorsqu'il s'agit d'utiliser un service par une application déployée sur plusieurs machines. Par exemple, si vous faites une application pour une banque qui effectue des calculs financiers, une façon consiste à déployer la grande application dans son ensemble sur chaque bureau et à être obligé de faire des mises à jour de grande taille pour chaque client à chaque fois; une autre approche consisterait à héberger une partie de calcul sur des serveurs et à déployer sur les postes de travail uniquement une application légère avec seulement une interface utilisateur et un tas d'appels vers ces serveurs.

  3. Si vous hébergez un service REST, n'importe qui peut l'utiliser: un utilisateur Mac, une personne qui utilise Linux, etc. Si vous avez créé une bibliothèque C # avec Visual Studio et que vous la distribuez sous forme de DLL, oubliez les utilisateurs (clients ?) qui n'ont pas Windows.

Arseni Mourzenko
la source
9

Un autre avantage des services est que lorsque vous mettez à jour le service, il est immédiatement déployé auprès de tous les consommateurs du service. Donc, si vous corrigez un bogue ou un problème de performances, tout le monde en profite dès que le service mis à jour est mis en ligne, au lieu d'avoir à distribuer une mise à jour que les gens peuvent choisir d'ignorer.

Mike O'Connor
la source
C'est vrai, mais cela peut aussi être un inconvénient. Lorsque vous apportez une modification à un service dont dépendent plusieurs applications, vous pouvez interrompre de façon inattendue des fonctionnalités dans une ou plusieurs de ces applications. Il ne s'agit pas d'effrayer qui que ce soit loin des services, mais sachez que vous devez vous assurer que tous les consommateurs du service continuent de travailler chaque fois que vous changez de service. Encore mieux est de laisser les méthodes de service héritées une fois qu'elles ont été déployées et de créer de nouvelles méthodes lorsque vous devez modifier l'implémentation.
Lews Therin
8

Avantages de la bibliothèque:

Avantages du service:

  • Tout le monde obtient des mises à niveau immédiatement et de manière transparente (sauf si l'API versionnée est proposée)
  • Les consommateurs ne peuvent pas décompiler le code
  • Peut adapter le matériel de service séparément
  • Agnostique technologique. Avec une bibliothèque partagée, les consommateurs doivent utiliser une technologie compatible.
  • Plus sûr. Le niveau d'interface utilisateur peut appeler le service qui se trouve derrière un pare-feu au lieu d'accéder directement à la base de données.
Maison Cory
la source
Le "code natif" n'a pas vraiment de sens ici: a) un service peut également utiliser du "code natif", et b) la compilation juste à temps fournit souvent les mêmes performances que le code natif.
sleske
Point pris. Ce à quoi je fais référence lorsque je dis «code natif», c'est qu'une bibliothèque est un appel «en cours». Il n'y a pas de surcharge de couche de service (par exemple HTTP si vous effectuez un appel d'API Web)
Cory House
Oui, la surcharge d'appel devrait en effet être plus faible. J'ai pris la liberté d'éditer votre réponse, pour remplacer la mention de "code natif" par "frais généraux d'appel inférieurs". N'hésitez pas à rééditer si vous n'êtes pas d'accord :-).
sleske
Ce que j'aime ajouter, c'est l'utilisation des transactions . Il est généralement beaucoup plus difficile de faire fonctionner les transactions au-delà des frontières des services que dans une bibliothèque partagée.
c_mart
2

Une approche SOA permet aux différents services d'être hébergés et maintenus séparément. En plus du code, le déploiement d'un service particulier peut nécessiter beaucoup de configuration spéciale (mots de passe, ports, certificats, etc.). La consommation d'un service REST présente une complexité limitée qui peut être clairement documentée et facilement comprise. Il est également plus sécurisé car cela signifie que vous n'avez pas besoin d'accorder l'accès aux bases de données ou à d'autres ressources aux clients.

jiggy
la source
1

S'il y a un changement à un service SOA, alors ce service SOA devra être redéveloppé, retesté et redéployé. Toutes les applications qui utilisent ce service peuvent continuer à le faire. Un changement à une bibliothèque dans une DLL signifie que tous les consommateurs de cette bibliothèque devront être redéveloppés pour référencer cette DLL, ils devront tous être retestés et ils devront tous être redéployés. Il existe également le risque que cela ne se produise pas correctement et différentes applications auront différentes versions de la DLL. Parfois, cela peut ne pas être un problème - peut-être que chaque système devrait avoir la version de la bibliothèque qui était présente au moment du déploiement (vous avez peut-être mis à jour votre système de journalisation pour avoir de nouvelles fonctionnalités utiles - avez-vous vraimentbesoin de mettre à jour chaque système avec lui?) dans ce cas, une bibliothèque est très bien. Mais supposons que vous ayez un service pour calculer le taux d'imposition et que les lois fiscales changent. Vous ne voulez pas avoir à mettre à jour chaque système pour intégrer ce changement, il serait préférable de le faire en un seul endroit. Dans ce cas, un service est une meilleure option.

Paul T Davies
la source
0

Il y a plusieurs bonnes réponses mais je voudrais ajouter plus de choses aux réponses données:

La méthode de bibliothèque d'API est très utile lorsque vous souhaitez interagir avec des choses avec le moins de frais généraux possible. La conséquence est qu'il existe un couplage plus élevé entre l'API et les applications l'utilisant. Parfois, c'est correct pour l'application et même nécessaire, mais si vous avez un système très distribué ou si vous pensez que l'interopérabilité est un problème énorme, vous devrez peut-être aller un peu plus loin dans l'abstraction et utiliser d'autres moyens de communication. Surtout, si vous voulez avoir un système distribué, SOAP est une sorte de prochaine étape dans SOA, mais vous resterez avec la dépendance entre les unités, car elles doivent connaître les procédures des autres. REST l'amène à un nouveau niveau, en permettant à une machine d'apprendre quelque chose sur le contenu des autres services de manière unifiée.

Dans votre cas, si votre application n'est pas distribuée, je ne vois aucune raison de transformer votre application en SOA.

aagaard
la source