Le partage d'un projet contenant l'interface wcf et les contrats de données et leur utilisation via ChannelFactory pour consommer le service est-il conforme aux principes SOA ?
Mon architecte me conseille de générer un proxy à l'aide de l'option Ajouter une référence de service.
Je suppose que cela dépend de certains éléments : votre infrastructure, vos politiques de sécurité, votre gouvernance, etc.
Nous concevons nos WSDL (contrats de services et de messages) et nos schémas XML (contrats de données), puis nous utilisons svcutil.exe* pour générer un proxy. À ce stade, nous disposons d'un code que nous pouvons utiliser pour consommer ou mettre en place un service. Bien sûr, je ne parle que du code, le fichier output.config sera modifié avec les comportements, les liaisons et les points de terminaison appropriés au fur et à mesure qu'ils seront décidés.
Une fois le service mis en place, il est dirigé par une passerelle XML. À ce stade, nous pouvons commencer à tester les services en utilisant la fonction "Add Service Reference...". Si vous cherchez simplement à gagner du temps et à remettre à quelqu'un d'autre votre proxy pré-généré ou si vos WSDL ne sont pas exposés (car ils se trouvent derrière une passerelle XML qui ne les répercute pas), alors ce que vous faites semble correct.
Sinon, je m'attendrais à ce que les consommateurs soient en mesure de "Ajouter une référence de service..." et de générer leurs propres clients.
*Les applications basées sur Java utilisent autre chose (WSDL2Java/ClientGen/outil IDE intégré).
Le partage d'interfaces de services préemballées avec des contrats de données n'est pas contraire aux principes de l'architecture orientée services (SOA) tant que les services consommateurs ne sont pas censés les utiliser. C'est exactement ce qui permet aux clients potentiels d'accélérer le développement par rapport à un service tiers existant ou de commencer le développement par rapport à un service qui n'a pas encore été construit. Fournir des interfaces/contrats de données sous forme de code sera moins ambigu que de décrire ces choses par le biais de la documentation uniquement (bien sûr, ils peuvent ne pas être utiles si le client utilise un langage de programmation différent).
Cependant, si une sorte d'implémentation pré-packagée de l'interface du service est fournie dans le paquetage partagé, et que cette implémentation doit être utilisée pour utiliser le service avec succès, cela irait à l'encontre des principes de l'architecture orientée services, à moins qu'une implémentation ne soit écrite pour tous les types de clients. Cependant, en étant pragmatique, cela peut être une bonne idée pour que les clients puissent être plus souplement couplés contre des choses telles que le choix du transport, les changements de contrat de service et les versions de service.
Je vous recommande d'utiliser ChannelFactory (à partir d'un client Dotnet, bien sûr), que vous utilisiez les services via un projet ou une dll d'interfaces/datacontrats pré-packagés partagés, ou que vous génériez votre propre proxy (via 'Add Service Reference' ou 'svcutil.exe'). Cela vous permettra de coder par rapport à l'interface du service et, par conséquent, votre client sera beaucoup plus facile à utiliser des concepts tels que l'injection de dépendances pour le stubbing, les tests, etc.
Les deux méthodes de génération d'un proxy sont valables, tout dépend du degré de contrôle que vous souhaitez avoir sur le proxy, et si vous possédez les deux côtés du code. Une troisième option existe également, vous pouvez créer à la main votre propre proxy. Laissez-moi vous expliquer :
Dans l'architecture SOA, nous transmettons des messages, ce qui est un paradigme différent de la transmission de pointeurs vers des objets sur un tas/une pile, qui est la norme dans le monde OO.
Ainsi, dans l'architecture SOA, le contrat (ce que vous pouvez faire) et le message (l'état sur lequel agir) sont importants et doivent être partagés avec les consommateurs du service afin qu'ils puissent tous se mettre d'accord sur le contrat ou les "règles d'engagement".
Le WS-* est un ensemble de spécifications permettant d'ajouter plus de fonctionnalités à notre appel de service (transactions distribuées, sécurité, etc.). Mais si nous faisons cela, nous devons tous nous mettre d'accord sur les règles et la saveur du type d'interaction que nous avons l'intention d'utiliser, de sorte que le service et ses clients doivent se mettre d'accord sur la manière exacte dont cela doit se produire et que cela doit être partagé.
La combinaison des définitions de contrat et des spécifications WS-* est appelée WSDL et c'est généralement ce qui est partagé entre les clients et les services, ce qui est conforme aux principes de la SOA selon lesquels nous partageons les schémas et les contrats, et non les classes, et la compatibilité est basée sur la politique (WS-*).
Ainsi, si vous utilisez channel factory, vous générez le proxy basé sur la définition de l'interface que vous avez et la configuration que vous avez mise en place à la volée, si vous utilisez add service reference, vous laissez l'IDE générer une classe proxy basée sur le WSDL du service tel qu'il existe alors.
Si vous créez vous-même le proxy, vous avez un contrôle total sur la façon dont cela se passe et vous pouvez intervenir dans la chaîne d'interception et faire des choses du côté client pour manipuler l'appel.
Cela dépend de ce que vous voulez faire.
Les normes que nous avons soigneusement examinées et adoptées au sein de mon entreprise prévoient que nous distribuons les contrats de service de deux manières. Sous la forme d'un assemblage partagé lorsqu'il est fourni aux équipes de l'entreprise, et sous la forme d'un WSDL lorsqu'il est fourni aux clients et autres tiers. Il s'agit d'une norme dont nous avons discuté avec Microsoft lors d'une révision de la conception/du processus et qui a été reconnue comme étant l'approche correcte.
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
