Le service WCF consommateur de client nécessite-t-il une définition d'interface?

Question

J'ai parcouru le livre «Learning WCF» en essayant de créer et d'utiliser les services Web de la WCF. La première partie du livre guide le lecteur à travers la création puis la consommation d'un simple service web "Hello World". Le problème que je rencontre est que l'application cliente ne semble pas connaître la structure de l'interface WCF lorsqu'elle l'appelle. Comment cela peut-il être nécessaire si un service Web peut être appelé à partir d'un certain nombre de langages de programmation?

J'ai énuméré le code exemple pertinent ci-dessous ...

Voici le code pour l'interface

[ServiceContract(Namespace="http: //www.thatindigogirl.com/samples/2006/06")] 
public interface IHelloIndigoService 
{ 
    [OperationContract] 
    string HelloIndigo(); 
} 

Voici le code pour le service qui héberge le service Web

static void Main(string[] args) 
{ 
    using (ServiceHost host = new ServiceHost(typeof(HelloIndigo.HelloIndigoService) , 
    new Uri("http: //localhost: 8000/HelloIndigo"))) 
    { 
    host. AddServiceEndpoint(typeof(HelloIndigo. IHelloIndigoService) , 
     new BasicHttpBinding(), "HelloIndigoService"); 
    host. Open(); 
    Console. WriteLine("Press <ENTER> to terminate the service host") ; 
    Console. ReadLine(); 
    } 
} 

Voici le code du client ap p qui consomme le service WCF C'est là que je suis confus. Étant donné que cette application client peut être n'importe quel langage capable d'appeler un service Web, pourquoi est-il nécessaire de connaître la définition de l'interface?

using System. ServiceModel; 
[ServiceContract(Namespace = "http: //www.thatindigogirl.com/samples/2006/06")] 
public interface IHelloIndigoService 
{ 
    [OperationContract] 
    string HelloIndigo(); 
} 

static void Main(string[ ] args) 
{ 
EndpointAddress ep = new 
    EndpointAddress("http: //localhost: 8000/HelloIndigo/HelloIndigoService") ; 
IHelloIndigoService proxy = ChannelFactory<IHelloIndigoService>. 
    CreateChannel(new BasicHttpBinding(), ep); 

string s = proxy. HelloIndigo(); 
Console. WriteLine(s) ; 
Console. WriteLine("Press <ENTER> to terminate Client.") ; 
Console. ReadLine(); 
} 

Est-ce que je manque un point important ici? Peut-être que ma compréhension de ce qui est nécessaire pour consommer un réseau fait défaut. Mon but est de pouvoir utiliser WCF pour créer un service .NET pouvant être appelé depuis n'importe quel langage ou environnement de programmation.

Quelqu'un pourrait-il suggérer un bon didacticiel sur la création de services Web «consommables multiplateformes» à partir de .NET? Merci!

Answer 1

Cette approche est basée sur une interface partagée (le livre ne partage pas l'interface mais utilise une copie locale) et est appliquée avec succès dans un environnement où le client et le serveur sont écrits dans .NET. Cette approche n'est pas utilisable pour l'interopérabilité ou les solutions SOA.

D'autres approches utilisent des métadonnées exposées par le service. Les métadonnées sont définies en tant que document WSDL plus plusieurs documents XSD. Ces fichiers de métadonnées permettent de fournir des informations sur votre service aux développeurs .NET et non .NET. Le livre contient la définition du point de terminaison des métadonnées (mex), donc vous lirez certainement à ce sujet. L'utilisation de métadonnées dans .NET signifie la création d'un proxy de service. Vous pouvez le faire automatiquement en utilisant la référence de service Ajout Visual Studio ou l'utilitaire de ligne de commande svcutil.exe. Quoi qu'il en soit, le code proxy généré contiendra probablement toujours l'interface créée à partir des métadonnées. Il est utilisé pour créer une abstraction transparente du service pour le client.

Answer 2

Chaque service WCF est composé de

• A - Adresse
• B - la liaison
• C - contrat

Le contrat est déclaré à l'aide d'une interface sur le côté serveur. Il déclare quelles méthodes sont disponibles pour le client. Si vous utilisez une liaison http, vous pouvez appeler une opération de service en émettant une requête http (en utilisant un client http dans n'importe quelle bibliothèque ou langue - ou même un navigateur Web) pointé à la bonne adresse. Ainsi, le client n'a besoin d'aucune référence d'interface. Il suffit de suivre le ABC du service.

Here est un joli blog sur l'interopérabilité WCF et Java.

Answer 3

Pour répondre à votre question sur la façon de développer des services Web «consommables multiplateformes», pensez à l'approche REST. Faire des services web de style REST les rend vraiment indépendants de la plate-forme qui les consomme. Autrement dit, ils utilisent les protocoles HTTP déjà bien établis que tout ce que supporte: les méthodes HTTP et GET. Vous pouvez alors avoir une application Java simplement faire des appels POST à ​​vos services WCF avec votre propre contenu XML personnalisé dans le payload sans avoir à manipuler des choses plus complexes comme faire des wrappers SOAP et autres. Consultez l'article de Rob Bagby sur REST:

http://www.robbagby.com/rest/rest-in-wcf-part-i-rest-overview/

Answer 4

« L'interface » ne signifie pas un fichier d'interface .NET, cela signifie que l'interface de programmation plus générale - un ensemble d'objets ayant des propriétés et méthodes avec des paramètres . C'est ce qu'on appelle le contrat de service. La raison pour laquelle le client et le service ont besoin de partager (c'est-à-dire connaître l'interface) est simple quand on y pense: si le client ne connaît pas l'interface, comment sait-on quelles sont les opérations disponibles? à quoi devraient ressembler les objets requête/réponse attendus?