Alright! This is not hard. This is yet another service you have already worked with, but without knowing what it actually is.
Let’s start with this: It’s a Web service, right! — but with a SOAP part attached to its face. So, if you know what a web service is and a few other terms I’m going to discuss, it will be a little easier for me to explain what a SOAP web service is.
What is a “Web Service”?
Is it a website? Mmm! It’s not quite true if I say yes. A web service is not essentially a website. It’s a Web + Service — a service provided through the Internet.
A website is meant to deal with humans (at least for now). But a Web Service is for applications (to deal with another application or a program).
Think of a web service like a waiter at a restaurant. You (the client) place an order, the waiter (the web service) delivers it to the kitchen (the server). Then he brings back your food (the response) without you ever knowing how it was cooked.
Just like that, the webservice will deal with the requests we provide and provide necessary responses to the client-end of the application to serve us.
What happened before Web Services?
Before web services, if you wanted to create a new website using existing data from another site, you had to copy the entire method (code) as a .jar file to your server, and it didn’t work simply by completing that task.
You also needed to create the same database. Moreover, when something changed in the original source, the updated code structure had to be recompiled and sent back to your server, along with updating the database as well.
With that experience, some kind of communication method was in dire need. A method that applications could use to communicate without replicating the same code again and again.
Web Services was the answer to that problem.
With the introduction of web services, developers have had a great chance to make applications communicate with each other rather than replicating the code.
Now, only the response needed can be obtained as an output and can be used anywhere with any technology — More and more applications have been introduced to the internet.
There are two major ways to create web services:
- SOAP
- REST
Today, we keep the REST out of the way and dig a little deeper into SOAP technologies (the older but still widely used method).
What is SOAP?
If I just elaborate the term, it’s the Simple Object Access Protocol. But we want to dive a little more if we’re going to truly know what it actually is.
Here’s how it works.
When a client app — let’s say a website — is requested some data from a web service, that request should be in a way that the web server can understand. If both the application and the server are in the same language, this is easy, but what if not?
In most cases, it’s going to be not.
Today, apps are being developed using numerous technologies and languages. Furthermore, the developers don’t even care about the language of the web services they are going to use.
Because they know there’s a way to communicate no matter what language is used. That secret is XML.
What is XML?
Extensible Markup Language is the fundamental way of communication for the web services. Since it is independent of platform and language, the previous problem of communication is no longer there.
XML is like a universal translator. No matter what language the app speaks, XML ensures the message is understood by the server.
All the requests of the client application are turned into one special kind of XML document, which describes the information of the request itself, along with some other technical details like;
- Mode of communication
- Versions of the technologies
- Security mechanisms
and so on. We call that document, Web Services Description Language — or in short — WSDL.
Let’s have a look at WSDL
This is the document which holds the contract between the consumer and the web service. It’s like a compact disk. You can enter it into your application and it will read what’s inside.
Since it is platform and language independent, it can be used anywhere, with any technology.
Here’s a tiny snippet of what a WSDL file looks like: This tells the service how to handle an ‘Add’ request.
<definitions name="CalculatorService">
<message name="AddRequest">
<part name="a" type="xsd:int"/>
<part name="b" type="xsd:int"/>
</message>
</definitions>
And there’s a whole library of WSDLs on the internet that you can either register your WSDLs or browse one to use for any of your projects. It’s called UDDI (Universal Description Discovery Integration).
What’s Next?
So, now you know what SOAP web services are, why they exist, and how they communicate using XML and WSDL. Quite a thing, right? But understanding the theory is just the beginning — the real magic happens when you build one yourself!
In the next part, we’ll create a SOAP web service from scratch — a simple calculator that performs basic operations. You’ll see firsthand how SOAP requests and responses work in action.
👉 Ready to get your hands dirty with some real coding? Let’s dive in!
