SOA, SOAP & Rest API

Introduction

15 min readFeb 25, 2021

The pace at which computer systems change was, is, and continues to be overwhelming. From 1945, when the modern computer era began, until about 1985, computers were large and expensive. Moreover, for lack of a way to connect them, these computers operated independently from one another.

Starting in the mid-1980s, however, two advances in technology began to change that situation. The first was the development of powerful microprocessors. Initially, these were 8-bit machines, but soon 16-, 32-, and 64-bit CPUs became common. With multicore CPUs, we now are reaching the challenge of adapting and developing programs to exploit parallelism. In any case, the current generation of machines have the computing power of the mainframes deployed 30 or 40 years ago, but for 1/1000th of the price or less.

The second development was the invention of high-speed computer networks. Local-area networks or LANs allow thousands of machines within a building or campus to be connected in such a way that small amounts of information can be transferred in a few microseconds or so. Larger amounts of data can be moved between machines at rates of billions of bits per second (bps). Wide-area networks or WANs allow hundreds of millions of machines all over the earth to be connected at speeds varying from tens of thousands to hundreds of millions bps, and sometimes even faster.

Parallel to the development of increasingly powerful and networked machines, we have also been able to witness miniaturization of computer systems with perhaps the smartphone as the most impressive outcome. Packed with sensors, lots of memory, and a powerful CPU, these devices are nothing less than full-fledged computers. Of course, they also have networking capabilities. Along the same lines, plug computers and other so-called Nano computers are finding their way to the market. These small computers, often the size of a power adapter, can often be plugged directly into an outlet and offer near-desktop performance.

The result of these technologies is that it is now not only feasible, but easy, to put together a computing system composed of many networked computers, be they large or small. These computers are generally geographically dispersed, for which reason they are usually said to form a distributed system. The size of a distributed system may vary from a handful of devices, to millions of computers. The interconnection network may be wired, wireless, or a combination of both. Moreover, distributed systems are often highly dynamic, in the sense that computers can join and leave, with the topology and performance of the underlying network almost continuously changing. In this paper, we provide a brief introduction to distributed systems, covering material from the past decades, in addition to looking toward what the future may bring us.

SOA

A service-oriented architecture (SOA) is an architectural pattern in computer software design in which application components provide services to other components via a communications protocol, typically over a network. The principles of service-orientation are independent of any product, vendor or technology. SOA just makes it easier for software components over various networks to work with each other.

Web services which are built as per the SOA architecture tend to make web service more independent. The web services themselves can exchange data with each other and because of the underlying principles on which they are created, they don’t need any sort of human interaction and also don’t need any code modifications. It ensures that the web services on a network can interact with each other seamlessly.

SOA is based on some key principles which are mentioned below

Standardized Service Contract — Services adhere to a service description. A service must have some sort of description which describes what the service is about. This makes it easier for client applications to understand what the service does.

Loose Coupling — Less dependency on each other. This is one of the main characteristics of web services which just states that there should be as less dependency as possible between the web services and the client invoking the web service. So if the service functionality changes at any point in time, it should not break the client application or stop it from working.

Service Abstraction — Services hide the logic they encapsulate from the outside world. The service should not expose how it executes its functionality; it should just tell the client application on what it does and not on how it does it.

Service Reusability — Logic is divided into services with the intent of maximizing reuse. In any development company re-usability is a big topic because obviously one wouldn’t want to spend time and effort building the same code again and again across multiple applications which require them. Hence, once the code for a web service is written it should have the ability work with various application types.

Service Autonomy — Services should have control over the logic they encapsulate. The service knows everything on what functionality it offers and hence should also have complete control over the code it contains.

Service Statelessness — Ideally, services should be stateless. This means that services should not withhold information from one state to the other. This would need to be done from either the client application. An example can be an order placed on a shopping site. Now you can have a web service which gives you the price of a particular item. But if the items are added to a shopping cart and the web page navigates to the page where you do the payment, the responsibility of the price of the item to be transferred to the payment page should not be done by the web service. Instead, it needs to be done by the web application.

