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.
As your company shifts its IT infrastructure toward a hybrid cloud approach, there’s a high likelihood you’ll be transforming a variety of workloads, including those based on SOA, to more lightweight and flexible cloud deployment models.
These transformations are just part of the application modernization required as the demand for better customer experiences and more applications impacts your business and IT operations. To meet these demands, a move toward greater automation also helps. Ideally, it would start with small, measurably successful projects that you can then scale and optimize for other processes and in other parts of your organization.
Working with IBM, you’ll have access to AI-powered automation capabilities, including prebuilt workflows, to help accelerate innovation by making every process more intelligent.
Take the next step:
Get started with an IBM Cloud account today.
Discover how hybrid cloud solutions built with IBM Cloud can help your organization migrate to cloud, modernize existing apps and build new cloud-native apps.
From your business workflows to your IT operations, we’ve got you covered with AI-powered automation. Discover how leading companies are transforming.
Connect applications, services and data with IBM Cloud Pak for Integration, the most comprehensive integration platform on the market.