2009-07-30 5 views
2

Ich mag diesesVerbrauchen WCF-Dienst mit demselben Namen und demselben Ziel-Namensraum von BizTalk

Namespace Company.BO.Contracts ein WCF-Dienst Service-Szenario habe {

public interface ITypeService { } 

public partial interface IType1Services : ITypeService 
{ 
    [OperationContract()] 
    Type1 GetType1(System.Int32 idValue); 

    [OperationContract()] 
    Type1 Save(Type1 myType1, System.Int32 changeUser); 
} 

public partial interface IType2Services : ITypeService 
{ 
    [OperationContract()] 
    Type2 GetType2(System.Int32 idValue); 

    [OperationContract()] 
    Type2 Save(Type2 type2, System.Int32 changeUser); 
} 

}

Namespace Company. ContractFulfillment {

public class Type1Services : IType1Services 
{ 
    public MyType1 GetType1(System.Int32 idValue) 
    { 
     return new Type1(); 
    } 
} 

public class Type2Services : IType2Services 
{ 
    public Type2 GetType2(System.Int32 idValue) 
    { 
     return new Type2(); 
    } 
} 

}

Wenn ich den obigen Code als WCF-Dienst verfügbar mache, ist BizTalk nicht in der Lage, zwischen Type1.Save() und Type2.Save() zu unterscheiden. Gibt es einen Weg, den Service nicht zu modifizieren, weil der Service Teil eines Frameworks ist und mehr Änderungen an anderen abhängigen Orten erfordert?

Für andere Clients als BizTalk ist die Servicezugriffsebene in die Typbibliothek (type1, typ2 usw.) eingeschlossen, und Clients greifen auf diese Typbibliothek als normale Klassenbibliothek zu.

+0

Können Sie genauer angeben, was Sie meinen, wenn Sie sagen: "BizTalk kann nicht zwischen Type1.Save() und Type2.Save()" unterscheiden? Was passiert auch, wenn Sie versuchen, es mit einem WCF-Client ("Add Service Reference") zu verwenden? –

Antwort

0

Können Sie ein [ServiceContractAttribute (Namespace = "http://company.com/services/type1/")] auf die Schnittstelle Typ 1 setzen? Verwenden Sie für jeden Servicevertrag einen anderen Namespace, da es sich um unterschiedliche Verträge handelt.

+0

2. - Unterschiedliche Namespaces für jeden Servicevertrag sind nicht möglich, da diese aus einem In-Place-Framework stammen; Durch das Ändern des Namespace werden andere Apps, die die Dienste in Anspruch nehmen, minimiert. Das BizTalk ist die neueste Initiative zur Integration mit einem anderen relativ neuen System. 1st - Alle Typen (type1 ... n) sind mit Services.Core-Namespace und spezifischen Namen wie folgt verfügbar. [ServiceContract (Namespace = "http://company.com/services/core", Name = "Type1 Interface")] – Muralidhar

0

Sie könnten einen WCF-Dienst erstellen, die Sie zwischen dem Rahmen platziert und Biztalk

Implement Type1.Save() als Type1.SaveType1() in diesem neuen Service.

Nicht besonders elegant, aber es würde funktionieren.

+0

Tatsächlich machen wir das gleiche. Aber ich denke, das ist überflüssig. Ich fand eine andere Implementierung mit benutzerdefinierten Pipelines, die es mir ermöglichen, die Quell- und Ziel-Namespaces (mit einigen .net Assembly mit 2 Eigenschaften für Quell-und Ziel Namespaces) zu ändern und sie auf die Schema-und Port-Konfiguration. Aber wenn mehr Datenkontrakte ausgesetzt sind und die Nr. von Orchestrierungen wachsen hoch, das ist schwer zu pflegen und zwicken, wenn etwas schief geht (hoher Wartungsaspekt!). – Muralidhar