Web Services

The topic of this article is Web Services. Web services are a set of technologies and rules that enable two or more components on the web to talk to each other. By components, I mean anything that exists on the web, anything that could operate on the web is a component. A web server is a component. A web browser is a component. Basically, any web program is a component.

Now, let’s talk about the first web service. The first web service used WSDL (which stands for Web Services Description Language) which is actually the rules in the previous definition and SOAP (Simple Object Access Protocol) which is technology. SOAP uses XML as data format and HTTP as the communication technology. Now, let me show you something.

This is an illustration of the first web service. Understanding this illustration is very important to understand in what is coming. So, pay close attention. Let’s start by the components parts we talked about earlier. Here, the components are the service provider and the service consumer. Think of the client-server model on the web. These service provider and service consumer could be anything as we said before. See what services were created to solve the communication part in distributed programming. Before I continue explaining this illustration, let me talk a little bit about distributed programming. It’s very important to understand in web services.

In distributed programming, the end software or the end system is a set of interlinked components or modules or as we will see later services that are located in different computers and communicate with each other through some protocol. The protocol here is SOAP. A web service is what makes it possible for these components to interoperate and communicate with each other. This web service is language or platform agnostic. What does this mean is that these modules or these components can be built with any programming language or exists in any platform, and they can still communicate with each other easily to achieve a certain functionality or goal in general.

So now, let’s go back to our illustration. As we said before, the two components are the service provider and the service consumer. Just to clarify, the service provider is the module or the component that does the functionality we need. The service consumer is the module or component that asks for it. The third part of this illustration is the history part which is the place where rules of communication exists. In the past, organizations that used distributed programming on the web or on any other network used to create their own web services with their own set of rules. And whenever a service consumer wants to communicate with the service provider, the service consumer needs first to consult the registry and ask for the rules that it needs to properly communicate with the service provider. The illustration explains this very well.

In the first step, the service provider create a set of rules, store them in their registry and says “hey, anyone who wants to talk to me just give them these rules”. After that, whenever a component or a service consumer wants to talk to a service provider or better yet consume service, it needs first to consult the registry and asks for the rules that it needs to properly communicate with the service provider as shown in the second and third steps. And finally, after the service consumer gets the rules, it sends a request to the service provider in a form of XML message. The service provider receives the request, analyzes it, does something, and sends back a response. That’s it! Now, I really don’t know if I explained that very well. But if this still sounds overwhelming and you’re still wondering what the heck is a web service, I promise by the end of this article, you’ll have all the necessary pieces to complete the picture.

Now, let’s talk about why we need web services. When I was talking about the first web service, I kind of gave you some hints and information about why and how the first web service came to exist. Well, that’s only half of the answer. Remember distributed programming and the need to make distributed system components to talk to each other and interoperate. Now more than ever before, the web is a very big and complex world that’s many complex software systems live in. Because there are so many software systems on the web many of which are based on distributed programming. Web services are needed more than ever before. Those systems need to talk to each other to do their job and to give a better user experience. Of course, now with cloud computing, we’ll see a lot of distributed systems and systems based on service-oriented architecture. For sure, web services will play an important role in this. So, web services are like the glue that holds everything together in the web.

Let me give you an example to make this clearer. One example is that if you ever used a web app before that has the sign-up and login features say like “Evernote” for those who don’t know it, it’s note-taking app on the web. This platform lets you create a new account and login using your Google account. That’s not magic. That’s just web services. Here is how it goes. You first go to the platform and click the sign-up button. Then, it shows you a very nice Google sign-up button, and you’re like “thank God, I don’t have to type in my name, the password, confirm and all the painful process”. You just click the Google sign-up button. What will happen after that is platform sends a message, thanks to web services, to a program into Google server which is the service provider and says “hey, someone wants to create an account using his Google info. Can you please send me his name, profile picture and some other stuff.” Then, a small window pops up. It’s Google asking you to allow ordinary requests. I’m sure you have seen something like this before.

This is the service provider asking you whether you want to allow or deny request. This is because Google wants to make sure that this is not a hacker or something that could do some kind of malicious action.

Let’s talk about what web services are exactly. You may be saying “if now you are going to talk about what web services are, what the heck were you talking about until now”. Well, I hope what I talked about before will make it easy to build the proper mental model of web services. So, in this section, I just want to put everything we talked about together and give you a clear and concise definition of what a web service is.

A web service is nothing but a connection technology that allows two or more components also known as Services to interoperate. So, web services are the bridge between components on the web. Each of these components which are actually just programs, these components or these programs do things got other programs need whether it’s some kind of computation, featuring a database, executing scripts, anything that can be achieved with programming.

Let’s talk about how they work. The model of the first web service I showed you before is no longer used. With the advancement of new technologies, it turned out that this model is not efficient, and new models are used. A lot of efforts are being made to standardize one kind of web services. That’s important because this allows for easier exchange of data and a significant reduction of development and maintenance time. Every service on the web can talk to any other service. One kind of this web services is REST web services. Now, most of the organizations adopt and use RESTful services. If you have not enough information about REST architecture or HTTP protocol, you can refer to my previous article.

How they work depends on the web service. What I will talk about here is what they have in common. The first thing we should know about web services is that they harness the power of HTTP. They use HTTP to handle the communication parts. So, web services allow two systems to talk to each other by sending HTTP messages, just a regular HTTP communication. The second thing that I have in common is that they all have to have an agreed upon data format that they will be using to talk to each other. Here is a simple illustration of how this happens.

Here, we have the service provider, service consumer, and the exchange of messages. Think of the HTTP as the envelope, and this HTTP envelope will contain the message that is written in the data format that the service provider and service consumer agreed upon. If you remember in the first web service, the data format was XML. Another thing to note here is that both the service provider and service consumer have the ability to pass the messages and extract meaning from them.

Before I finish, let me tell you what you need to know to build either service providers or service consumers which are also called clients and what you really should know to use web services effectively. First you need to have a solid understanding of the HTTP protocol and now HTTP2. HTTP2 has a lot of great capabilities. It will certainly be great change in web services and in the web generally. Next, you should be familiar with data exchange formats and the most used ones which are XML and JSON. You should know how they work, how you send and receive messages using them, and how to pass them of course. Another important thing is you should try to know about the REST specification, the REST rules. Because most of the communications over the web follow the REST rules. That’s all for this article. Keep Up!