Everything about SOAP, REST, and Message Brokers

Web Services

Services offered through the Web-wide standardized protocols.

Standard definition:

A Web service is a software application identified by a URI, whose interfaces and bindings are capable of being defined, described, and discovered as XML artifacts. A web service supports direct interactions with other software agents using XML-based messages exchanged via internet-based protocols(TCP, UDP).

Why do we need web services?

• Expose the existing functions onto a network.
• Interoperability (Connect different Applications).
• Standardized Protocol.

Characteristics of Web Services

• XML-Based
• Loose Coupled
• Ability to be Synchronous or Asynchronous
• Supports RPCs(Remote Procedure Calls)
• Supports Document Exchange

Benefits of web services

• Platform independence(Hardware, OS).
• Programming language neutrality.
• Uses low-cost communication(SOAP over HTTP).

Types of Web Services

1. Service-Oriented web Services — SOAP
2. Resource-Oriented Web Services — REST

SOAP ( Simple Object Access Protocol )

• SOAP is an XML-based protocol for exchanging information between applications. It is basically a specification of how web services should talk to each other.
• RPC ( Remote Procedure Call ) is the most popular standard that is used for implementing the client-server architecture.
• There are many RPC protocols but most of them are too low level and not compatible with each other. Therefore most of the firewalls will block this traffic. SOAP USES HTTP/SMTP as the communication protocol to avoid this problem
• There are 3 basic rules that a web service should follow in order for it to be a SOAP web service — SOAP, WSDL, UDDI

How SOAP works?

At the Client —

• Turns the RPC call into an XML document.

Transports the XML data over HTTP/SMTP (Client to Server)

At the Server —

• Turns the XML document into a procedure call.
• Turns the procedure’s response into an XML document.

Transports the XML data over HTTP/SMTP(Server to Client)

At the Client —

• Turns XML data back to RPC.

A SOAP message contains 2 main parts

1. SOAP Header
2. SOAP Body

The Soap header is optional and the Soap body is mandatory.

SOAP Header

This is a generic placeholder for information that is not necessarily application-dependent. Application may not be even aware of the fact that the header is attached to it.

Typically used to store —

• Identifiers
• Security information(eg- certificates)

SOAP Body

Intended for application-specific data. It may also contain a “Fault entry section”. This section is there for reporting errors (processing of the SOAP message).

Disadvantages of SOAP

• Only support XML.
• Tight coupling between client and server.
• Slower than REST.

RESTful Web Services

Refers to the web services that are based on the REST(Representational State Transfer) Architecture. In the REST architecture, everything is a resource. These web services are lightweight, highly scalable, and maintainable and are commonly used to create APIs.

REST Design Principles

1. Everything is a Resource.
2. Each Resource is identifiable by a unique URI.
3. Use standard HTTP methods.
4. Allow multiple representations for the same recourse.
5. Communication should always be stateless.

SOAP VS REST

• REST is more dynamic.
• REST is not restricted to XML format. REST services can easily send plain text, JSON, and also XML.
• REST is an architectural style. SOAP is a Protocol.
• REST has better performance and scalability compared to SOAP.

HTTP (HyperText Transfer Protocol)

This is a communication protocol that powers most of our everyday interactions on the internet. It is maintained by the Internet Engineering Task Force.

HTTP IS NOT REQUIRED FOR A RESTFUL SYSTEM.

HTTP is very popular in building modern APIs. That is because HTTP provides a consistent and predictable way to access and manipulate remote data. HTTP also allows clients to choose different representations for some resources. There it WORKS WELL WITH REST ARCHITECTURE.

HTTP also provides the same set of methods for every resource. This again adheres to the principles of REST. There are 4 main HTTP methods.

• POST — create
• GET — Retrieve
• PUT — Update
• DELETE — Delete

HTTP is a Request/Response Protocol.

HTTP Status Codes

These codes are used to convey the results of a client request. There are 5 main categories.

• 100–200: Informational Messages
• 200–300: Success Messages
• 300–400:Redirect Messages
• 400–500: Client Errors
• 500–600: Server Errors

HTTP 1.0 VS HTTP 1.1

HTTP 1.0 uses a TCP connection for every request. This is very costly because for each and every request we need a new TCP connection. Some 1.0 implementations used a “keep-alive” header to request a connection to persist.

HTTP 1.1 solved this problem by introducing persistent connections and pipelining requests on a persistent connection. The connections are persistent by default. HTTP 1.1 also allows the connections to be closed at any given time. In this version, we can transmit multiple requests over a TCP connection. The Client does not need to wait for a response before sending another. However, the server must still send the responses of a particular connection in the order of the matching request.

What is the issue with this behavior?

Example —

