[C#] Webservice dynamic invoke + raw data

[Verwijderd]

Via een stuk C# code wordt een webservice die beschreven is in een WSDL file dynamisch aangeroepen. De code daarvoor heb ik gehaald van http://www.codeproject.co...namic-Web-Service-Invoker. Dit werkt perfect.

Nu zou ik echter graag toegang hebben tot de ruwe data (soap) die ontvangen wordt door de webservice. Dit gaat blijkbaar moeilijker dan ik verwacht had. Volgens het voorbeeld dat op MSDN: SoapExtension Class (System.Web.Services.Protocols) te vinden is, zou ik boven mijn methodes een custom attribuut moeten zetten, om zo een SoapExtension te definieren.
De webservices methodes zelf zitten niet in mijn code, maar worden dus gegenereerd door middel van een ServiceDescriptionImporter. Een andere manier om de extension werkende te krijgen heb ik niet gevonden.

Hopelijk kan hier iemand mij helpen om de code van de eerste url uit te breiden zodat ik de soap data te weten kan komen.

[D-Raven]

Waarom dacht je in godsnaam dat het verstandig was om het aanroepen van een webservice, waarvan je de WSDL kant en klaar krijgt aangeleverd, op zo'n manier te doen?

Doe eens niet zo ontiegelijk moeilijk, en gebruik gewoon de tools die hiervoor bedoeld zijn. M.a.w WCF. Dan is het wegschrijven van de rauwe data die je ontvangt ineens heel eenvoudig.

[ Voor 13% gewijzigd door D-Raven op 13-12-2013 14:57 ]

[Verwijderd]

Van waar haal je het feit dat we de WSDL kant en klaar krijgen? Dat is namelijk net niet het geval.
De WSDL is configureerbaar. En afhankelijk van welke WSDL er ingeladen wordt kunnen bepaalde methodes aangeroepen worden met argumenten.
Anders zou het inderdaad heel erg eenvoudig zijn.

[D-Raven]

Verwijderd schreef op vrijdag 13 december 2013 @ 15:16:
Van waar haal je het feit dat we de WSDL kant en klaar krijgen? Dat is namelijk net niet het geval.
De WSDL is configureerbaar. En afhankelijk van welke WSDL er ingeladen wordt kunnen bepaalde methodes aangeroepen worden met argumenten.
Anders zou het inderdaad heel erg eenvoudig zijn.

Je roept dus je wsdl url met parameters aan, en op basis daarvan krijg je een andere wsdl terug.......owkeeey...

SoapExtension kun je niet gebruiken, want volgens mij is dat puur voor de Soap Service zelf. En je bent hier de client/aanroepende partij.

Wat je aan het doen bent is het dynamisch genereren van een statische abstractie welke het .Net framework aanbied voor het communiceren met een SOAP Service.
Deze abstracties zijn nooit ontworpen/bedoeld om op deze manier gebruikt te worden.

Met de 'oudere' .net soap clients gaat je dit gewoon niet lukken. Want enige extensie punten die er zijn worden allemaal via class/method scoped attributes gedaan. Wat dus kansloos is als je je service op deze manier genereert.

Een alternatief zou WCF kunnen zijn. Vanuitgaande dat het je lukt om dynamisch een wcf service client te genereren, vervolgens moet je daar dan een binding bij genereren.
De binding kun je helemaal in code opbouwen, hierbij kun je dan ook extensies/interceptors registreren. Dus dan zou je wel 'dynamisch' dingen als logging enzo er aan toe kunnen voegen.

Mocht je zelf dat idee nog niet hebben, dan zal ik het nog eens expliciet zeggen. Volgens mij zit je je oplossing in de verkeerde richting te zoeken .

Waarom is die wsdl dynamisch? En hoe dynamisch is die WSDL dan eigenlijk? Ik kan me niet voorstellen dat er een oneindig/zeer grote hoeveelheid varianten mogelijk zijn. (en welke zieke geest verzint zoiets)

edit:

Wat niet zo vreemd is zijn constructies als: www.serviceendpoints.com/wsdl?service=Login en www.serviceendpoints.com/wsdl?service=Account.

Of www.serviceendpoints.com/...rvice=Login&style=message en www.serviceendpoints.com/wsdl?service=Login&style=rpc

Maar dan heb je dus 2 services die je gewoon kunt consumeren op een normale manier. Maar deze constructie is niet waarna jij hint in je verhaal. Vandaar mijn reactie op deze manier.

[ Voor 10% gewijzigd door D-Raven op 13-12-2013 16:14 ]

[Verwijderd]

Uw aannames zijn helaas niet helemaal juist.
Het betreft hier om een monitoring tool voor webservices. De gebruiker geeft dus de locatie van de wsdl file op. Kan daarna een methode kiezen uit die WSDL, en daarna dus de verschillende properties in het request object invullen.
Ik kan dus onmogelijk weten welke WSDL de gebruiker gaat invullen. In principe kan dat elke mogelijke WSDL waar dan ook zijn.

De tool gaat dan om de x seconden de request uitvoeren. En er kunnen bepaalde velden uit het response object gechecked worden om te kijken of de webservice nog op de juiste manier werkt.

Wat hierboven beschreven is heb ik al, en werkt al geruime tijd zeer goed.
Nu wil een bepaalde groep gebruikers echter meer info zien, onder andere de raw data dat verstuurd en ontvangen wordt.

Het gaat hier dus niet over een of andere zieke geest die zijn webservice slecht ontworpen heeft.

[pedorus]

Er worden in die CodeProject-post 2 methodes beschreven om dynamisch een soap web service te invoken. Ik snap eigenlijk niet wat er mis is met methode 1, volgens mij is dit handiger, en dan heb je ook direct toegang tot de ruwe data. Iemand die met een soap webservice werkt heeft vast toch al de xml data voor een test request in soapUI oid, dus die kun je er dan ook een stuk makkelijker in kwijt.

[Verwijderd]

Dat komt de gebruiksvriendelijkheid van de software zeker niet ten goede.

[D-Raven]

Verwijderd schreef op zaterdag 14 december 2013 @ 12:01:
Uw aannames zijn helaas niet helemaal juist.
Het betreft hier om een monitoring tool voor webservices. De gebruiker geeft dus de locatie van de wsdl file op. Kan daarna een methode kiezen uit die WSDL, en daarna dus de verschillende properties in het request object invullen.
Ik kan dus onmogelijk weten welke WSDL de gebruiker gaat invullen. In principe kan dat elke mogelijke WSDL waar dan ook zijn.

De tool gaat dan om de x seconden de request uitvoeren. En er kunnen bepaalde velden uit het response object gechecked worden om te kijken of de webservice nog op de juiste manier werkt.

Wat hierboven beschreven is heb ik al, en werkt al geruime tijd zeer goed.
Nu wil een bepaalde groep gebruikers echter meer info zien, onder andere de raw data dat verstuurd en ontvangen wordt.

Het gaat hier dus niet over een of andere zieke geest die zijn webservice slecht ontworpen heeft.

"U" hoeft niet hoor

Bedankt dat je het waarom van je huidige oplossing even toegelicht hebt. Dit maakt het een en ander wat duidelijker.

De oplossing richting die je nu hebt is wellicht perfect voor de tool wat je nu gebouwd hebt. Alleen omdat het dus op zo'n dynamische manier gebeurd ben je gewoonweg gelimiteerd in de mogelijkheden die je hebt.
Het antwoord van Pedorus illustreert dit ook perfect. In zijn oplossing is het eenvoudiger om verder te gaan dan simpelweg communiceren met een webservice. Maar raak je weer je reflectie mogelijkheden kwijt om makkelijk de functionaliteiten te bieden die je tool nu heeft.

Nogmaals, ik denk dat je met WCF meer succes hebt. Je zou met de wdsl.exe een .cs bestand (wat de wcf service class bevat) kunnen genereren welke je vervolgens dynamisch inlaad in je appdomain. Waarna je weer met reflectie aan de slag kan.
Alleen zie ik even niet hoe je dan vervolgens een juiste binding opbouwt in code, zonder de config file (welke door wsdl.exe naast de .cs file gegenereerd wordt) te parsen om daar de specifieken uit te pluizen.

Maar als je dat eenmaal hebt, dan kun je perfect tracelisteners en weet ik wat nog meer bij de bindings configureren.

Succes!

[Verwijderd]

Ik heb het nu inderdaad kunnen oplossen door over te schakelen op WCF. Hiervoor heb ik voorbeeldcode gevonden op: http://blogs.msdn.com/b/v...programming-with-wcf.aspx.
De WSDL file wordt nog steeds geconverteerd naar een assembly waarvan ik methods via reflection kan invoken. Dus het grootste deel van mijn huidige code kon behouden blijven.

Om dan de raw data eruit te halen is het nu inderdaad heel erg makkelijk. Gewoon een behaviour toevoegen aan de endpoint die gebruikt wordt. Hoe dat moet heb ik hier geleerd: http://mbsguru.blogspot.b...ng-raw-soap-messages.html

Bedankt iedereen voor de hulp!

[D-Raven]

Die dynamicproxytool is wel erg nice. Lost meteen het probleem op van hoe je aan je binding gegevens gaat komen.