Rilevamento del servizio Web in WCF: Ws-Discovery o UDDI?

Question

Conosco la distinzione tra UDDI e Ws-Discovery (posizione ben nota per la ricerca di un servizio rispetto alla trasmissione). Ma la mia domanda è: qual è il modo più semplice per scoprire un servizio web in WCF? Per semplice intendo ciò che è già implementato in WCF e può essere utilizzato ora? Non ho visto alcuna implementazione integrata in WCF per UDDI o Ws-Discovery.

Hai qualche link o esperienza da condividere su questi due protocolli in WCF?

UPDATE

Ora sto pensando a tre soluzioni, in attesa di WS-discovery su .NET 4.0 o forse creare il mio binding di rilevamento con l'associazione Peer to Peer fornita da WCF. In questo modo posso trasmettere una richiesta. O usando l'implementazione fornita dal link di eed3si9n.

Penso che farò un'interfaccia gateway per cambiare facilmente quest'ultima implementazione.

Answer 1

.NET 4.0 avrà WS-Discovery. Vedi Miglioramenti della messaggistica in .NET 4.0: (Discovery Part I) Uso di WS-Discovery in WCF 4.0 . Nel frattempo, Claudio Masieri ha fornito un'implementazione. Vedi WS-Discovery per WCF .

Esiste anche un'implementazione di individuazione personalizzata eseguita in modo simile a UDDI. Vedi Windows Communication Service Discovery .

  

Immagina di avere 200 client che utilizzano   il tuo funky servizio Wcf. Vorrebbero tutti   hanno nel loro file conf una sezione come   questo:

<client>
   <endpoint configurationName="default"
               address="http://localhost/servicemodelsamples/service.svc"
               binding="wsHttpBinding"
               bindingConfiguration="Binding1"
              contract="IDataContractCalculator" />
 </client>
 <bindings>
   <wsHttpBinding>
      <binding configurationName="Binding1" />
   </wsHttpBinding>
</bindings>

  

Ora, decidi di cambiare quello esistente   endpoint (lato server) con uno nuovo   che utilizza SSL per motivi di sicurezza. Come   aggiorni i tuoi clienti? Puoi   vedere rapidamente che può diventare   noioso. Quindi l'idea che voglio dettagliare   qui è per implementare una scoperta   servizio simile a quello che fa UDDI e   utilizzare un risolutore di metadati per ottenere il file   configurazione fuori servizio dentro   per creare dinamicamente un proxy   permettendo al cliente di discutere con   il servizio.

Questa persona ha preoccupazioni simili a te e sembra avere una soluzione funzionante.

Answer 2

  

UDDI fornisce un registro centrale a   memorizzare informazioni su disponibili   Servizi. Fornisce un catalogo dove   i consumatori possono trovare servizi che soddisfano   i loro bisogni. Questo tipo di rubrica   directory di informazioni consentire   i consumatori a trovare servizi per nome,   indirizzo, contratto, categoria o da   altri dati. Si può pensare a UDDI   come DNS dei servizi Web.

     

D'altra parte, WS-Discovery   fornisce un protocollo da scoprire   servizi che vanno e vengono   da una rete. Come un servizio si unisce   la rete, ne informa i suoi pari   il suo arrivo trasmettendo un Hello   Messaggio; allo stesso modo, quando i servizi cadono   dalla rete hanno multicast un Ciao   Messaggio. WS-Discovery non si basa su   un singolo nodo per ospitare informazioni   su tutti i servizi disponibili come UDDI   lo fa. Piuttosto, ogni nodo in avanti   informazioni sui servizi disponibili   in modo ad hoc. Questo riduce   la quantità di infrastruttura di rete   necessario per scoprire servizi e   facilita il bootstrap.

Citazione da: http://travisspencer.com/blog/2007/09/ post.html

Ecco un buon elenco di proprietà: http://laflour.spaces.live.com/Blog/cns! 7575E2FFC19135B4! 728.entry

Answer 3

jUDDI ha un client .NET che puoi usare. Semplifica notevolmente una serie di cose per lavorare con UDDI.

Per esperienza, ci sono solo due o tre implementazioni funzionanti di WS-Discovery.

• Apache CXF, ma solo quando eseguito all'esterno di un contenitore
• Questo: https://code.google.com/p/java- ws-discovery / che non funziona in Jboss e non è mantenuto
• Microsoft .NET 4.0ish

UDDI a cui puoi accedere da qualsiasi cosa. Esistono molte implementazioni client e server. (Qui è elencata solo la versione 3)

• IBM WS-Registry
• Apache jUDDI
• Microsoft UDDI v3 con Biztalk (è gratuito con il server 2008)
• HP SOA / Systinet o come si chiama ora
• WSO2 ha qualcosa
• ebXML ha una sorta di bridge o adattatore

Esiste persino un endpoint REST per UDDI3 (jUDDI 3.2 ha risposte XML o JSON) che apre questo a molte più possibilità.

Inoltre, i dati condivisibili con WS-Discovery sono alquanto limitati rispetto ai dati praticamente illimitati che è possibile collegare a UDDI.

Sono solo i miei 2 centesimi.