Contract First Web Service Development in .NET
Working on information systems integration often comes with the task of implementing a Web Service following a previously defined contract. This can happen with a design-first approach or a partner interoperability project where you must implement the expected receiver for the incoming data.
To develop an XML web service, having an existing WSDL, we can use the tooling provided with Microsoft Visual Studio.
We will use an ASMX project. If you’re worried about support because this is no longer a part of .NET from version 5 upward, I’d advise you to read this guy's opinion:
To be accurate, both WCF and ASMX will be supported after .NET 5 is released. They will be included in .NET 4.8 and that will be supported as a component of the OS that they are installed on.
Sure, we could use Soap Core, but to work with existing contracts I find it to be a very manual solution and with some risk of inadvertently altering the schema.
Getting down to business, let’s go through the steps of a quick and easy proof of concept for an existing, simple, and free of charge public web service:
Download the WSDL file onto a folder on your local computer. You’ll need Visual Studio installed. Open “Developer Command Prompt for VS 2019”:
On the command prompt, go to the folder where you saved the WSDL file. Run the WSDL command:
wsdl /namespace:My.Contract.First /serverInterface <file.wsdl>
Where <file.wsdl> is the name you gave when saving the contract. Choose an adequate namespace also. Upon successful completion of this command you should have an interface definition corresponding to the methods available on the given Web service:
Open Visual Studio and create a new empty ASP.NET Web Application (.NET Framework):
Right click on your project and “Add > Existing Item”. Browse to your .CS interface file, click “Add”:
Now Add a new ASMX item:
Implement the Interface generated by the WSDL tool on your ASMX:
Build and Run. That’s all for developing the stub web service using an existing WSDL contract.
The SOAP/XML Web services are gradually losing ground to REST APIs for their lack of simplicity and for failing to deliver on the promise for guaranteed cross-platform integration. But most enterprise applications still use it for the enhanced protocol features like formal XML schema definition, transactionality, and security.
So, if you’re building something new, give REST a try. If you’re maintaining previously developed platforms, better off using the existing tooling.