What Is Soap Web Services In .net

What is SOAP?

SOAP is an XML-based protocol for accessing spider web services over HTTP. It has some specification which could be used across all applications.

Soap is known as the Simple Object Access Protocol, merely in later on times was simply shortened to Lather v1.ii. Soap is a protocol or in other words is a definition of how web services talk to each other or talk to client applications that invoke them.

SOAP was developed every bit an intermediate linguistic communication so that applications congenital on various programming languages could talk easily to each other and avoid the extreme evolution effort.

In this Soap Web services tutorial, you volition larn-

Soap Introduction
Advantages of SOAP
SOAP Edifice blocks
Soap Bulletin Construction
SOAP Envelope Element
SOAP Advice Model
Practical SOAP Example

SOAP Introduction

In today's earth, there is huge number of applications which are congenital on unlike programming languages. For example, at that place could be a web application designed in Java, another in .Net and another in PHP.

Exchanging data between applications is crucial in today's networked world. But information exchange betwixt these heterogeneous applications would exist complex. And then volition be the complexity of the code to accomplish this data exchange.

One of the methods used to combat this complexity is to use XML (Extensible Markup Linguistic communication) as the intermediate language for exchanging data between applications.

Every programming language can empathise the XML markup language. Hence, XML was used equally the underlying medium for information substitution.

But in that location are no standard specifications on utilise of XML beyond all programming languages for data exchange. That is where SOAP software comes in.

SOAP was designed to work with XML over HTTP and have some sort of specification which could be used beyond all applications. Nosotros will wait into further details on the SOAP protocol in the subsequent chapters.

Advantages of SOAP

Lather is the protocol used for information interchange between applications. Below are some of the reasons as to why Lather is used.

When developing Lather based Spider web services, you need to have some of language which can be used for spider web services to talk with customer applications. Soap is the perfect medium which was developed in order to achieve this purpose. This protocol is also recommended by the W3C consortium which is the governing body for all spider web standards.
SOAP is a low-cal-weight protocol that is used for information interchange between applications. Note the keyword 'calorie-free.' Since SOAP programming is based on the XML linguistic communication, which itself is a calorie-free weight data interchange language, hence Soap equally a protocol that also falls in the aforementioned category.
Lather is designed to be platform independent and is also designed to be operating organization contained. And then the SOAP protocol tin can work whatever programming language based applications on both Windows and Linux platform.
It works on the HTTP protocol –Lather works on the HTTP protocol, which is the default protocol used by all web applications. Hence, there is no sort of customization which is required to run the web services congenital on the Soap protocol to piece of work on the World wide web.

SOAP Building Blocks

The SOAP specification defines something known as a "Soap message" which is what is sent to the web service and the client application.

The below diagram of Soap architecture shows the various building blocks of a Soap Message.

The SOAP bulletin is nothing but a mere XML document which has the beneath components.

An Envelope chemical element that identifies the XML document as a SOAP message – This is the containing role of the Soap message and is used to encapsulate all the details in the Lather bulletin. This is the root element in the SOAP bulletin.
A Header element that contains header information – The header element tin incorporate data such as authentication credentials which can exist used by the calling application. It can as well comprise the definition of complex types which could be used in the SOAP message. Past default, the Lather message tin contain parameters which could be of unproblematic types such as strings and numbers, but can also be a circuitous object blazon.

A uncomplicated SOAP service example of a complex type is shown below.

Suppose we wanted to ship a structured data blazon which had a combination of a "Tutorial Name" and a "Tutorial Description," then we would define the complex type as shown below.

The complex type is defined by the element tag <xsd:complexType>. All of the required elements of the structure along with their respective data types are then defined in the circuitous type collection.

<xsd:complexType>       <xsd:sequence>         	<xsd:element proper noun="Tutorial Name" type="string"/>            	<xsd:element proper noun="Tutorial Clarification"  blazon="string"/>   </xsd:sequence> </xsd:complexType>

