The Ins and Outs of a Service-Oriented Architecture (SOA)

This post aims to help the reader gain a better understanding and go beyond the textbook definition to where leaders can realize the benefits of SOA. You will learn about a few common examples, and the key differences between SOAP and REST.  But we’ll get to that later. Read on to learn how an SOA truly functions, and more importantly, just how you can take advantage.

What is SOA?

SOA stands for service oriented architecture. According to Gartner, service oriented architecture (SOA) “is a design paradigm and discipline that helps IT meet business demands.” Going further, there are several distinct features to this architectural style:

• The service design is contextualized and further based on business processes
• There are several interaction models including resource-oriented, method-oriented, or event driven
• Relies on reuse of existing infrastructure
• Effective implementation relies on service representation governance

What is a service?

Using an SOA style allows IT to deploy software services, each consisting of a piece of logic that resides within an application. A service can be loosely defined and has a range of capabilities specific to the intended function of the software service. Typical characteristics of a service description are:

• Remains independent of other software. In other words, it is commonly self-contained or
• May be a composite of other services
• Is modeled to a specific business process
• Responds to another service using runtime technology to access a web application.
• Due to loose coupling, a service is able to perform its functions without any type of changes.

What are the benefits of a service-oriented architecture?

Think of how life used to be within an IT department. You had all this legacy technology and often bulky equipment for software, hardware, and networking. Remember how hard it was to make a change to any of the three? An SOA is designed to make change easier and simpler.

Easy-to-configure components: Service-oriented architecture make your business processes run smoothly.

Flexibility to assemble these different services and mix-and-match any way you see fit: This flexibility allows IT to better meet business needs

Service reuse and reconfiguration: When a service needs to be updated or changed, rather than starting completely from scratch, developers can simply reconfigure the way the services are deployed.

In order to fully understand the positive impact SOA can have on the business, let’s take a look at a high-profile example of SOA transformation in recent years with the story of Amazon.

Amazon started as a book retailer, and has grown to become a goliath in everything from retail and cloud computing to streaming television shows and movies. But in 2002, CEO Jeff Bezos sent forth a mandate broken down as follows:

• All data and functionality needs to be exposed through service interfaces
• No other methods of process communication are permitted
• All services must be developed with the outside world in mind

This was the groundwork that led to the creation of Amazon Web Services; an early decision that every single function of Amazon’s code base must be an exposed service. Total game changer and one of SOAs greatest success stories.

How to implement SOA:

There are several options for service-oriented architecture implementation that rely on standard internet protocols, programming languages, and existing systems. As in the Amazon example, Web services is a common building block to establishing SOA.

SOAP (Simple Object Access Protocol)

There are two central web-architecture services that actually performs these SOA functions. The first we’re going to discuss is SOAP, which stands for Simple Object Access Protocol. SOAP is a protocol that provides an outlet for systems to communicate with one another. It is XML-based, and in addition to supporting HTTP (HyperText Transfer Protocol), it also has built-in standards for FTP (File Transfer Protocol), SMTP (Simple Mail Transfer Protocol), and WSDL (Web Service Definition Language). Most implementations are sent by XML over HTTP.

Within the XML document, there is an XSD (XML Schema Definition), which effectively defines how the XML document is structured. IT pros can use an XSD to validate an XML document and ensure that it follows the rules that you have laid out for it to perform. WSDL, on the other hand, is an XML document that describes and details a web service. It provides a way to view which operations are available to use, and how the data should be structured.

Often, SOAP implementations are more of the complex nature, and are especially large. The message is wrapped in what is called a SOAP envelope, which features a SOAP header and a SOAP body, which is what the message consists of. As mentioned above, HTTP is the most common transport within SOAP, and it is used to define ways to interact with a web service.

SOAP implementations are preferred in industries such as the financial sector, which require transactional auditing to remain compliant. As a matter of fact, any transactional make good sense within SOAP because they are so similar to a remote procedure call that they allow you to have full control to ensure you remain complaint and the transaction is secure.

REST (Representational State Transfer)

Now that you’ve gained a better understanding of a Simple Object Access Protocol, it’s time to discuss the next most common web-architecture service, REST. REST stands for Representational State Transfer. REST implementations have been called less restrictive forms of SOA than SOAP. REST is known for its simplistic nature, and also uses interactions to communicate via HTTP. APIs defined by REST architecture are referred to as RESTful APIs. There are five HTTP commands typical of RESTful APIs:

1. GET: Nullipotent command to safely retrieve information

2. PUT: Idempotent command to create, update or replace an entity

3. PATCH: Idempotent command to replace an entity

4. POST: Used to create a new entity or update an existing one

5. DELETE: Idempotent command to immediately or asynchronously remove an entity

REST is a client-service architecture based on a request/response design. The client sends the request and the server responds, and the communication between the two is resource based. Documents and images are a few resources that travel between the client and the server. Common examples of REST implementations include cloud applications, as well as social networking apps. Twitter is a common example of a REST implementation.

Differences between SOAP and REST

 SOAP and REST both have their benefactors as well as detractors. There isn’t necessarily a right or wrong answer as to which is better to use, but each of them has certain use cases that are more helpful in different scenarios than the other.

• Independence – SOAP is language, platform, and transport independent, while REST must use HTTP.

• Efficiency – REST can use smaller messaging formats, while SOAP requires XML for all of its messages.

• Environment – SOAP works well in a distributed environment, while REST assumes a direct point-to-point collaboration.

• Dynamic – REST is easier to implement and learn to use, SOAP requires more bandwidth and resources to work effectively.

Microservices vs. SOA

Microservices are a variant of SOA and a method to develop an application by way of composing application from smaller modular components or multiple services. Each component has specific tasks and functions that it must support via APIs. Take an SOA and break it down into smaller services in order to perform a set goal. Microservices considered a more granular and flexible way of architecting and designing applications and services then an SOA.

Microservices were designed to capitalize on the world of cloud computing, and have been considered a way to build out and expand an SOA. Microservices are individual, thin, smaller services that communicate with each other through APIs. Let’s take a look at some of the key differences between an SOA and microservices.

• Freedom – Unlike an SOA, a microservice architecture is completely independent from one another. Microservices can likely be upgraded without upgrading the related services, whereas with an SOA, you might have to also upgrade the other services when performing a general upgrade.

• Containerization – Microservices are often placed within a virtual container system such as Docker.

• Development ­­– Again, because of the individuality that microservices provide, they can be easier to develop than SOA because they only perform a simple function and were created to work on their own.

The validity of an SOA

A service-oriented architecture is designed to bring better alignment to your business. Gartner states specific business benefits, including the ability to bring applications to the market faster, a lower integration TCO due to systemic simplicity and consistency, and perhaps most importantly, increased business agility.

IT professionals need to ensure all the applications within an enterprise are running smoothly and communicating with one another. SOA provides the principles to allow more cohesive application implementation that couples leveraging existing infrastructure assets coupled together with new solutions and services development. While SOA continues to play an important role in the enterprise, for it to be effective, strict adherence to governance and IT processes is required.