SOAP, REST and the Need of Message Brokers ??

Ranmal Dewage
May 14 · 9 min read
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)

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

  • 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.
WSDL Representation in XML
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.

Figure 2: SOAP Message Overview
SOAP Message in XML Format

Representational State Transfer (REST)

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

  • 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

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

Response Codes

  1. Informational Responses (100–199)
  2. Successful Responses (200–299)
  3. Redirects (300–399)
  4. Client Errors (400–499)
  5. Server Errors (500–599)
Figure 3: Comparison of SOAP vs REST

Important Points

🔸 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

  • 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

Figure 4: Point-to-Point Messaging

Publisher/Subscriber (Pub/Sub) Messaging

Figure 5: Publisher/Subscriber (Pub/Sub) Messaging

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

  • 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

  • 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

  • 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

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

Nerd For Tech

From Confusion to Clarification

Nerd For Tech

NFT is an Educational Media House. Our mission is to bring the invaluable knowledge and experiences of experts from all over the world to the novice. To know more about us, visit https://www.nerdfortech.org/. Don’t forget to check out Ask-NFT, a mentorship ecosystem we’ve started

Ranmal Dewage

Written by

Software Engineer at Virtusa, Graduate of Sri Lanka Institute of Information Technology (SLIIT).

Nerd For Tech

NFT is an Educational Media House. Our mission is to bring the invaluable knowledge and experiences of experts from all over the world to the novice. To know more about us, visit https://www.nerdfortech.org/. Don’t forget to check out Ask-NFT, a mentorship ecosystem we’ve started

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store