SOAP, REST and the Need of Message Brokers ??

Published in

Nerd For Tech

9 min readMay 14, 2021

Source (https://dzone.com/articles/soap-vs-rest-api-a-comparative-analysis)

When you talk about SOAP and REST, first of all, you need to understand what lead to these two terms. Enterprise Applications are software systems used by large-scale businesses or networks of businesses. They usually involve with,

Persistence of data.
Have a large volume of data.
Accessed by many concurrent users.
Have many user interfaces.
Integrates with other Enterprise Applications scattered around the enterprise or business network.
Interoperable with other enterprise applications.

When we talk about the evolution of enterprise applications architectures, firstly, we had Standalone Mainframe Legacy Systems, then we had 2-tier and 3-tier Client-Server Architecture. Then we move into something called Service Oriented Architecture (SOA).

What is Service-Oriented Architecture (SOA)

Service-Oriented Architecture (SOA) is an architectural style where existing or new functionalities are grouped into atomic services. In other words, service-oriented architecture defines a way to make software components reusable and interoperable via service interfaces. Services use common interface standards and an architectural pattern so they can be rapidly incorporated into new applications. This removes tasks from the application developer who previously re-developed or duplicated existing functionality or had to know how to connect or provide interoperability with existing functions. Some of the main reasons for the invention of the SOA are;

Tight Coupling between local and remote systems requires significant bandwidth demands (eg:- CORBA, EJB, DCOM introduced a highly coupled RPC).
Interoperability Issues mainly due to incompatible data types in different languages (EJB and DCOM were tied to specific platforms and not at all inter-operable).

So how SOAP and REST connected this SOA. SOAP and REST are Web Service approaches that are used as a communication technology to build SOA. SOAP is a Service-Oriented Web Service, and REST is a Resource-Oriented Web Service.

Simple Object Access Protocol (SOAP)

SOAP is a messaging protocol for exchanging structured information as web services in computer networks. Use XML as its messaging format and relies on application layer protocols like Hypertext Transfer Protocol (HTTP) and Simple Mail Transfer Protocol (SMTP) for the transmission. SOAP allows developers to invoke processes running on different operating systems (such as Windows, macOS, and Linux) to authenticate, authorize, and communicate using XML. Since Web protocols like HTTP are installed and running on all operating systems, SOAP allows clients to invoke web services and receive responses independent of language and platforms. SOAP has to work with the UDDI and WSDL for the operation of Service Registry, Service Provider, and Service Consumer functionalities.

WSDL: XML format that describes what are the input and output messages and how these messages should be packaged (bind) to different protocols in the SOAP envelope.
UDDI: UDDI is an XML-based standard for describing, publishing, and finding web services.

Figure 1: Service Registry, Service Provider, and Service Consumer functionalities

Generally, the SOAP message is an XML document consisting of the following elements;

Envelope: Defines the start and the end of the message. It is a mandatory element.
Header: Contains information specific to the application (for example, security or encryption information) that is associated with the SOAP request or response message. It is an optional element.
Body: The XML data that contain the message being transferred. It is a mandatory element.
Fault: An optional Fault element that provides information about errors that occur while processing the message.

SOAP is, by default, synchronous in nature, but depending on different Enterprise Integration Patterns can achieve both synchronous and asynchronous service calls.

Representational State Transfer (REST)

REST is an architectural style where client and server implementation can be independent of each other; this is called separation of concerns. Additionally, the separation allows each component the ability to evolve independently. When different clients hit the same REST endpoints, perform the same actions, and receive the same responses. RESTful services are also stateless, which means the server does not need to know in which state the client is in and vice versa. This is possible through the use of resources. Resources are the objects, documents, or entities that you need to store or send to other services. Because of this, they do not rely on the implementation of interfaces. The REST being an architectural specification, it does not enforce strict rules or official standards that we must follow, as in SOAP.

In the REST architecture, clients will send requests to the server, the server will modify the resources mentioned in the request. Generally, a request consists of;

HTTP request methods that define what kind of operation to perform.
The headers, that allow the client to pass information about the request.
A path to a resource.
An optional message body containing data.

HTTP Request Methods

GET: These requests are used to retrieve data from the server.
POST: This method is used to send an entity to the specified resource, often causing a change in state on the server.
PUT: This method replaces all current representations of the target resource with the request payload. Generally, use to update data.
DELETE: This method is used to deletes a specified resource.
PATCH: This method is used to apply partial modifications to a resource. Used when updating attributes of existing resources in the servers.

These are the main methods used when building CRUD operations in RESTful services. There are some other methods like HEAD, CONNECT, OPTIONS, and TRACE. You can find more details about those in https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods.

Headers

In the header of the request, Accept field represent; the type of content the server can send in responses. It will ensure that the server will not send data that doesn’t understand by the client.

When sending data payload to the client, the server must include a Content-Type in the header of the response. This content-type header informs the client what type of data is receiving inside the response. The content type that the server sends back in the response should match with the accept field client specified in the request.

The Client sets the Accept field in the Request Header

The Server sets the Content-Type field in the Response Header

Path

Requests should contain a path to a resource in RESTful API operations, and those paths should be designed to help the client understand what is going on. If you are making a get request to retrieve a user with ID 10, Path should be GET fashionbug.com/user/:id. Where “: id” is the route parameter we pass when calling the GET request.

Response Codes

HTTP response status codes help the client to identify whether an HTTP request has been successful or not. Responses are grouped into five classes as below;

Informational Responses (100–199)
Successful Responses (200–299)
Redirects (300–399)
Client Errors (400–499)
Server Errors (500–599)

Important Points

🔸 In HTTP 1.0, it used a short-lived connection for every request. For every request, a new connection was created and then close after the response was received. The main problem was it eats up the time for opening and closing of connections. Apart from that, HTTP 1.0 respond to the request in the order they were received.

🔸 As a solution to this, HTTP 1.1 introduced persistent connection and pipelining. Persistent connection keeps the connection open between successive requests, reducing the time needed to open new connections. The pipelining helps to send several requests without even waiting for an answer, reducing much of the latency in the network. But HTTP 1.1 done these modifications on top of HTTP 1.0 since there are no breaking changes. Therefore even though several successive requests are sent to the server, it replies to them in the order they were received.

🔸 Therefore although the RESTful Architecture specifies it provides asynchronous communication since it is using HTTP 1.1 as the protocol, REST APIs design by us still works synchronously. To achieve asynchronous nature, we have to use intermediate service call Message Brokers.

Message Brokers

The Message Broker enables applications and services to communicate with each other and exchange information. Message Broker does this by translating messages between formal messaging protocols. This allows interdependency, even if they were written in different languages or implemented on different platforms. Most importantly, it helps to achieve;

loosely coupled communication
Asynchronous messaging
Reliable delivery (A message is guaranteed to be delivered once and only once).

Message brokers can validate, store, route, and deliver messages to the appropriate destinations using messaging middleware or message-oriented middleware (MOM) solutions. It acts as an intermediate between the other applications. Therefore, the sender can send messages without knowing where the receiver’s location and without worrying about their active status. This facilitates the decoupling of processes and services within systems. Message Brokers offer two different styles of messaging called Point-to-Point and Publisher/Subscriber messaging.

Point-to-Point Messaging

In the Point-to-Point model, one message is delivered to one receiver only. As the message-oriented middleware (MOM), a Queue is used. The Queue is responsible to hold the messages until the receiver is ready. The sender and receiver have no timing dependencies. The receiver can fetch the message whether or not it was running when the client sent the message.

Publisher/Subscriber (Pub/Sub) Messaging

In Pub/Sub model, one message is delivered to all the subscribers. It is like broadcasting. As the message-oriented middleware, a Topic is used. The topic is responsible to hold and deliver the messages. Publishers and Subscribers have timing dependency. A client can consume only messages published after its subscription and must continue to be active to consume the messages.

There are different kinds of message brokers available in the market, such as Kafka, RabbitMQ, Amazon SQS, Google Pub/Sub, etc. An overview of each of these message brokers is listed below.

Apache Kafka

It was originally designed as a messaging queue. The software quickly grew popular as an event streaming platform. Wherever there is a requirement for message queuing or a message broker system, Kafka is a good option. Some of the main features are listed below;

Allows publishing and subscribing to streams of records.
Records streams are stored using a fault-tolerant approach.
Allows the decoupling of applications.
It is easily available.
When managing real-time data transfers, it offers high throughput.
Support only Asynchronous Communications.

RabbitMQ

Written in Erlang, it was originally designed for Advanced Message Queuing Protocol (AMQP) but has been updated to support other protocols, including STOMP and MQTT. Some of the main features are listed below;

Messaging techniques like pub-sub, point-to-point, and request-reply messaging are supported.
Can achieve both synchronous and asynchronous modes of communication.
Ensure reliability delivery acknowledgments.
By replicating queues across multiple nodes of a cluster assures high availability. Therefore messages aren’t lost even in the case of a hardware failure.

Amazon SQS

Amazon SQS is a fully managed distributed message queuing service offered by Amazon. It’s cost-effective and offers simple techniques to manage communication between software components of a system running in the cloud. Some of the main features are listed below;

Automatically scale to the size of the workload.
Only pay for the messages you read and write as your requirements grow.
You can choose between standard and FIFO queues.
FIFO queues ensure message delivery and process exactly once, in the order that they are sent.
“Dead Letter” queue help to maintain unprocessed messages.
Support both Synchronous and Asynchronous communications.

Google Pub/Sub

Google Cloud Pub/Sub is an asynchronous messaging service for sending and receiving messages between independent applications. It is the perfect application for distributing event notifications, streaming data from different devices due to the reliable message storage and low latency for real-time message delivery. Some of the main features are listed below;

It offers low latency and high throughput.
Both push and pull message deliveries are supported.
Highly reliable since every message is stored on multiple servers.
Highly scalable, with support for 10,000 messages per second
Messages delivered and in storage are encrypted.
Support only Asynchronous communications.

References

For further more clarification check these resources;