Everything about SOAP, REST, and Message Brokers

Web Services

Services offered through the Web-wide standardized protocols.

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?

  • Turns the procedure’s response into an XML document.
  1. SOAP Body

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.

  • Security information(eg- certificates)


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.


  • 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.

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

HTTP Status Codes

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

  • 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.

What is the issue with this behavior?

Example —

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.

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.

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

Message Broker Models

  • There are 2 main Message broker models available.

Point-to-Point Messaging

  • Multiple processors can work at the same time.

2. Publish/ Subscribe Messaging

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.

  • Reliability
  • Durability
  • Performance

Kafka vs RabbitMQ

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

  • 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.

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 Clients: Java applications that send and receive messages.
  2. Messages: Objects that are used to communicate information between JMS clients.
  3. 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.

Associate Software Engineer at Virtusa