What is service-oriented architecture (SOA)?

SOA removes tasks from the application developer who previously redeveloped or duplicated existing functions 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 run a complete, discrete business function (for example checking a customer’s credit, calculating a monthly loan payment or processing a mortgage application). The service interfaces provide loose coupling. This means that 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 (for example, SAP), SaaS applications (for example, Salesforce CRM), or obtained as open source applications.

Service interfaces are frequently defined by using web service definition language (WSDL) which is a standard tag structure based on xml (extensible markup language).

The services are exposed by using standard network protocols—such as simple object access protocol (SOAP)/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 that 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 functions housed in another system required complex point-to-point integration—integration that developers had to re-create, 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).

Although SOA, and the more recent microservices architecture, share many words in common (that is “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 and 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 by using a specially designed integration runtime and toolset that helps ensure 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 much work (even if the interfaces are reusable) and creates a significant maintenance challenge 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:

• Greater business agility; faster time to market: Reusability is key. The efficiency of assembling applications from reusable services - that is, building blocks, rather than rewriting and reintegrating with every new development project, enables developers to build applications much more quickly in response to new business opportunities.
  The service oriented architectural approach supports scenarios for application integration, data integration and service orchestration style automation of business processes or workflows. This speeds software design and software development by enabling developers to spend dramatically less time integrating and more time focusing on delivering and improving their applications.
• Ability to use legacy functions in new markets: A well-crafted SOA enables developers to easily take functions ‘locked’ in one computing platform or environment and extend it to new environments and markets. For example, many companies have used SOA to expose functions from mainframe-based financial systems to new web applications. This enables their customers to serve themselves to processes and information previously accessible only through direct interaction with the company’s employees or business partners.
• Improved collaboration between business and IT: In an SOA, services can be defined in business terms (for example, ‘generate insurance quotation’ or ‘calculate capital equipment ROI’). This enables business analysts to work more effectively with developers on important insights—such as the scope of a business process defined by using services or the business implications of changing a process—that can lead to a better result.

By 2010, SOA implementations were going full steam at leading companies in virtually every industry. For example:

Delaware Electric turned to SOA to integrate systems that previously did not talk to each other, resulting in development efficiencies that helped the organization stay solvent during a five-year, state-mandated freeze on electric rates.

Cisco adopted SOA to make sure its product ordering experience was consistent across all products and channels by exposing ordering processes as services that Cisco’s divisions, acquisitions and business partners might incorporate into their websites.

Independence Blue Cross (IBC) of Philadelphia implemented an SOA to help ensure that the different constituents dealing with patient data—IBC customer service agents, physicians’ offices, IBC website users—were working with the same data source (a ‘single source of truth’).

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:

SOA is an integration architectural style and an enterprise-wide concept. It enables existing applications to be exposed over loosely coupled interfaces, each corresponding to a business function that enables applications in one part of an extended enterprise to reuse functions in other applications.

Microservices architecture is an application architectural style and an application-scoped concept. It enables the internals of a single application to be broken up into small pieces that can be independently changed, scaled and administered. It does not define how applications talk to one another, for that we are back to the enterprise scope of the service interfaces provided by SOA.

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:

• Developer agility and productivity: Microservices enable developers to incorporate new technologies to one part of the application without affecting the rest of the application. Any component can be modified, tested and deployed independently of the others, which speed iteration cycles.
• Scalability: Microservices can take maximum advantage of cloud scalability—any component can be scaled independently of the others for the fastest possible response to workload demands and the most efficient use of computing resources.
• Resilience: Again, thanks to decoupling, the failure of one microservice does not impact the others. And each microservice can perform to its own availability requirements without staking the other components or the entire application to greatest common availability requirements.

For a deeper dive into the differences between SOA and microservices, see SOA versus 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 integration. This is one of the core premises behind agile integration.