Service Discoverability — Services can be discovered (usually in a service registry). We have already seen this in the concept of the UDDI, which performs a registry which can hold information about the web service.

Service Compos ability — Services break big problems into little problems. One should never embed all functionality of an application into one single service but instead, break the service down into modules each with a separate business functionality.

Service Interoperability — Services should use standards that allow diverse subscribers to use the service. In web services, standards as XML and communication over HTTP is used to ensure it conforms to this principle.

How work SOA

To understand SOA, consider the architecture commonly found on college campuses: the data-oriented system. In a data-oriented system, campus departments share information by sending it in batch-file transfers from one department to another. For example, the library might need to check individuals who wish to borrow materials to find out if they are full-time students. To do so, the library would query the student records department, which, in the case of UW–Madison, would send all 45,000 student records in a batch. The library would then load the batch into its system’s database, simply to locate the data it needs for a small subset of those students.

Research firm Adventure notes that university departments can easily misinterpret data sent by batch transfers because departments use different business rules or different versions of data to suit their unique needs. Recreational facilities, for example, might define a current student as one who is enrolled and has paid all college fees and is therefore authorized to use campus facilities. The library, on the other hand, might define a current student — one eligible to check out books — as one who is enrolled but has not necessarily paid all fees. Such differences can create obvious data-accuracy problems and minimize the usefulness of information.

The fact that the batch-file method includes all possibly needed data increases the security risk and places a large burden on already strained computing resources. Batch-file transfers inherent can be cumbersome, time-consuming processes prone to errors. As departments transfer batch files across campus, different “versions of truth” begin to circulate. In contrast, SOA is based on a service-level agreement between a service owner (source) and the service consumer. The transaction between the two is tracked at all points.

Pros and Cons of SOA

Pros :

Service Reusability

In SOA, an application is built by assembling small, self-contained, and loosely coupled pieces of functionality. Therefore, the services can be reused in multiple applications independent of their interactions with other services.

2. Easy Maintainability

Since a service is an independent entity, it can be easily updated or maintained without having to worry about other services. Large, complex applications can thus be managed easily.

3. Greater Reliability

SOA-based applications are more reliable since small, independent services are easier to test and debug as compared to massive chunks of code.

4. Location Independence

The services are usually published to a directory where consumers can look them up. This approach allows a service to change its location at any time. However, the consumers are always able to locate their requested service through the directory look up.

5. Improved Scalability and Availability

Multiple instances of a single service can run on different servers at the same time. This increases scalability and availability of the service.

6. Improved Software Quality

Since services can be reused, there is no scope for redundant functionality. This helps reduce errors due to inconsistent data, and thereby improves the quality of code.

7. Platform Independence

SOA facilitates the development of a complex product by integrating different products from different vendors independent of the platform and technology.

8. Increased Productivity

Developers can reuse existing legacy applications and build additional functionality without having to develop the entire thing from scratch. This increases the developers’ productivity, and at the same time, substantially reduces the cost of developing an application.

Cons

Ø Increased Overhead

Every time a service interacts with another service, complete validation of every input parameter takes place. This increases the response time and machine load, and thereby reduces the overall performance.

Ø Complex Service Management

The service needs to ensure that messages have been delivered in a timely manner. But as services keep exchanging messages to perform tasks, the number of these messages can go into millions even for a single application. This poses a big challenge to manage such a huge population of services.

Ø High Investment Cost

Implementation of SOA requires a large upfront investment by means of technology, development, and human resource

Example of SOA

To deliver services outside the firewall to new markets: First Citizens Bank not only provides services to its own customers, but also to about 20 other institutions, including check imaging, check processing, outsourced customer service, and “bank in a box” for getting community-sized bank everything they need to be up and running. Underneath these services is an SOA-enabled mainframe operation.