• Assumption: There are 3 different requests namely A, B, and C. A takes 100ms to and B takes 50ms to process. C takes 10ms to process at the server. If we send all these requests simultaneously, what is the time it takes to receive a response from the server? (Assume that the transmission time is 0ms)

Answer:

100ms. why?

Even though B, C finished execution before A, the response will be sent according to the received order. A received first and it will take 100ms to process. Therefore after 100ms, the response will be sent back to the client. To overcome this problem, we use Message Brokers.

REST Behavior

REST can be implemented synchronously or asynchronously. However, the underline communication protocol plays a vital role in maintaining this asynchronous nature. If the used communication protocol is synchronous(ex- HTTP) in nature, then the structure will be synchronous.

Synchronous REST

Used in situations where the service availability is high and low latency is a priority.

However, the main disadvantage of using this method is that the client has to wait for the API call to return before the continuation of code execution.

Asynchronous REST

Now the question arises on how to make the REST act asynchronously. To achieve this task, we can use a Message Broker.

Message Broker/ Integration broker

Intermediary computer program module that translates a message from the sender’s message protocol to the receiver's messaging protocol.

Examples —

• AWS AMAZON MQ
• Apache Kafka
• WSO2 Message broker
• Java JMS — API provided by Java

Message brokers also allow different services to communicate with each other, even if they are written in different programming languages. They basically act as intermediaries between applications.

Message brokers have “message queues” which can be used to store the message in the exact transmitted order. Therefore it supports asynchronous messaging. The sender does not need to wait for the receiver’s reply. In addition to this, the use of Message brokers also improves the scalability and fault tolerance of the overall system.

Message Broker Models

• There are 2 main Message broker models available.

Point-to-Point Messaging

In a point-to-point messaging system, the messages are persisted in the queue and one or more consumers can consume the messages in the queue. But a single message can be consumed by a single consumer only.

Example: Order processing system.

• One order will be processed by one processor.
• Multiple processors can work at the same time.

2. Publish/ Subscribe Messaging

In publish/subscribe messaging system, each message publishes it to a topic. Messages are persisted in this topic. Message consumers subscribe to topics from which they intend to receive messages. This is a broadcast-style distribution model.

Apache Kafka

Kafka is the most famous open-source Message broker in the market. It is a distributed publish-subscribe messaging system. It is ideal for both online and offline message consumption. Kafka uses a robust queue that can handle large volumes of data. This makes it possible to exchange messages from one point to another in a minimum time.

Key benefits of Kafka —

• Scalability
• Reliability
• Durability
• Performance

Kafka vs RabbitMQ

RabbitMQ is another famous Message broker. However, Apache Kafka has significant benefits over RabbitMQ.

• Kafka provides message ordering because of its partitions. In RabbitMQ, there are no partitions.
• Kafka act as a log. Therefore messages are always there. However, RabbitMQ act as a queue, and messages are removed after they are consumed.
• Kafka guarantees atomicity. It guarantees that either the whole batch of messages passes or fails. RabbitMQ does not guarantee atomicity.
• Kafka offers much higher performance than RabbitMQ. The use of sequential disk I/O by Kafka is the main reason for this.

Kafka is widely used for stream processing scenarios. Activity tracking, log aggregation, event sourcing are some of the popular Kafka use cases.

RabbitMQ is widely used by web servers that need quick responses to its requests. This is used by applications that need to support legacy protocols and also by applications that need to handle complex routing scenarios. So it's clear to us that even though their architecture is different, each performs better in certain environments.

Java Messaging Service (JMS)

This is another famous Messaging Service designed by Sun Microsystems. The main aim of developing this Messaging service is to easily develop applications that asynchronously send and receive business data and events. JMS supports both the point-to-point messaging model and the publish-subscribe messaging model. A JMS application consists of 4 main parts.

1. JMS Provider: Messaging system that implements the JMS specification.
2. JMS Clients: Java applications that send and receive messages.
3. Messages: Objects that are used to communicate information between JMS clients.
4. Administered Objects: Preconfigured JMS objects created by an admin.

WSO2 Message Broker (wso2 MB)

A highly available message broker introduced by WS02. Currently, this message broker is within the WS02 Enterprise Integrator. This Message broker is 100% open source and has the ability to easily scale up to multiple clusters without a single point of failure. WSO2 message broker also supports JSM 1.0 and 1.1 versions. Interoperability with many languages and platforms is the key feature of this Message broker. This is done using AMQP (Advanced Message Queuing Protocol) clients.

References —

Getting Started with Java Message Service (JMS)

Apache Kafka - Introduction

What are Message Brokers?

Marrying RESTful HTTP with Asynchronous and Event-Driven Services

Difference Between REST and HTTP | Baeldung on Computer Science