A Body chemical element that contains telephone call and response information – This element is what contains the actual data which needs to be sent between the web service and the calling application. Beneath is an SOAP web service example of the SOAP body which actually works on the complex type divers in the header section. Here is the response of the Tutorial Name and Tutorial Description that is sent to the calling application which calls this spider web service.

<soap:Body>    <GetTutorialInfo> 		<TutorialName>Web Services</TutorialName>  		<TutorialDescription>All nigh web services</TutorialDescription>     </GetTutorialInfo> </soap:Body>

SOAP Message Structure

One thing to notation is that Lather messages are normally auto-generated by the web service when it is called.

Whenever a client application calls a method in the web service, the web service will automatically generate a SOAP bulletin which will have the necessary details of the data which volition be sent from the web service to the client awarding.

As discussed in the previous topic of this SOAP tutorial, a unproblematic SOAP Message has the following elements –

The Envelope element
The header element and
The body element
The Mistake element (Optional)

Let'southward look at an example below of a simple Soap message and come across what element actually does.

SOAP Message Structure — Soap Bulletin Structure

As seen from the above SOAP bulletin, the get-go part of the SOAP message is the envelope element which is used to encapsulate the entire SOAP message.
The next element is the Soap body which contains the details of the bodily message.
Our bulletin contains a web service which has the name of "Guru99WebService".
The "Guru99Webservice" accepts a parameter of the type 'int' and has the name of TutorialID.

Now, the in a higher place SOAP bulletin will be passed between the web service and the client application.

Y'all tin see how useful the above information is to the client application. The SOAP message tells the client application what is the name of the Web service, and also what parameters it expects and besides what is the blazon of each parameter which is taken by the web service.

SOAP Envelope Element

The kickoff bit of the edifice cake is the Lather Envelope.

The SOAP Envelope is used to encapsulate all of the necessary details of the SOAP messages, which are exchanged between the web service and the client awarding.

The Lather envelope chemical element is used to signal the starting time and cease of a SOAP message. This enables the client awarding which calls the spider web service to know when the Lather message ends.

The following points can exist noted on the SOAP envelope element.

Every SOAP message needs to have a root Envelope element. It is absolutely mandatory for SOAP message to have an envelope chemical element.
Every Envelope chemical element needs to take at least one soap body element.
If an Envelope element contains a header element, it must contain no more than one, and it must appear as the first child of the Envelope, before the body element.
The envelope changes when Soap versions change.
A v1.one-compliant SOAP processor generates a fault upon receiving a bulletin containing the v1.2 envelope namespace.
A v1.2-compliant Lather processor generates a Version Mismatch fault if it receives a message that does not include the v1.two envelope namespace.

Below is an Soap API example of version one.2 of the Soap envelope chemical element.

<?xml version="1.0"?> <Soap-ENV:Envelope xmlns:Lather-ENV="http://www.w3.org/2001/12/soap-envelope" SOAP-ENV:encodingStyle=" http://www.w3.org/2001/12/soap-encoding">           <lather:Body>         <Guru99WebService xmlns="http://tempuri.org/">                   <TutorialID>int</TutorialID>                 </Guru99WebService>           </soap:Trunk> </Lather-ENV:Envelope>

The Fault message

When a asking is made to a SOAP web service, the response returned tin be of either ii forms which are a successful response or an error response. When a success is generated, the response from the server will always be a SOAP message. Simply if Soap faults are generated, they are returned every bit "HTTP 500" errors.

The SOAP Fault message consists of the following elements.

<faultCode>– This is the lawmaking that designates the lawmaking of the error. The fault lawmaking can exist either of whatever beneath values
1. Soap-ENV:VersionMismatch – This is when an invalid namespace for the Soap Envelope chemical element is encountered.
2. Soap-ENV:MustUnderstand – An immediate child element of the Header element, with the mustUnderstand attribute set to "1", was not understood.
3. SOAP-ENV:Client – The bulletin was incorrectly formed or contained incorrect information.
4. Soap-ENV:Server – In that location was a problem with the server, so the message could not proceed.
<faultString> – This is the text message which gives a detailed description of the error.
<faultActor> (Optional)– This is a text string which indicates who caused the fault.
<particular>(Optional) – This is the element for application-specific error messages. So the application could have a specific error bulletin for different business logic scenarios.