To provide real-time analysis of business events: Through real-time analysis, OfficeMax is able to order out-of-stock items from the point of sale, employ predictive monitoring of core business processes such as order fulfilment, and conduct real-time analysis of business transactions, to quickly measure and track product affinity, hot sellers, proactive inventory response, price error checks, and cross-channel analysis.

To streamline the business: Whitney National Bank in New Orleans built a winning SOA formula that helped the bank attain measurable results on a number of fronts, including cost savings, integration, and more impactful IT operations. Metrics and progress are tracked month to month — not a “fire-and-forget business case.”

To improve federal government operations: The US Government Accountability Office (GAO) issued guidelines intended to help government agencies achieve enterprise transformation through enterprise architecture. The guidelines and conclusions offer a strong business case for commercial businesses also seeking to achieve greater agility and market strength through shared IT services. As GAO explains it, effective use of an enterprise architecture achieves a wide range of benefits.

To improve state and local government operations: The money isn’t there to advance new initiatives, but state governments may have other tools at their disposal to drive new innovations — through shared IT service. Along these lines, a new study released by the National Association of State Chief Information Officers (NASCIO), TechAmerica and Grant Thornton, says well-managed and focused IT initiatives may help pick up the slack where spending is being cut back.

To improve healthcare delivery: If there’s any sector of the economy that desperately needs good information technology, that’s the healthcare sector — subject to a dizzying array of government mandates, fighting cost overruns at every corner, and trying to keep up with the latest developments in care and protocols.

SOAP

Simple Object Access Protocol, as the name says, is a standard protocol intended to exchange structured messages in a decentralized, distributed environment. SOAP is a protocol based on XML to exchange messages across the internet. It has a set of rules which define and describe the messaging format and processing rules for information exchanged between the sender and receiver. SOAP can use two different transfer protocols to exchange the messages: HTTP (Hypertext Transfer Protocol) and SMTP (Simple Mail Transport Protocol), but the most popular protocol used by SOAP services is HTTP. Below we have a SOAP Request message as well as an example of the SOAP message structure:

OST /soap/event HTTP/1.1

Content-Length: 309

SOAPAction: ”getEvent”

Content-Type: text/xml;charset=utf-8

Host: ems-sv258:1774

Connection: Keep-Alive<?xml version="1.0" ?>

<soapenv:Envelope

    xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"

    xmlns:xsd="http://www.w3.org/2001/XMLSchema"

    xmlns:ns1="http://soap.com/act">

    <soapenv:Body>

       <ans:getNote xmlns:ans="http://soap.com/act">

          <eventID>1000</eventID>

       </ans:getNote>

    </soapenv:Body>

</soapenv:Envelope>

Since SOAP standards for message exchange are based on XML and usually use HTTP as a transport protocol, it is possible to communicate between different applications with different operational systems.

One specific characteristic of SOAP is the coupling between the service provider (server) and the service consumer (client). There is a rigid contract between the server and client in SOAP and the consumer must know the exact message structure to send to the server. If anything changes on either side, client or server, it will break the communication.

Another important characteristic of SOAP is its association with Web Service Description Language (WSDL). The WSDL has the description of SOAP service and how it works. This makes the client building process easier once IDEs and frameworks can be utilized to automate the implementation based on WSDL.

SOAP also has built-in error handling. When any message has an error or is missing required information, the error response message contains information about what is wrong and can be used by the client to fix the problem. This is very important to consumers when they are not the owner of the service, otherwise, the client won’t be able to understand what is wrong with the request.

How to work SOAP

SOAP primarily uses the standard HTTP request/response model (see Figure A).

The client wraps a method call in SOAP/XML, which is then posted over HTTP to the server. The XML request is parsed to read the method name and parameters passed and delegated for processing. The XML response is then sent back to the client, containing the return value — or fault data — of the method call. Finally, the client may parse the response XML to make use of the return value.

But HTTP is not the only transfer protocol that SOAP supports. In version 1.1 of SOAP, the specification was expanded to cover other transfer protocols such as Simple Mail Transfer Protocol (SMTP), File Transfer Protocol (FTP), or any other protocol that can transfer text. These other protocols could be used to make asynchronous SOAP calls, meaning the client application could invoke the SOAP service but would not have to wait for a response from the server.

