2009-05-14 26 views
0

Je suis en train d'implémenter un service WCF (contrat A) qui finira par effectuer des appels à un service autonome (contrat B) hébergé par le client. Au moment de la conception, lorsque le client interroge le WSDL de mon service pour créer son proxy, je souhaite inclure le WSDL pour le contrat B afin que le client puisse créer son service. Malheureusement, je n'arrive pas à comprendre comment injecter le contrat B dans le WSDL émis par le service. Comme le contrat est une interface et qu'il ne possède pas l'attribut [DataContract], je ne peux pas l'ajouter en tant que type connu. Existe-t-il un autre moyen d'injecter un contrat dans WSDL émis?Injection d'un contrat non lié dans le WSDL créé par le fournisseur MEX de WCF

Voici un exemple:

[ServiceContract] 
public interface IServerService 
{ 
    [OperationContract] 
    void GiveTheServerMyServiceUri(string uri); 

    [OperationContract] 
    void TellAllClientsSomething(string message); 
} 

// THIS IS THE INTERFACE I WANT TO INCLUDE IN THE WSDL 
[ServiceContract] 
public interface IClientService 
{ 
    [OperationContract] 
    void ReceiveMessageFromServer(string message); 
} 

public class ServerService : IServerService 
{ 
    private List<string> knownClients; 

    public void GiveTheServerMyServiceUri(string uri) 
    { 
    knownClients.Add(uri); 
    } 

    public void TellAllClientsSomething(string message) 
    { 
    foreach (string clientUri in knownClients) 
    { 
     // 1. Create instance of ClientServiceProxy using client's uri 
     // 2. Call proxy.ReceiveMessageFromServer(message) 
    } 
    } 
} 

Au début, il semble que ce soit un exemple de manuel d'un contrat duplex. Cependant, pour cette application particulière, pour une variété de raisons, j'ai besoin d'un peu plus de séparation entre client et serveur donc j'espérais juste donner au client une interface à implémenter (via le WSDL), laisser héberger son propre service, puis Dites-moi simplement l'URL du service.

Répondre

1

Je ne vois pas que cela a du sens. À moins que votre service n'implémente le contrat de service de l'autre service, ne le faites pas. D'autre part, votre service peut mettre en œuvre l'autre contrat de service et devenir un client de l'autre service. Par contre, Il peut ensuite déléguer des appels à l'autre contrat de service à cet autre service.


J'ai juste essayé ceci pour m'assurer. J'ai créé un nouveau projet de bibliothèque de service WCF. Cela a créé un Service1 implémentant IService1, avec deux opérations. J'ai modifié l'attribut [ServiceContract] pour utiliser un espace de noms spécifique (http://localhost/service1). J'ai ensuite ajouté un nouveau service, ce qui m'a donné Service2, implémentant IService2, avec une seule opération (DoWork). J'ai mis à jour le [ServiceContract] pour utiliser http://localhost/service2/. J'ai ensuite mis à jour Service1 pour implémenter IService2 ainsi que IService1 et pour déléguer IService2.DoWork au service Service2

J'ai également dû ajouter un nouveau point de terminaison implémentant IService2, et j'ai dû spécifier une adresse relative, afin que les deux ne soient pas en conflit (puisqu'ils étaient dans le même projet). Voici le résultat:

using System; 

namespace WcfServiceLibrary1 
{ 
    public class Service1 : IService1, IService2 
    { 
     public string GetData(int value) 
     { 
      return string.Format("You entered: {0}", value); 
     } 

     public CompositeType GetDataUsingDataContract(CompositeType composite) 
     { 
      if (composite.BoolValue) 
      { 
       composite.StringValue += "Suffix"; 
      } 
      return composite; 
     } 

     public void DoWork() 
     { 
      Service2Reference.IService2 svc = null; 
      try 
      { 
       svc = new Service2Reference.Service2Client(); 
       svc.DoWork(); 
      } 
      finally 
      { 
       if (svc != null) 
       { 
        ((IDisposable)svc).Dispose(); 
       } 
      } 
     } 
    } 
}