SoapExtension web.config setting probleem.

[cablepokerface]

He dot-netters, ik heb een vraagje:

Ik heb een soapextension gemaakt in c# die een soapheader toevoegd aan de inkomende en uitgaande messages. Nu heb ik zowel webservices als asp.net webapplicaties die beide met weinig moeite gebruik willen maken van die extension. Nou is daar een mooie methode voor: "soapExtensionTypes" in de web.config. Werkt goed.

Het probleem is nu, de app groeit en ik moet wat vb6 en java webservices aan gaan spreken. Echter die kotsen allemaal stuk voor stuk die header uit, omdat mijn soapextension die erboven stopt maar de webservice begrijpt daar niets van.

Vraag: hoe kan ik bepalen welke webservice referentie in mijn web app de extension WEL gebruikt en welke referentie hem NIET gebruikt.

(Op WebMethod niveau vastleggen is geen optie, de services zijn te groot en dit vereist teveel onderhoud. Geloof me, het zijn er een hoop).

Beetje advanced stuff. Als je deze weet vind ik ongeveer dit van je:

EDIT: sorry voor het ontbreken van de topic titel prefix: [C# WebServices]

[ Voor 5% gewijzigd door cablepokerface op 13-06-2006 18:35 ]

[Vedett.]

Ik denk dat ik de vraag niet helemaal begrijp.

Jij spreekt een extra webservice aan vanuit je eigen geschreven webservice. Deze extra webservice is geschreven in Java, en je hebt er geen controle over. De webservice die jij gebouwd hebt aanvaardt een soapextension, en stuurt ook soapExtensions terug naar diegene die de webservice oproept?


Je hebt ook een ASP.Net website gebouwd. Deze maakt gebruik van zowel je eigen geschreven webservice, en de extra webservice?


Ik zie echt niet direct het probleem. Je kan in je App toch een andere proxy gebruiken die geen soapHeader toevoegt aan de soapMessage als je naar iemand anders zijn webservice gaat?


Hoe ziet het er schematisch allemaal uit?

code:

asp | vb 
         ---> eigen webservice 
                       ---> andere webservice

-- of --

asp | vb
        ---> eigen webservice
        ---> andere webserivce

[cablepokerface]

Dank je voor de reply.

Mijn asp.net website heeft een aantal web references naar web services. Sommige zijn java, sommige zijn .net (van mezelf) en sommige zijn vb6. Dus:

- asp.net
- ws1 (.net)
- ws2 (java)
- wsa (vb6)
- wsb (.net)
- etc.

Sommige moeten de soapheader ontvangen en sommige niet. omdat de meerderheid de header WEL moet hebben heb ik dit in een web.config setting gedaan en dus niet op WebMethod niveau. Ik wil dus kunnen configureren dat sommige web references er wel gebruik van maken en sommige niet.

note: dus .net services zelf maken ook gebruik van die extensie, nl. om een header terug te sturen als ze er een ontvangen hebben. maar dat maakt het misschien verwarrender, maar die hebben toch een eigen web.config, want het is een apart project.

[Vedett.]

Ja, je maakt het leven er niet makkelijk op he

Wat volgens mij moet werken is, geen SoapExtension in je app.config definiëren! Waar dan wel?
Ik zou een attribuut aanmaken dat overerft van SoapExtensionAttribute. Je maakt voor elke webservice die je aanspreekt een aparte proxy. Ik veronderstel dat dit momenteel het geval is. Op de proxy-classen die een webserice aanspreken die een SoapExtension verwachten plaats je dit attribuut op Class-Level. Let op: je attribuut moet zo geprogrammeerd zijn dat dit op class level kan. Dit kan door een attribuut te plaatsen op je attribuut-class [AttributeUsage(....)] (Veel attributen he ]

[edit]
Ik ben eigenlijk niet zeker dat dit op de client wel werkt
Op de Server weet ik het zeker.

[edit]
Na dit:
http://msdn.microsoft.com...apextensionclasstopic.asp
en dit:
http://msdn.microsoft.com...3/07/XMLSchemaValidation/
te hebben gelezen denk ik dat ik helemaal mis zit.
Ik heb ook een tesprojectje gemaakt, en daar lukt het ook niet in. Ik probeer nog even verder. Als het bij u wel lukt, hoor ik het heel graag

[ Voor 31% gewijzigd door Vedett. op 14-06-2006 20:15 ]

[Vedett.]

Ik krijg het werkend met een attribute, maar enkel op Method-level niveau. Bij class-level doet hij helemaal niets.

Zou een extra scriptje, dat een attribuut toevoegt voor een public method, echt niet mogen??
huidige code staat trouwens hier http://users.pandora.be/bosend/tweakers/TravelSystem.zip


Quote van de eerste link die ik postte

In order to configure a SoapExtension on a method-by-method basis, you need to write a custom attribute derived from SoapExtensionAttribute (see Figure 4). The ExtensionType property returns the type of SoapExtension to use, in this case ValidationExtension. You should take note that this attribute can only be applied to a method, and then only once. This way the compiler will catch most of the places where this attribute might be misapplied. Limiting it to a single instance on a method just makes it easier to implement the extension.

[ Voor 111% gewijzigd door Vedett. op 14-06-2006 21:31 ]

[cablepokerface]

Dank je voor het uitproberen!

Leuk probje blijkt het te zijn.

Ik had ook nog gedacht aan een custom attribute maar ik was te bang dat ik daar tijd in ging stoppen en het uiteindelijk niet werkend kreeg.

Ik heb inmiddels een soort van oplossing bedacht, hij is semi-elegant maar niet perfect. Het voelt iig niet aan als een hack:

In de GetInitializer van de SoapExtension krijg je de type terug van de service of reference die gebruik maakt van de extension. (omdat het geconfigureert is in de webconfig wordt deze methods aangeroepen, als je het op webmethod niveau doet roept ie de andere overload aan).

Nu heb ik een .config file aangemaakt die ik uitlees met m'n (al bestaande) ConfigFilesSectionHandler. Dit config bestand bevat data (xml structuurtje) waarin iedere web reference en service geidentificeerd staat en erbij wordt vermeld of ie de header gebruikt ja of nee. De soapextetension is zo nog steeds erg reusable; als het config bestandje niet bestaat moet de header worden toegevoegd (true), als het config bestandje bestaat en/of de ref staat gedefinieerd als geen soapheader dan returned de GetInitializer false en wordt in de Initialize van de extension die bool in een private field gestopt.

Vervolgens kan dat private field gebruikt worden om te beslissen of tijdens de message handling de soapheader moet worden toegevoegd.

Vind je d'r van?

[Vedett.]

Ik was al aan zoiets aan het denken, maar was naar de HTTP headers aan het kijken. Daar staat natuurlijk de method niet in die je oproept, maar wel de service (.asmx oid).

Ik denk dat het de beste oplossing is, als je rekening houdt met:
- onerhoudbaarheid (generated proxy classes hebben geen attribuut)
- de snelste om te ontwikkelen
- Het gemakkelijkste is aangezien je toch zo goed als alles al geprogrammerd hebt (config + extensie)


Ik vind het ook zeker geen hack. Het is de properste oplossing die je kunt verzinnen met de huidige implementatie van het .Net Framework


Succes ermee

[cablepokerface]

Follow-up. Ik weet niet of deze thread nog gemonitord wordt door iemand maar het kan allemaal beter dan de oplossing die ik had.

De soapextension kijkt in de ProcessMessage naar de SoapMessage en cast deze ofwel naar een SoapServerMessage of een SoapCleintMessage. Deze hebben (respectievelijk) de properties "Server" en "Client".

Deze 2 properties geven een system.object terug die te casten is naar de class van de webservice of de client class. Echter is dat niet echt loosly-coupled.

Het volgende is dus gedaan, indien in de web.config staat aangegeven dat er een soapextension moet worden gebruikt, verplicht deze soapextension het server of Client object tot het implementeren van een bepaalde interface. IHeaders, indien dit object deze niet implementeert throw exception. Hier komt de programmeur die de extension consumeert dus tijdens developen achter.

Deze interface verplicht de class tot het returnen van een pre-configured headertype (we kennen er een aantal) welke de soapextension boven de message plakt.

Beter zo.