Cons and Pros

Pros

1. WS Security: SOAP defines its own security known as WS Security.

2. Language and Platform independent: SOAP web services can be written in any programming language and executed in any platform

Cons

1. Slow: SOAP uses XML format that must be parsed to be read. It defines many standards that must be followed while developing the SOAP applications. So it is slow and consumes more bandwidth and resource.

2. WSDL dependent: SOAP uses WSDL and doesn’t have any other mechanism to discover the service.

Example of SOAP

In order to call a SOAP API, you’ll most likely need to include a SOAP library with your programming language. Although it’s possible to make SOAP API calls without SOAP libraries, it’s more efficient to work with an abstraction rather than crafting the messages yourself. The SOAP messages are verbose, mainly due to reliance on XML.

While the following examples use Python for readability, remember that SOAP is agnostic regarding your programming language. To retrieve a user profile from a fictitious SOAP API, you might make the following request using the Zeep library:

In this example, we initiate a SOAP client based upon the SOAP endpoint. Then we call the service, invoking the getuser option with a user ID parameter. It’s a simple example, but disguises even more detail of the SOAP messages behind the scenes.

Let’s look at how this SOAP call might be structured:

And the response might look something like this:

Even in this simple example, the actual data within the message is surrounded by the SOAP structure. Compared to some more modern API request examples, SOAP may appear overly complex. Keep in mind that most developers making SOAP API calls are using a library, which provides a friendlier interface.

That said, it is possible to make SOAP API calls through a typical HTTP request (most SOAP services use HTTP, though the specification is independent of protocol). Here is the same call above using the Python requests library:

In this case, response. Content would include the raw XML response, which needs to be parsed in order to determine the username and any other data the SOAP API returns.

Rest API

REST stands for Representational State Transfer. It is an architectural Style for designing networked applications (i.e. apps that use some form a network to communicate). It is the most popular style for building web APIs. REST determines specifications of the API through a set of rules that are followed when a REST API is created.

REST treats any data (e.g. image, video, text, etc.) as a resource that the client can fetch/edit/delete. REST mandates that a client should be able to perform the appropriate operation by accessing a specific URL and sending a request. The server then sends an appropriate response.

Think of it as a contract between the programs: the requester (aka the client) and the responder (aka the server). If the requester sends X to the responder, the responder will give the requester Y. X and Y are specified in contract between the two parties and explained in the documentation for the API.

REST is stateless, which implies that each request from the client must have all the necessary information for the server to understand it. For example, the client cannot assume that the server remembers what they had asked for earlier.

Resource: users

Service: contact information (GET)

Representation:

   - name, address, e-mail

   - JSON or XML format

URI: http://rest.org/users

Pros and Cons

Pros

1. REST API is easy to understand and learn, due to its simplicity, known API.

2. With REST API, being able to organize complicated applications & makes it easy to use resources.

3. The high load can be managed with help out of HTTP proxy server & cache.

4. REST API is easy to explore and discover.

5. It makes it simple for new clients to work on other applications, whether it is designed specifically for purpose or not.

6. Use standard HTTP procedure call- outs to retrieve data and requests.

7. REST API depends on codes, can use it to synchronize data with a website without any complications.

8. Users can avail access to the same standard objects and data model when compared to SOAP-based web services.

9. Brings flexibility formats by serializing data in XML or JSON format.

10. Allows Standard-based protection with the use of OAuth protocols to verify your REST requests.

Cons

1. Lack of state: most web applications require tasteful mechanisms. Suppose you purchase a website which has a mechanism to have a shopping cart. It is required to know the number of items in the shopping cart before the actual purchase is made. This burden of maintaining the state lies on the client, which makes the client application heavy and difficult to maintain.

2. Last of security: REST does’ impose security such as SOAP. That is the reason REST is appropriate for public URLs, but it is not good for confidential data passage between client and server.