darren_k156
asked on
Siebel Web Service written in Java, consumed by .NET client
Hi everyone, the situation is:
We have an application written in .NET 1.1 which calls several Java Web Service functions. We used WSDL.exe to create our proxy classes and we programmed a Web Service simulator because we actually didn't have access to the Java Web Service to develop against. Everything worked fine against the simulator but when deploying our application we've come across a problem we didn't expect...
The Java Web Services are created by a Siebel system using Siebel V7.5 and it turns out the WSDL files created don't conform to the WS-I 1.1 standards, the violation being there are namespace attributes defined for the SOAP body. This means that the XML coming back to the client is in a different namespace than the standard namespace which is expected.
I've done some tests and proved this is the case by saving the Web Service output (the SOAP message) to file, and serializing the resulting XML file into our objects from which the classes were created by WSDL.exe. When the namespace is swapped for the default namespace our objects are populated, when the namespace is left as specified by the Siebel Web Services they're set to nothing.
The Web Service functions cannot change their interface so this problem has to be solved on the client side.
The way I think this needs to be solved is for us to modify the incoming SOAP message on the client but before our function receives it, and replace the Siebel namespace with the default namespace and pass it on.
I've had SOAPExtensions suggested as a possible solution but these seem to be server side only so I'm ruling this out.
Has anyone got any ideas how I can sort this one?
Cheers
We have an application written in .NET 1.1 which calls several Java Web Service functions. We used WSDL.exe to create our proxy classes and we programmed a Web Service simulator because we actually didn't have access to the Java Web Service to develop against. Everything worked fine against the simulator but when deploying our application we've come across a problem we didn't expect...
The Java Web Services are created by a Siebel system using Siebel V7.5 and it turns out the WSDL files created don't conform to the WS-I 1.1 standards, the violation being there are namespace attributes defined for the SOAP body. This means that the XML coming back to the client is in a different namespace than the standard namespace which is expected.
I've done some tests and proved this is the case by saving the Web Service output (the SOAP message) to file, and serializing the resulting XML file into our objects from which the classes were created by WSDL.exe. When the namespace is swapped for the default namespace our objects are populated, when the namespace is left as specified by the Siebel Web Services they're set to nothing.
The Web Service functions cannot change their interface so this problem has to be solved on the client side.
The way I think this needs to be solved is for us to modify the incoming SOAP message on the client but before our function receives it, and replace the Siebel namespace with the default namespace and pass it on.
I've had SOAPExtensions suggested as a possible solution but these seem to be server side only so I'm ruling this out.
Has anyone got any ideas how I can sort this one?
Cheers
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.