SOA, or 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 redeveloped or duplicated existing functionality or had to know how to connect or provide interoperability with existing functions.
Each service in an SOA embodies the code and data required to execute a complete, discrete business function (e.g. checking a customer’s credit, calculating a monthly loan payment, or processing a mortgage application). The service interfaces provide loose coupling, meaning they can be called with little or no knowledge of how the service is implemented underneath, reducing the dependencies between applications.
This interface is a service contract between the service provider and service consumer. Applications behind the service interface can be written in Java, Microsoft .Net, Cobol or any other programming language, supplied as packaged software applications by a vendor (e.g., SAP), SaaS applications (e.g., Salesforce CRM), or obtained as open source applications. Service interfaces are frequently defined using Web Service Definition Language (WSDL) which is a standard tag structure based on xml (extensible markup language).
The services are exposed using standard network protocols—such as SOAP (simple object access protocol)/HTTP or Restful HTTP (JSON/HTTP)—to send requests to read or change data. Service governance controls the lifecycle for development and at the appropriate stage the services are published in a registry that enables developers to quickly find them and reuse them to assemble new applications or business processes.
These services can be built from scratch but are often created by exposing functions from legacy systems of record as service interfaces.
In this way, SOA represents an important stage in the evolution of application development and integration over the last few decades. Before SOA emerged in the late 1990s, connecting an application to data or functionality housed in another system required complex point-to-point integration—integration that developers had to recreate, in part or whole, for each new development project. Exposing those functions through SOA services allowed the developer to simply reuse the existing capability and connect through the SOA ESB architecture (see below).
Note that although SOA, and the more recent microservices architecture, share many words in common(i.e. "service" and "architecture"), they are only loosely related and, in fact, operate at different scopes, as discussed later in this article.
An ESB, or enterprise service bus, is an architectural pattern whereby a centralized software component performs integrations between applications. It performs transformations of data models, handles connectivity/messaging, performs routing, converts communication protocols and potentially manages the composition of multiple requests. The ESB can make these integrations and transformations available as a service interface for reuse by new applications. The ESB pattern is typically implemented using a specially designed integration runtime and toolset that ensures the best possible productivity.
It is possible to implement an SOA without an ESB, but this would be equivalent to just having a bunch of services. Each application owner would need to directly connect to any service it needs and perform the necessary data transformations to meet each of the service interfaces. This is a lot of work (even if the interfaces are reusable) and creates a significant maintenance challenges in the future as each connection is point to point. In fact, ESBs were, eventually, considered such a de facto element of any SOA implementation that the two terms are sometimes used as synonyms, creating confusion.
Compared to the architectures that preceded it, SOA offered significant benefits to the enterprise:
By 2010, SOA implementations were going full steam at leading companies in virtually every industry. For example:
Experts have filled a few thousand print and digital pages comparing SOA and microservices, and defining the subtleties of their relationship to one another. For the purposes of this article, the chief differences between the two are the coupling of components and scope of use:
Microservices architecture emerged and gained steam with the rises of virtualization, cloud computing, Agile development practices, and DevOps. Most of the advantages of microservices in these contexts arise from the decoupling of the components, which simplifies and improves the following:
For a deeper dive into the differences between SOA and microservices, see "SOA vs. Microservices: What's the difference?"
In the same way that microservices architecture has the potential to bring improvements in agility, scalability, and resilience to application design, these same techniques can also be applied to integration. This is important because, over time, the heavily centralized ESB pattern and its associated centralized team of integration specialists can become a bottleneck. Borrowing from microservices principles, we can potentially break up the ESB into a more fine-grained, decentralized integrations. This is one of the core premises behind agile integration.
Connect applications, services and data with IBM Cloud Pak for Integration, the most comprehensive integration platform on the market.
Connect apps and data with a powerful, AI-automated application integration software.
IBM API Connect® is a secure API management solution that utilizes an intuitive experience to help consistently create, manage, secure, socialize, and monetize APIs.
Learn the basics of service-oriented architecture (SOA) and microservices, their key differences, and which approach would be best for your situation.
This guide outlines how to accelerate your app modernization, improve developer productivity, and improve operational efficiency and standardization.
Learn more about the ESB (an essential component of SOA), the benefits it offers, and how it relates to microservices architecture.