Hi Aman, on the basis of what you just said in your last reply. It sounds like you a) want one VSM, b) The VSM will support SOAP/HTTP calls so you can virtualize the operations, c) you want to be able to call the exact same service and retrieve the WSDL. If this is not correct, no need to go further.
If yes, then your high level Use Case scenarios are:
Scenario 1: Call for the WSDL using a rest call For Example: http://localhost:8001/someService/endpoint/path?wsdl
Scenario 2: Call the same endpoint passing a SOAP message: http://localhost:8001/someService/endpoint/path (with a SOAP Envelope containing operation and arguments)
To do these scenarios, open your VSI:
- Create one operation with an operation name of: GET /someService/endpoint/path (there is a space between GET and "/")
- In the META transaction for this operation, add one argument named: wsdl.
- In the response for this operation, place the WSDL that you want returned to the caller.
- The remainder of the operations in your VSI follow SOAP conventions and contain whatever their respective operation and argument signatures are.
- In your VSM, include the SOAP DPH and leave off the REST DPH.
Some customers have done this with success. Their apps can ask for the WSDL and then make a call for an operation.
I cannot vouch for SoapUI or whether or not issues will still exist using that tool.