What is Service-oriented Architecture (SOA)?

Service-oriented architecture (SOA) is an architectural pattern as well as a collection of design principles that support loose coupling and reusability of different components in a distributed system.

Although the concept of SOA or service-oriented architecture became popular in the early 2000s, its relevancy continues to dominate today. The global revenues from the SOA market are projected to increase to around 100 million USD by 2020, from 11 million USD in 2008. This is in part due to SOA’s evolution from its initial days of web applications to a broader range of use cases—including on-premises, cloud, and other implementations such as microservices.

In this article, we will learn more about SOA, its features, and its impact on technology and business.

The need-to-know SOA building blocks

Software systems were initially designed as monolith applications that were hard to manage. The emergence of client-server architecture and the separation of user interface, business logic, and database improvised on the earlier approach with their modularity. The SOA took it a step further by providing a framework in which applications are perceived as a collection of services that communicate with each other through a common network protocol.

The SOA consists of two important roles – service provider and service consumer. A provider is the one that implements a certain technical or business objective. The consumer makes a call to the provider in order to leverage its functionalities. The consumer sends a request and the provider comes back with a response. The request-response paradigm here follows a standard messaging or communication protocol that both parties can understand.

Some of the commonly used technologies to achieve this communication are WSDL (Web Services Description Language), SOAP (Simple Object Access Protocol), and REST (Representational State Transfer).

Before we discuss the principles that define the SOA architecture, let’s look into what a service is. The following are the four properties that define a service:

1. Logically represents a business activity with a specified outcome: Services are usually identified as logical units that have a specific, narrow purpose. For example, a Logger service manages all the logging functionalities of your application. Irrespective of whether it’s the UI, server, or database, the Logger service can be reused for logging purposes.
2. Self-contained: The logic inside a service is independent of any other service or process. So, if you make changes to algorithms inside the Logger service, it does not impact any other service as long as the interface isn’t broken. This property allows loose coupling between various services, allowing you to change technologies used or optimize your code without impacting other processes.
3. Black box for its consumers: A consumer of a service does not have any knowledge of what happens inside the service it invokes. For example, let’s say there is a CustomerInformation service. Initially, the service might have been pulling information from database tables, but later it might extract data from social media channels. The consumer has no awareness of this change.
4. Consists of other underlying services: A service can use other services to achieve its business goal. For example, a Logger service may in-turn use a ReadWrite service that can write text into a file in a certain format.

8 defining SOA features

The SOA architectural style is technology agnostic, business-centric, and achieves seamless interoperability between services. The following eight guiding principles help towards these goals.

1. Standard service contract: The contract usually refers to: documentation on how the service interfaces are defined, parameters that need to be passed, data models used, and the messaging formats involved (example: XML).
2. Loose coupling: A service interface should be defined in such a way that if the implementation inside changes, the interface points do not break.
3. Abstraction: A service should encapsulate all internal details such as business logic and technologies used. For example, there will be no impact on a consumer if a Java service is changed to a .NET service.
4. Reusability: Reusing services across systems is one of the goals of SOA. For example, while building a Login Service, developers should consider making the functionalities generic and widen their scope such that the service could be used across multiple systems and platforms.
5. Autonomy: A service should have maximum control over its logic and less or almost no reliance on the design of other external systems.
6. Statelessness: A service should not have to remember its previous state. The application that invokes the service has to record state transitions and write its business logic accordingly.
7. Discoverability: Clients should be able to find out which services are available by checking in with a common service registry.
8. Composability: A service should never become too bulky as it can get hard to maintain and reuse. By breaking it into many smaller services, rewrites become easier. It should also be possible to plug-and-play services into the overall business application.

The SOA component framework

While the eight principles provide a structured guideline, we need a unifying model or framework for building applications based on SOA, where multiple services interact with each other or a business application reuses some of the services. The various components of SOA discussed below provide that implementation framework for different moving parts to come together:

Service registry or broker

A service registry is a catalogue or directory that contains all information or metadata related to services. It extends the scope of use to outside teams or even organisations. Public registries, for example, can be accessed to understand what interfaces are exposed by a certain service provider.

Enterprise service bus (ESB)

ESB refers to the message routing layer that manages communication from and to a service. A common protocol allows multiple technologies to talk to each other. ESB removes point-to-point interaction making it easy to maintain and scale services.

Service orchestration

A central service manager invokes or orchestrates a composition of services in a certain sequence, adds to that with its own logic, and achieves a certain business objective.

Business process modelling (BPM)

The objective of SOA is to achieve business goals rather than just implement a collection of services. BPM is a representation of the service orchestration. It helps users understand, analyse, and improve current workflows.

Unified data modelling

For an SOA to maintain loose coupling and be autonomous, it’s important for services to share a common data model and access a master data store that consolidates and creates a single version of truth.

SOA vs. microservices

SOA is often compared to microservices as both share the same fundamentals. Microservices, which are more recently developed than SOA, are even considered to be a type of SOA. Both styles advocate the use of plug-and-play services that come together to form an application challenging the monolithic architecture of yesteryears. They are both independent technology and encourage loose coupling between services.

However, there are some notable distinctions between the two, mainly their scope and objective. SOA operates at an enterprise level and microservices is an architectural pattern to use within an application. While SOA’s primary goal is reusability, microservices aims to make the application development process more agile.

In essence, SOA creates services that are reusable across the enterprise in many applications, thereby resulting in cost savings. Microservices is a fallout of the agile and DevOps culture, where continuous integration and delivery is the key. So, it splits the application into tiny services that can be tested and deployed independently, thereby improving the speed of development and delivery.

Another difference between the two is the way they manage data. In SOA, the various services within an application access a common data store. However, every microservice within an application has its own data repository in order to make it self-contained in the truest sense. This data duplication adds complexity and usually requires a synchronisation mechanism to ensure data alignment.

Applying SOA in business applications

Although the concept of SOA is technical and architecture-based, its ultimate goal is to model business processes efficiently into manageable chunks.

Let’s look at a few advantages of SOA:

• Services can be reused within an enterprise resulting in significant cost savings. They can also be made public for third party use. For example, the Google Map service is used extensively by several organisations.
• Services are scalable. If the volume of data increases in the future, it can be easily handled by running more instances of a service.
• The loose coupling and technology independence enable developers to add more functionalities seamlessly. For example, you can add new gateways or channels to a payment service with ease.
• Monolithic applications are hard to maintain, debug, and test for quality. However, services are easier to write test cases for and narrow down problem areas.
• Overall, SOA with its clear mapping between services and business layers enables enterprises to respond to business and technical changes with improved agility.

SOA is not without its complications though. Here are a few things to watch out for while working with an SOA:

• Using too many services can become clunky, create many hops within an application, and slow down performance. However, this can be avoided at design time by evaluating the scope of each service.
• A good design of the service orchestration layer is crucial for the success of SOA. Managing multiple services, translating messages between them, and handling the bandwidth could be a challenge.

Building a successful SOA implementation

Talend can help overcome some of the limitations associated with SOA. By providing a reliable and scalable messaging platform to exchange and route messages, Talend creates and connects SOAP and REST services across your applications while also mediating service interactions. 

Further, Talend helps solve one of the biggest challenges enterprises fact today: dealing with varied data silos that need to be unified into a single environment. Talend Data Fabric solves this issue by building a virtual data layer to easily integrate a variety of data sources and enable intuitive self-service data access. 

By putting these fundamental building blocks in place, it becomes possible to manage even a complex enterprise service architecture. Try Talend Data Fabric today to meet the demand for faster and agile integration.