Partage un projet contenant l'interface wcf et les contrats de données et les utilise via ChannelFactory pour consommer le service par rapport aux principes SOA?WCF ChannelFactory par rapport aux principes SOA?
Mon architecte conseille de générer un proxy en utilisant l'option Ajouter une référence de service.
Je suppose que cela dépend une des choses: votre infrastructure, les politiques de sécurité, la gouvernance, etc.
Nous concevons nos WSDLs (contrats de service et de messages) et XML (contrats de données) Schemas puis utilisez svcutil.exe * pour générer un proxy. À ce moment-là, nous avons du code que nous pouvons utiliser pour consommer ou tenir un service. Bien sûr, je ne fais que parler du code, le fichier output.config sera modifié avec les comportements appropriés, les liaisons et les points de terminaison selon ce qui est décidé.
Une fois le service mis en veille, il est dirigé par une passerelle XML. À quel point nous pouvons commencer à tester les services en utilisant le 'Ajouter une référence de service ...'. Si vous cherchez simplement à gagner du temps et à remettre à quelqu'un d'autre votre proxy pré-généré ou vos WSDL ne sont pas exposés (comme ils sont derrière une passerelle XML qui ne leur fait pas écho), alors ce que vous faites semble bien . Dans le cas contraire, je m'attendrais à ce que les consommateurs puissent "Ajouter une référence de service ..." et générer leurs propres clients.
* Les applications Java utilisent autre chose (outil IDE WSDL2Java/ClientGen/intégré).
Le partage d'interfaces de service pré-packagées avec des contrats de données ne va pas à l'encontre des principes 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 à celui qui doit encore être construit. Fournir des interfaces/des contrats de données au format de code sera moins ambigu que de décrire ces choses par la documentation seulement (bien sûr, ils peuvent ne pas être utiles si le client utilise un langage de programmation différent). Toutefois, si une sorte d'implémentation pré-packagée de l'interface de service est fournie dans le package partagé et que cette implémentation doit être utilisée pour utiliser le service avec succès, cela serait contraire aux principes SOA sauf si une implémentation écrit pour tous les types de clients. Étant pragmatique cependant, cela peut être une bonne idée afin que les clients puissent être plus lâchement couplés à des choses telles que le choix de transport, les changements de contrat de service et la gestion des versions de service. Je recommande d'utiliser ChannelFactory (à partir d'un client dotnet bien sûr) si consommer les services via un projet d'interfaces/datacontracts pré-packagé partagé ou dll, ou générer votre propre proxy (via 'Add Service Reference' ou 'svcutil .EXE'). Cela vous permettra de coder par rapport à l'interface de service et donc votre client sera beaucoup plus amical à utiliser des concepts tels que l'injection de dépendance pour le stubbing, les tests, etc.
Les deux méthodes de génération d'un proxy sont valides, cela dépend de comment beaucoup 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 votre propre proxy. Permettez-moi d'expliquer plus loin:
En SOA nous passons des messages, c'est un paradigme différent pour passer des pointeurs vers des objets sur un tas/pile qui est la norme dans le monde OO.
Ainsi, dans SOA, le contrat (ce que vous pouvez faire) et le message (l'état d'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 "nous avons ici la forme la plus basique de SOA.Entrez WS- * un ensemble de spécifications pour ajouter plus de fonctionnalités à notre appel de service (transactions distribuées, sécurité etc ...) mais si nous faisons cela, nous devons tous être d'accord sur les règles et la saveur du type de l'interaction que nous avons l'intention d'utiliser, de sorte que le service et ses clients doivent se mettre d'accord exactement sur la façon dont cela doit se produire afin qu'il soit nécessaire de le partager. La combinaison des définitions de contrat et des spécifications WS- * s'appelle un WSDL et c'est généralement ce qui est partagé entre les clients et les services, c'est en accord avec les locataires SOA que nous partageons le schéma et le contrat, pas la classe, et que Compatibilité est basée sur la politique (WS- *). Donc, si vous utilisez la fabrique de canaux, vous générez le proxy en fonction de la définition de l'interface et de la configuration que vous avez configurée à la volée. Si vous utilisez la référence de service, vous laissez l'IDE générer une classe proxy basée sur le WSDL. du service tel qu'il existe alors.
Si vous fabriquez le proxy, vous avez un contrôle total sur la façon dont cela se produit et vous pouvez sauter dans la chaîne d'interception et faire des choses du côté client pour manipuler l'appel.
Dépend de ce que vous voulez faire.
Les normes que nous avons soigneusement examinées et adoptées dans mon entreprise sont que nous distribuons des contrats de service de deux façons. En tant qu'assemblage partagé lors de la livraison aux équipes au sein de l'entreprise, et en tant que WSDL lors de la fourniture aux clients et autres tiers. C'est une norme que nous avons discutée avec Microsoft lors d'un examen de conception/processus et ils ont convenu que c'était la bonne approche.