Ich versuche, Code in C # zu schreiben, der einen WCF-Dienst im laufenden Betrieb aufruft, indem er die WSDL importiert, sie untersucht und dann dynamisch darauf aufruft.
Der Dienst, den ich anrufe, kann sich von Zeit zu Zeit ändern. Wenn das der Fall ist, möchte ich, dass mein Client neue Methoden und neue Eingabeparameter und Ausgabeparameter für die Aufrufe kennt, ohne meinen Client neu aufzubauen.
Eine mögliche Lösung hierfür ist das Importieren und Kompilieren einer Servicereferenz im laufenden Betrieb.
Hier beschrieben: Erstellen einer Baugruppe im laufenden Betrieb von einer WSDL
Ich möchte die Erzeugung einer Baugruppe vermeiden und wenn möglich darüber nachdenken.
Ich habe den Code des dynamischen Proxys im Link untersucht und verwende eine Framework-Klasse, um den Import durchzuführen. Diese Klasse ist WsdlImporter . Ich hatte also eine gute Idee - ich kann das verwenden und das WSDL-Schema untersuchen und bestimmen, welche Anrufe vorhanden sind und welche Eingaben und Ausgaben verfügbar sind.
Das Problem ist, dass die Typinformation in den MessagePartDescription -Objekten fehlt, die WsdlImporter erstellt. Anscheinend fehlt dies weil es die Typen noch nicht finden kann - siehe die Antwort auf die Frage von Brian.
Also irgendwelche Ratschläge, wie ich vorgehen soll? Bin ich hier völlig falsch?
Dies ist wahrscheinlich keine Antwort, aber ich werde es als eine veröffentlichen, um meine Meinung vollständig zu beschreiben.
Dynamischer Proxy:
IMO das ist ein Beispiel für die falsche Nutzung der Technologie. Es ist elementares Verhalten von WSDL - wenn es Änderungen gibt, müssen Sie den Client ändern oder Sie müssen eine gute WSDL-Versionierung vornehmen und einen neuen Client erstellen.
Sie müssen Ihren Client immer noch dazu bringen, WSDL zu erhalten - Bedeutet das, dass Sie WSDL vor jedem Aufruf analysieren? Scheint nicht wie eine gute Idee.
Informationen zu Typen sind nicht Teil von WSDL, da WSDL standardmäßig interoperabel generiert wird. CLR-Typen sind für die Interoperabilität nicht erforderlich. Wenn Sie einen Dienstproxy über die Dienstreferenz "Hinzufügen" oder "Svcutil" erstellen, wird Code für in WSDL definierte Typen generiert. Dieser Code muss dann kompiliert werden.
Sie können versuchen, NetDataContractSerializer anstelle von default DataContractSerializer zu verwenden. NetDataContractSerializer fügt CLR-Typinformationen in WSDL hinzu, aber ich erwarte immer noch, dass Ihren Clients neue Typen bekannt sein müssen - das bedeutet, dass neue Assembly mit Typen bereitgestellt und von Clients verwendet werden. Das klingt fast nach dem gleichen Ansatz, wenn Assembly einfach mit einem neuen statischen Client-Proxy bereitgestellt wird.
Dynamischer WF-Client
Ich sehe auch nicht zu viel Nutzung dieser Architektur - Sie müssen immer noch den Client ändern, um neue WF-Schritte zu reflektieren, nicht wahr?
Ändern der WF
Sprechen wir über die Windows Workflow Foundation? Ich kann mir kaum ein Szenario vorstellen, wo du WF erstellst, es als Dienst entlarvst und es dann änderst. Wenn Sie WF als Dienst bereitstellen, definieren Sie wahrscheinlich WF mit langer Laufzeit. Lang laufende WFs verwenden Persistenz, die auf Serialisierung basiert (zumindest in WF 3.5, aber ich glaube, es ist dasselbe in WF 4). Wenn Sie die WF-Definition ändern, sind alle persistenten WFs höchstwahrscheinlich verloren, weil sie niemals deserialisiert werden. Diese Situation wird normalerweise durch die parallele Bereitstellung einer neuen und einer alten Version gelöst, wobei die alte Version nur dazu verwendet wird, unvollständige WFs zu beenden. Wieder bedeutet es neue Kunden.
Wenn Sie das Problem aus einem anderen Blickwinkel betrachten. Müssen Sie den Proxy jedes Mal neu generieren oder benötigen Sie einen Vertrag, der weiter funktioniert, wenn sich die Dinge ändern?
WCF hat einen Mechanismus für diese IExtensibleDataContracts, siehe: Ссылка
Best Practices für die Versionierung von Verträgen finden Sie hier
Tags und Links wcf c# dynamic wsdl wcf-binding