2010-12-15 4 views
0


Ich muss einen WCF-Dienst erstellen, der einige Drittanbieterdienste emuliert. Dieser Dienst hat sehr komplizierte Nachrichten und Wrapper für sie, deshalb werde ich sie in der Beschreibung vereinfachen.
Ich habe WSDL dieses Dienstes und erstellte Proxy-Klasse. Aber hier tritt das erste Problem auf: Alle Methoden im Proxy haben[System.ServiceModel.OperationContractAttribute(Action = "", ReplyAction = "*")] So ist es unmöglich, WCF-Dienst mit vielen Methoden zu erstellen: jeder für eine Methode in Proxy, weil jede Methode eindeutige Aktion haben muss. Ich denke, dass der Dienst von Drittanbietern über eine Methode verfügt, die alle Anforderungen verarbeitet. Und ich habe eine solche Methode mit benötigten KnownType-Attributen auf RequestTypeBase und RespectTypeBase erstellt. Alle Proxy-Klasse-Methoden haben einen Parameter vom Typ, abgeleitet von RequestTypeBase. Und hier ist das Hauptproblem und die Frage: Wenn WCF-Dienst versucht, Nachrichtentext zu deserialisieren, löst es eine Ausnahme besagt, dass erwartet Elementname ist "Process" (der Name meiner Mega-Methode, die alle Anfragen verarbeitet) aber vorhandene ElementName ist "RequestType1" (die Name-Klasse mit Daten, die als Parameter an die Methode "Process" übergeben werden müssen). Also wie kann ich solche Nachricht erhalten? Gibt es in WCF ein Attribut, das den Methodenname nicht als Root des Nachrichtentexts benötigt? Und ich verstehe überhaupt nicht, wofür WCF diesen MethodName braucht, wenn er schon weiß, wie die Methode heißt? Sieht nach Redundanz mit Aktionsspezifikation aus.Steuern der WCF Message Body-Serialisierung

Vielleicht einfach MessabeBody Beispiel, das erfolgreich durch WCF verarbeitet, wird dazu beitragen, zu verstehen, was ich meine:

<s:Body> 
    <TestMethod xmlns="someNamespace"> 
    <x>1</x> 
    <str>param2</str> 
    </TestMethod> 
</s:Body> 
+0

Oh nein, ich glaube, XmlSerializerFormatAttribute tut nichts Gutes - XmlSerializer einfach nicht löst eine Ausnahme, dass das Element „Prozess“ nicht gefunden, aber es ergibt sich, dass die Methode mit null als Parameter Aufruf = ( –

+0

Oh, wie es oft geschieht, gute Frage. ist eine Hälfte der Antwort =). Ich fand Attribut, das half: [XmlSerializerFormatAttribute] Fügen Sie es zu Interface-Methode von WCF-Service hinzu –

Antwort

0

Sie WCF Deserialisierung vollständig mit dem „Universaldienstvertrag“ auf der Serviceseite überspringen könnten:

und dann die Deserialisierung selbst mit der empfangenen Nachrichteninstanz arbeiten.

Wenn Sie eine Stub-Emulation eines externen Dienstes zu Testzwecken schreiben (ich schätze), ist das trotzdem ein guter Ansatz, da Sie genau kontrollieren können, was in der Antwort gesendet wird.

+0

Danke! Sieht so aus, als würde es helfen! Ich habe fast die gleiche Methode ausprobiert, aber anstelle von Message Parameter habe ich RequestTypeBase verwendet –