Example for Fault Message

An instance of a error message is given below. The error is generated if the scenario wherein the client tries to use a method called TutorialID in the class GetTutorial.

The beneath mistake message gets generated in the issue that the method does not exist in the defined class.

<?xml version='1.0' encoding='UTF-8'?> <SOAP-ENV:Envelope xmlns:Soap-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/1999/XMLSchema-case" xmlns:xsd="http://www.w3.org/1999/XMLSchema">       <Lather-ENV:Trunk>          <Soap-ENV:Fault>          <faultcode xsi:type="xsd:string">SOAP-ENV:Client</faultcode>         <faultstring xsi:type="xsd:string">             Failed to locate method (GetTutorialID) in grade (GetTutorial)          </faultstring>     </SOAP-ENV:Fault>    </Lather-ENV:Body> </Soap-ENV:Envelope>

Output:

When you execute the above code, it volition testify the error like "Failed to locate method (GetTutorialID) in class (GetTutorial)"

SOAP Communication Model

All advice by SOAP is done via the HTTP protocol. Prior to SOAP, a lot of web services used the standard RPC (Remote Procedure Call) style for communication. This was the simplest type of communication, but it had a lot of limitations.

Now in this SOAP API tutorial, let's consider the beneath diagram to see how this communication works. In this example, let's presume the server hosts a web service which provided 2 methods as

GetEmployee – This would become all Employee details
SetEmployee – This would set the value of the details like employees dept, salary, etc. accordingly.

In the normal RPC style communication, the client would simply call the methods in its request and transport the required parameters to the server, and the server would then send the desired response.

The above communication model has the below serious limitations

Not Language Independent – The server hosting the methods would exist in a detail programming language and unremarkably the calls to the server would be in that programming language only.
Not the standard protocol – When a call is made to the remote procedure, the call is not carried out via the standard protocol. This was an outcome since mostly all advice over the spider web had to be done via the HTTP protocol.
Firewalls – Since RPC calls practise not go via the normal protocol, divide ports need to be open on the server to allow the customer to communicate with the server. Normally all firewalls would cake this sort of traffic, and a lot of configuration was generally required to ensure that this sort of communication between the client and the server would work.

To overcome all of the limitations cited higher up, SOAP would then utilise the below communication model

The client would format the information regarding the procedure call and whatever arguments into a Lather message and sends it to the server as part of an HTTP request. This procedure of encapsulating the data into a Soap message was known as Marshalling.
The server would so unwrap the message sent by the customer, see what the client requested for and so transport the appropriate response back to the customer as a SOAP message. The do of unwrapping a request sent by the customer is known as Demarshalling.

Practical SOAP Example

Now in this SoapUI tutorial, let's see a practical SOAP example,

Probably one of the best ways to run into how SOAP messages become generated is to actually run across a spider web service in action.

This topic will expect at using the Microsoft.Net framework to build an ASMX web service. This type of web service supports both SOAP version 1.1 and version 1.ii.

ASMX web services automatically generate the Spider web Service Definition Language (WSDL) document. This WSDL document is required by the calling client application so that the application knows what the web service is capable of doing.

In our example, we are going to create a simple web service, which volition be used to return a string to the application which calls the spider web service.

This web service will be hosted in an Asp.Net web application. We will then invoke the web service and see the consequence that is returned by the spider web service.

Visual Studio will also show us what the Soap message being passed between the spider web service and the calling application.

The offset pre-requisite to setup our Web service application which can be washed by following the below steps.

Delight ensure that you take Visual Studio 2013 installed on your organization for this example.

Step 1) The get-go footstep is to create an empty ASP.Net Web awarding. From Visual Studio 2013, click on the card option File->New projection.

SOAP Message Example

One time you click on the New Projection option, Visual Studio will then give you another dialog box for choosing the type of project and to give the necessary details of the project. This is explained in the next footstep.

