Tworzenie i prezentowanie usługi SOAP i jej WSDL dynamicznie w języku C# (z niestandardowym detektorem TCP!)

Question

Mam niestandardowy serwer HTTP zbudowany w języku C#, który akceptuje żądania usług REST i odpowiada za pomocą XML lub JSON (w zależności od tego, co potrzeby klienta). Usługi REST są definiowane w środowisku wykonawczym z konfiguracji opartej na bazie danych, różnią się znacznie pod względem parametrów wejściowych i typów danych wyjściowych, a także sprawnie pracują podczas produkcji.

Chciałbym jednak dodać dostęp SOAP do tych samych usług, z odpowiednimi plikami WSDL. Ponieważ dostępne usługi nie są zakodowane, to znaczy:

• Publikowanie WSDL wygenerowany przy starcie z definicjami metoda w bazie
• parsowania przychodzące żądania SOAP, mapowanie ich do tych definicji i upewniając wnioski są zgodne z podpisem metody przed zabiegiem im
• gdy odpowiedź jest obsługiwane, tworząc spotkanie odpowiedzi SOAP WDSL powrotu Wyniki

dokumentacja MS (i Google) dokumentów za pomocą Visual Studio do generowania stron internetowych servi cs (i WSDL) w czasie projektowania, eksponowanie rzeczy za pomocą WebMethods, ASP.NET MVC itd. Nie jest to tym, czego szukam, ponieważ nie istnieją definicje metod, z których można wygenerować wiązania w czasie projektowania.

Czy ktoś ma jakieś pomysły (np. Zestawy narzędzi do nieprzetworzonego parsowania SOAP) i myśli na temat generowania WSDL-ów z dynamicznie tworzonych sygnatur metod, itp.? Masz pojęcie, jak można budować takie rzeczy, jeśli nie? Staram się uniknąć ponownego wynalezienia koła, jeśli to możliwe.

PS: Najwyraźniej w systemie .NET istnieją standardowe elementy, ponieważ Visual Studio robi to za Ciebie - wszelkie pomysły na dostęp do tego na niższym poziomie w czasie wykonywania?

Answer 1

Aby utworzyć dynamicznie WSDL można użyć ServiceDescriptionReflector

Na przykład: dla klasy

public class TestWebService 
{ 
    [WebMethod] 
    public string Hello(string namex) 
    { 
     return "Hello " + namex; 
    } 
} 

można użyć tego kodu

StringWriter wr = new StringWriter(); 
var r = new System.Web.Services.Description.ServiceDescriptionReflector(); 
r.Reflect(typeof(TestWebService), "http://somewhere.com"); 
r.ServiceDescriptions[0].Write(wr); 
var wsdl = wr.ToString(); 

Ale odkąd powiedział

Publishin ga WSDL generowane w czasie wykonywania z definicji metody w bazie

trzeba stworzyć Type przy starcie

var asm = AppDomain.CurrentDomain.DefineDynamicAssembly(new AssemblyName("MyAsm"), AssemblyBuilderAccess.Run); 
var mod = asm.DefineDynamicModule("MyModule"); 

TypeBuilder typeBuilder = mod.DefineType("TestWebService"); 

MethodBuilder mb = typeBuilder.DefineMethod("Hello", MethodAttributes.Public, CallingConventions.Standard, typeof(string), new Type[] { typeof(string) }); 
var cab = new CustomAttributeBuilder(typeof(WebMethodAttribute).GetConstructor(new Type[]{}), new object[]{}); 
mb.SetCustomAttribute(cab); 
mb.DefineParameter(1, ParameterAttributes.In, "namex"); 
mb.GetILGenerator().Emit(OpCodes.Ret); 

Type type = typeBuilder.CreateType(); 

Teraz można użyć type stworzyć WSDL

StringWriter wr = new StringWriter(); 
var r = new System.Web.Services.Description.ServiceDescriptionReflector(); 
r.Reflect(type, "http://somewhere.com"); 
r.ServiceDescriptions[0].Write(wr); 
var wsdl = wr.ToString(); 

Do czytania Żądanie i tworzenie odpowiedzi, możesz użyć Linq2Xml. Fiddler może dać pojęcie o formacie SOAP (xml) wysłanym między klientem a serwerem:

Answer 2

SOAP jest "po prostu" opartym na XML protokołem wymiany informacji. Wdrożenie wsparcia od podstaw byłoby męczące, ale w zasadzie nie jest skomplikowane, nie sądzę.

Oficjalne specyfikacje SOAP można znaleźć pod numerem here.

Answer 3

Nie analizowania SOAP chyba rzeczywiście trzeba, niech WCF zrobić podnoszenia ciężkich dla Ciebie, wygenerować na usługi i datacontracts w kodzie C# ze swoimi definicjami i kompilacji w czasie wykonywania. Wygeneruj implementację usługi, która będzie podłączana do twojego "statycznego" kodu poprzez dobrze znany interfejs.

Dynamicznie twórz punkty końcowe z poprawnym wiązaniem dla nowych umów o świadczenie usług/umów dotyczących danych. Jeśli powiązania nie zmieniają się dynamicznie, można to zdefiniować w pliku app.config, w przeciwnym razie należy to również ustawić w środowisku wykonawczym.

dodaj punkt końcowy Mex, aby opublikować wsdl.

Dla "zbadaniu" wykorzystywać ruch przychodzący MessageInspector

własnym gospodarzem/usługę WCF SOAP w serwer HTTP przy użyciu ServiceHost ->Self Hosting WCF

Zaledwie kilka pomysłów na innym podejściu.