w3c.dom.element consumption by .NET clients...is this possible?
Have a tough one for you good people :)
Is it possible for a .NET client to consume a w3c.dom.element type? Now let
me elaborate on that....I'm creating a custom proxy class for an exsiting
Java Axis 1.0 web service which features the ApacheSoap:Element return
Now I can do this currently with the SOAP toolkit and the HTTP40Document
classes...but why? I mean was not .NET supposed to be the greatest platform
for Web Services? Why am I loosing functionality by using .NET? I mean I
can use interop with legacy COM and the MS SoapTool Kit 3.0 but again why?
I'm currently bashing my skull againts my keyboard trying to figure out how
to resolve the raw SOAP response and request messages correctly. I do not
want to have to resort to building my soap envelopes via string love. It
seems a bit unpalatable even for this x vbscript coder.
If anyone has used Axis 1.0 with ApacheSoap:Elements please e-mail or post I
would truly be greatfull.
Thank you very much....
Share your photos without swamping your Inbox. Get Hotmail Extra Storage
- Ok I created a custom client side WSDL using XSD in the <type/>
section. Previously the apache soap namespace was being imported
into the XSD namespace and it was not working correctly.
I created a custom client proxy class as well. I created classes for
each of the elements being passed from the Axis Web Service...it
appears to be working...well the WSDL is valid. I used "MindReef"
and it was able to use it againts the web service and I was getting
data back correctly. Unfortunately the .NET client still barfs on the
same xml message error.
I think this has to do with the server not responding with non RPC
encoded style messages....they are actually not fully QNamed
predicated. They are simpley angle bracket error responses. And where
the Server Side code is injected in the response message is where it
barfs in .NET. Me thinks they are doing both...declaring messages as
RPC but yet still sending messages in Doc/Literal format.
Bad code smell....
Anyone else had any problems with recieving doc-literal using a .NET
client expecting RPC style?