Découverte de service Web dans WCF: Ws-Discovery ou UDDI?
Question
Je connais la distinction entre UDDI et Ws-Discovery (emplacement bien connu pour rechercher un service ou une émission). Mais ma question est la suivante: quel est le moyen le plus simple de découvrir un service Web dans WCF? Par plus simple, je veux dire ce qui est déjà implémenté dans WCF et peut être utilisé maintenant? Je n'ai vu aucune implémentation intégrée dans WCF pour UDDI ou Ws-Discovery.
Avez-vous un lien ou une expérience à partager à propos de ces deux protocoles dans WCF?
MISE À JOUR
Maintenant, je pense à trois solutions: attendre la découverte WS sur .NET 4.0 ou peut-être créer ma propre liaison de découverte avec la liaison Peer to Peer fournie par WCF. De cette façon, je peux diffuser une demande. Ou en utilisant la mise en oeuvre fournie par le lien de eed3si9n.
Je pense que je ferai une interface de passerelle pour modifier facilement cette dernière implémentation.
La solution
.NET 4.0 aura WS-Discovery. Voir Améliorations de la messagerie dans .NET 4.0: (Découverte, partie I) Utilisation de WS-Discovery dans WCF 4.0 . Dans l’intervalle, Claudio Masieri a fourni une implémentation. Voir WS-Discovery pour WCF .
Il existe également une implémentation de découverte personnalisée réalisée de la même manière que UDDI. Voir Découverte du service de communication Windows .
Imaginez que vous avez 200 clients utilisant votre service funky Wcf. Ils seraient tous avoir dans leur fichier de configuration une section comme celui-ci:
<client>
<endpoint configurationName="default"
address="http://localhost/servicemodelsamples/service.svc"
binding="wsHttpBinding"
bindingConfiguration="Binding1"
contract="IDataContractCalculator" />
</client>
<bindings>
<wsHttpBinding>
<binding configurationName="Binding1" />
</wsHttpBinding>
</bindings>
Maintenant, vous décidez de changer le point final (côté serveur) avec un nouveau qui utilise SSL pour des raisons de sécurité. Comment mettez-vous à jour vos clients? Vous pouvez voir rapidement que cela peut devenir fastidieux. Donc, l'idée que je veux détailler voici pour mettre en œuvre une découverte service similaire à ce que fait UDDI et d'utiliser un résolveur de métadonnées pour obtenir le configuration hors service dans afin de créer dynamiquement un proxy permettant au client de discuter avec le service.
Cette personne a les mêmes préoccupations que vous et semble avoir une solution satisfaisante.
Autres conseils
UDDI fournit un registre central pour stocker des informations sur disponible prestations de service. Il fournit un catalogue où les consommateurs peuvent trouver des services qui répondent leurs besoins. Comme un annuaire répertoire d'informations permettent les consommateurs à trouver des services par leur nom, adresse, contrat, catégorie ou par autre informations. UDDI peut être pensé comme DNS des services Web.
D'autre part, WS-Discovery fournit un protocole à découvrir services qui vont et viennent à partir d'un réseau. En tant que service rejoint le réseau, il informe ses pairs de son arrivée en diffusant un bonjour message; De même, lorsque les services chutent hors du réseau, ils multicast un Bye message. WS-Discovery ne compte pas sur un seul noeud pour héberger des informations à propos de tous les services disponibles comme UDDI Est-ce que. Au contraire, chaque nœud avance informations sur les services disponibles de manière ad hoc. Cela réduit la quantité d'infrastructure de réseau nécessaire pour découvrir les services et facilite l'amorçage.
Citation tirée de: http://travisspencer.com/blog/2007/09/ post.html
Voici une bonne liste de propriétés: http://laflour.spaces.live.com/Blog/cns! 7575E2FFC19135B4! 728.entry
jUDDI a un client .NET que vous pouvez utiliser. Cela simplifie grandement un certain nombre de choses pour travailler avec UDDI.
Par expérience, il n'y a que deux ou trois implémentations fonctionnelles de WS-Discovery.
- Apache CXF, mais uniquement en dehors d'un conteneur
- Celui-ci: https://code.google.com/p/java- ws-discovery / qui ne fonctionne pas dans Jboss et qui n'est pas maintenu
- Microsoft .NET 4.0ish
UDDI auquel vous pouvez accéder depuis n'importe quoi. Il existe de nombreuses implémentations client et serveur. (Seuls les éléments de la version 3 sont répertoriés ici)
- registre IBM WS
- Apache jUDDI
- Microsoft UDDI v3 avec Biztalk (gratuit avec serveur 2008)
- HP SOA / Systinet ou ce que l'on appelle maintenant
- WSO2 a quelque chose
- ebXML a une sorte de pont ou d’adaptateur
Il existe même un point de terminaison REST pour UDDI3 (jUDDI 3.2, XML ou JSON), ce qui ouvre de nombreuses possibilités.
De plus, les données partageables avec WS-Discovery sont quelque peu limitées par rapport aux données pratiquement illimitées que vous pouvez attacher à UDDI.
C'est juste mes 2 centimes.