- A web service is software that exposes itself on the network and uses some standardized format to talk to another machine.
- Webservices are distributed dynamic applications that can be located on the network.
- Webservice is not tied to any particular operating system.
- A web service can carry data to other services, and this is called Payload.
Types of Payload Data
Commonly two types of data are used as the payload in the web services: XML and JSON data. Let’s look at both:
JSON
JSON stands for JavaScript Object Notation. It is used to describe JavaScript objects. It is a data-sharing format that specifies data values using key-value pairs. The JSON object is supported across all major browsers. The JSON format is also used to transmit data across the network. For this purpose, data needs to be serialized and deserialized.
To summarize:
To summarize:
- Key/value pairs
- Each pair is separated by commas
- Curly braces encapsulate objects
- Square brackets encapsulate arrays
- Arrays are called JSON Arrays
- JSON arrays hold JSON objects.
- A JSON object can contain another JSON object. This is called Nested JSON Objects.
Suppose we want to save the name and age of any person to remote service. If we convert this data into JSON it will look something like the below:
{ name: XYZ, age: 32 }
Now suppose if we want to send multiple values to a remote server then we will need to send a collection of JSON objects. This is called JSON Array. Below is an example of a JSON Array:
[{ name: XYZ, age: 32 }, { name: ABC, age: 32 }]
XML
XML stands for Extensible Markup Language. This XML format is very similar to HTML but allows developers to specify their tags rather than sticking to predefined tags. An XML document uses these tags to define the data and the format of the data. XML is a powerful way to store, transfer, and search data. XML document also allows adding comments to the data which is not supported by the JSON format.
For a valid XML, the document must be well-formatted. It must conform to XML syntax rules.
For a valid XML, the document must be well-formatted. It must conform to XML syntax rules.
<?xml version="1.0" encoding="UTF-8"?>
<message>
<name>XYZ</name>
<age>32</age>
</message>
If suppose more than one names need to be sent, then the message would look like below:
<message>
<object>
<name>XYZ</name>
<age>32</age>
</object>
<object>
<name>ABC</name>
<age>32</age>
</message>
Notice that the XML document uses more characters in terms of text than JSON.
Now that you are aware of the web services and their payloads, let us look at the two types of web services commonly used today: SOAP and REST Web Services.
Notice that the XML document uses more characters in terms of text than JSON.
Now that you are aware of the web services and their payloads, let us look at the two types of web services commonly used today: SOAP and REST Web Services.
SOAP Web Service
SOAP stands for Simple Object Access Protocol. SOAP service is an XML-based service used to establish communications between two applications. SOAP uses WSDL for communication between consumers and providers. WSDL stands for Web Service Description Language. WSDL allows for service discovery over the network. The SOAP request consists of an XML payload and the response is also in the XML format. SOAP services send the message over the HTTP protocol. SOAP is a W3C recommendation and is platform and language independent.
While the SOAP services are secure and descriptive, they are often less preferred than REST services. This is because SOAP service is complicated to build and maintain. SOAP service is slow in operations. SOAP service is dependent on XML and therefore language restricted.
While the SOAP services are secure and descriptive, they are often less preferred than REST services. This is because SOAP service is complicated to build and maintain. SOAP service is slow in operations. SOAP service is dependent on XML and therefore language restricted.
REST Web Service
REST stands for REpresentational State Transfer. A REST service allows data to be transferred between two machines using any format of the choice such as XML, JSON, or plain text. It is lightweight than SOAP because it does not contain any WSDL definitions. Rather the service contract is highly dynamic. Communication happens over the HTTP protocol. REST service uses HTTP verbs such as POST, GET, PUT, etc. REST web service is supported by all the popular programming languages and frameworks. Additional information such as security or type of content is passed in the request header.
Protobuf
Protobuf is a new open-source format for serializing structured data. It stands for Protocol Buffer. Protobuf is an open cross-platform format and is available for all popular high-level languages. Even if you are working with C++, Protobuf has you covered using the Protobuf C++ library. With proto3 language version, one can also work with Dart, Go, Ruby, and C#, with more languages to come. Protobuf is different from both JSON and XML as it is a smaller, more maintainable, and structured way of sending data. Protobuf however is non-human readable since it is a binary format. Another disadvantage of Protobuf is that it is newer than XML or JSON so not a lot of resources or community is present.
Microservices
Since web services allow remote machines to talk to each other and exchange data, it leads us to Microservices. This is when we divide a large application into smaller components that are more manageable and concerned with their use case. But to remain connected to each other for dependency they use web services to communicate to other machines. A single large application can be broken down into smaller components called microservice and there can be as many microservices as needed even hundreds of microservices can be there.
The opposite of the Microservices can be considered monolithic architecture. Monolithic architecture remained in use for a long time to build the applications. However, when building large applications this architecture was not feasible as a small change would need the whole application to be deployed. Also, because there was no separation of concerns among different components of the application, any change could break the current fully functional features. This is where Microservices found their way.
The opposite of the Microservices can be considered monolithic architecture. Monolithic architecture remained in use for a long time to build the applications. However, when building large applications this architecture was not feasible as a small change would need the whole application to be deployed. Also, because there was no separation of concerns among different components of the application, any change could break the current fully functional features. This is where Microservices found their way.
Asynchronous Communications
To understand it, consider a self-servicing restaurant. You go to the counter and order some food. Now the food will take some time to get ready. You go back to your table and maybe start reading the newspaper or continue making your sales phone calls. When the food is ready, you receive the message. So, you pick it up and leave. This is an example of asynchronous communication.
In asynchronous communication, a machine sends a request to another machine. The other machine takes some time in processing this request. Meanwhile, the sender machine does not wait for the response and moves on. When the second machine is done with its processing, it notifies the sender machine that the output is ready. The sender machine then picks up the response and moves on.
This type of communication is ideal when the response is not needed in real-time such as storing data or backend processing of financial services.
In general, to achieve asynchronous communication a message broker technology is used such as Apache Kafka, RabbitMQ, etc. These technologies allow asynchronous messaging by enabling one machine to publish its message to the queue of the second machine. The second machine picks this message, processes it, and puts the response back to the queue of the first machine. The first machine finally then picks up the response and does whatever it needs to with it.
In asynchronous communication, a machine sends a request to another machine. The other machine takes some time in processing this request. Meanwhile, the sender machine does not wait for the response and moves on. When the second machine is done with its processing, it notifies the sender machine that the output is ready. The sender machine then picks up the response and moves on.
This type of communication is ideal when the response is not needed in real-time such as storing data or backend processing of financial services.
In general, to achieve asynchronous communication a message broker technology is used such as Apache Kafka, RabbitMQ, etc. These technologies allow asynchronous messaging by enabling one machine to publish its message to the queue of the second machine. The second machine picks this message, processes it, and puts the response back to the queue of the first machine. The first machine finally then picks up the response and does whatever it needs to with it.
Synchronous Communications
This communication is opposite to Asynchronous Communication. To understand this, consider an example of bill payment. You go to some bank and then submit your bill and the cash. The bank processes the bill, prepares the final receipt for you, and then hands over the receipt to you. You pick up the receipt and then leave. However, during this time, you wait at the bank counter. This is how synchronous communication works.
Here one machine sends the request to another machine and then waits. The second machine processes this request and then sends back the response. There can be a lag of some milliseconds between request and response, but the communication is not broken. Regardless of application latency, the requester cannot move forward.
This type of communication is ideal when the requesting machine needs the response in real-time such as online payment, shopping cart, or emails.
This communication is achieved by SOAP or REST communication over HTTP protocol or gRPC. The gRPC is an advanced open-source remote procedure calling framework.
Here one machine sends the request to another machine and then waits. The second machine processes this request and then sends back the response. There can be a lag of some milliseconds between request and response, but the communication is not broken. Regardless of application latency, the requester cannot move forward.
This type of communication is ideal when the requesting machine needs the response in real-time such as online payment, shopping cart, or emails.
This communication is achieved by SOAP or REST communication over HTTP protocol or gRPC. The gRPC is an advanced open-source remote procedure calling framework.
Cloud Computing
This leads us to our final topic Cloud Computing. Cloud computing is how computing is done these days in most public applications. Once you have microservices, it requires that the services be brought up and down as needed along with the infrastructure and the needed resources and components to run the application. Cloud computing provides the solution to this need, enabling developers to have one point for all their application needs, providing them with servers, operating systems, serverless applications support, emails, event messaging, databases, caching, and much more, right from a single console.
Cloud computing is a whole subject on its own. Cloud infrastructures are used not only for microservices for many diverse and large variety of use cases. Based on the needs and type of application being developed there are Four Different Types of Cloud Computing Services available from the popular Cloud vendors.
Cloud computing is a whole subject on its own. Cloud infrastructures are used not only for microservices for many diverse and large variety of use cases. Based on the needs and type of application being developed there are Four Different Types of Cloud Computing Services available from the popular Cloud vendors.
Conclusion
This was a long blog. We started from web services, remote communication, types of communications to serializing and deserializing of data, learning about Protobuf, and finally the basis of the latest architectural pattern of microservices for building applications.