Pace two) In this pace,

Ensure to commencement choose the C# spider web template of ASP.Net Spider web application. The projection has to be of this type in order to create SOAP services project. Past choosing this pick, Visual Studio will then carry out the necessary steps to add together required files which are required by any web-based awarding.
Give a name for your projection which in our case has been given equally webservice.asmx. Then ensure to give a location where the project files will be stored.

SOAP Message Example

Once done you will see the project file created in your solution explorer in Visual Studio 2013.

SOAP Message Example

Step 3) In this footstep,

We are going to add a Web service file to our project

First Right-click on the project file as shown below

SOAP Message Example

Once you right-click on the project file, you have the chance to choose the option "Add->Web Service(ASMX) to add a spider web service file. Just provide a name of Tutorial Service for the web service name file.

SOAP Message Example

Footstep 4) Add together the following code to your Tutorial Service asmx file.

SOAP Message Example

Code Explanation:

This line of code provides a name for your spider web service file. This is an important step because it gives mode for the customer application to call the spider web service via the name of the web service.
Normally a class file is used to encapsulate the functionality of a spider web service. And so the class file will have the definition of all the web methods which will provide some functionality to the client application.
Here [WebMethod] is known as an aspect which describes a function. The subsequent stride creates a part chosen "Guru99WebService", but with the inclusion of this stride of adding a [WebMethod] aspect makes sure that this method tin be invoked past a client application. If this attribute is not in place, then the method tin can never exist called by a client application.
Here we are defining a function chosen 'Guru99WebService' which will exist used to return a cord to the calling client application. This function is a web service which can exist called by whatever client application.
We are using the return argument to return the string "This is a Guru99 Web service" to the client application.

If the code is executed successfully, the following Output will be shown when you run your lawmaking in the browser.

Output:

SOAP Message Example

The output clearly shows that the name of our web service is "Guru99 Web Service" which is the result of giving a name for our web service.
We tin can likewise see that we tin to invoke the web service. If we click the Invoke button, nosotros will become the below response in the web browser.

SOAP Message Example

The higher up output,

It clearly shows that by invoking the spider web method, the string "This is a Guru99 Web service" is returned.
Visual Studio besides allows you to view the Lather message request and response which is generated when the in a higher place spider web service is called.

The SOAP request which is generated when the web service is chosen is shown below.

SOAP Message Example

Code Caption:

The starting time role of the SOAP message is the envelope chemical element which is what was discussed in the prior capacity. This is the encapsulating element which is present in every SOAP message.
The Lather Body is the next element and contains the actual details of the SOAP message.
The third part is the element which specifies that nosotros want to telephone call the service which is called 'Guru99WebService.'

SOAP Message Example

<soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">        <soap:Torso>                <Guru99WebServiceResponse xmlns="http://tempuri.org/">                        <Guru99WebServiceResult>string</Guru99WebServiceResult>                    </Guru99WebServiceResponse>     </lather:Body> </soap:Envelope>

Code Caption:

The get-go part of the SOAP message is the envelope element which is what was discussed in the prior chapters. This is the encapsulating chemical element which is present in every Lather bulletin.
The Lather Body is the next element and contains the actual details of the SOAP bulletin.
The interesting role you volition run across at present is the 'string' aspect. This tells the client application that the web service being chosen returns an object of the type cord. This is very useful because if the client awarding which otherwise would non know what the web service returns.

Summary

SOAP is a protocol which is used to interchange data between applications which are built on different programming languages.
SOAP is built upon the XML specification and works with the HTTP protocol. This makes it a perfect for usage within spider web applications.
The SOAP building blocks consist of a Lather Message. Each Soap message consists of an envelope element, a header, and a body element.
The envelope element is the mandatory chemical element in the SOAP message and is used to encapsulate all of the data in the SOAP bulletin.
The header chemical element can be used to contain information such equally hallmark information or the definition of complex data types.
The body chemical element is the main element which contains the definition of the spider web methods along with whatsoever parameter information if required.