This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
We are migrating a webservice project from WAS (Websphere Application Server) 5.1 to WAS 6.1 and are encountering problems related to SOAP requests received from a desktop tool that uses this service.
Theoretically the tool accessing our service should have taken the WSDL from us and generated the client but that has not happened(The tool is developed using C++ and sends the request which has been hard coded in it) and now changes to the tool in near future is beyond scope hence we need to do a work around to make this service work for the tool.
The WSDL and a sample soap request is pasted below. The request coming from the tool doesn't have namespace information which is conformant to the target namespace defined in the wsdl. All this worked fine for WAS 5.1 as there was no strict namespace checking but with WAS 6.1 its failing due to namespace validations.
Now, what we would like to do is to align the schema definition with what we receive in the SOAP request. We would like to make the schema validations work for the incoming requests that are in the attached format. So essentially our requirement is to enforce the namespace validations for requestHeader elements and bypass them for the others.
Can anybody please provide leads on what changes we need to do in the schema definition to suit the requests that are coming to us. ( I know this is an odd scenario but then we have to live in real world ! )
The request coming from the tool doesn't have namespace information which is conformant to the target namespace defined in the wsdl. All this worked fine for WAS 5.1 as there was no strict namespace checking but with WAS 6.1 its failing due to namespace validations.
A better option than altering the WSDL schema would be to alter the incoming SOAP message by adding the namespace information. This can easily be implemented with a server-side handler. Handlers can be registered (1) by service, (2) by transport, or (3) globally for all services and transports.
The handler in this case would only apply to incoming messages sent from the desktop application.
Joined: Oct 09, 2008
We tried to implement the Web Service handlers (JAX-RPC) for modifying the namespace of the incoming request before it reaches our service. However, in WAS 6.1 we found that the namespace validation gets triggered before the control reaches the web service handlers. So the request errors out before the handlers can actually modify the namespace.
Kindly suggest any alternative way to resolve this issue. We can't change the incoming request as stated earlier.
Thanks for your help.
Joined: Apr 16, 2008
Sounds like an issue. I am suprised that such a change was implemented without a way to disable it. Your best bet is to stick with WAS 5, until you figure this out. I suggest contacting the vendor to see if they implemented some mechanism to disable the namespace validation on the incoming SOAP message. As you mention, this worked fine with WAS 5.
Or, another solution would be to modify the desktop application so that it sends a 'good' SOAP message for the WAS 6 implementation.