As much as we complain about SOAP web services. SOAP has the great advantage in that everything we need to know to know is contained in the WSDL file. Also if you are interfacing to SAP and other ERP systems you can be sure that they will have a SOAP implementation

WDSL stands for (Web Service Definition Language) and provides us all the information we need, especially our method prototypes and data types that need to be serialised

The procedure to reverse engineer a SOAP web service is as follows

1. Obtain the WSDL file describing the service
2. Run SVCUTIL.exe on the WSDL to generate the interface class source and the output.config
3. Inherit the interface class in your service class
4. Implement the action methods in your service class
5. Incorporate the channel binding in output.config into the web.config file

Let’s look at a simple example. A soap service that returns a GUID.

First create an empty WSDL service:

In visual studio 2013

File -> new project ->WCF->WCF Service Application

Copy the WSDL file from the original service to into the directory containing the service source files

Now run svcutil on the wsdl file.

Note that the ScvUtil.exe resides in the .NET tools directory. Two files will be created, guidService.cs and output.config

The guidService.cs file contains the service and operations contracts decorations and the interface class for the service.Replace the service and Operations contracts in your Iservice.cs file with these definitions.

This is where a lot of time and pain is saved.(If any of the method definitions has a misspelt parameter this will cause an error when interfacing to the service and can be quite difficult to find. Same goes for the Namespace and configuration name)

Incorporate the binding information from the output.config file to your web.config file.

Finally in your service.svc file inherit the interface class and implement the methods required

And now you have your own implementation of the original web service.

To test your reverse engineered web service take the original wsdl and load this into SOAP UI, if you can connect and operate the service with the original wsdl you are worthy J

Hope this helps with your testing J