This content is part of the Essential Guide: Developers' guide to deploying microservices and containers

service-oriented architecture (SOA)

Contributor(s): Tom Nolle

Service-oriented architecture (SOA) is a software development model for distributed application components that incorporates discovery, access control, data mapping and security features. 

SOA has two major functions. The first is to create a broad architectural model that defines the goals of applications and the approaches that will help meet those goals. The second function is to define specific implementation specifications, usually linked to the formal Web Services Description Language (WSDL) and Simple Object Access Protocol (SOAP) specifications.

The emergence of SOA

For decades, software development required the use of modular functional elements that perform a specific job in multiple places within an application. As application integration and component-sharing operations became linked to pools of hosting resources and distributed databases, enterprises needed a way to adapt their procedure-based development model to the use of remote, distributed components. Simple models like the remote procedure call (RPC) were a start in the right direction, but RPC lacked the security and data-independent features needed for truly open and distributed operations.

The solution to this problem was to redefine the old operation model into a broader and more clearly architected collection of services that could be provided to an application using fully distributed software components. The architecture that wrapped these services in mechanisms to support open use under full security and governance was called the service-oriented architecture, or SOA. SOA was introduced in the late 1990s as a set of principles or requirements; within a decade, there were several suitable implementations.

Major objectives of SOA

There are three major objectives of SOA, all which focus on a different part of the application lifecycle.

The first objective aims to structure procedures or software components as services. These services are designed to be loosely coupled to applications, so they are only used when needed. They are also designed to be easily utilized by software developers, who have to create applications in a consistent way.

The second objective is to provide a mechanism for publishing available services, which includes their functionality and input/output (I/O) requirements. Services are published in a way that allows developers to easily incorporate them into applications.

The third objective of SOA is to control the use of these services to avoid security and governance problems. Security in SOA revolves heavily around the security of the individual components within the architecture, identity and authentication procedures related to those components, and securing the actual connections between the components of the architecture.  

WS and WSDL models

Initially, SOA implementations were based on the RPC and object-broker technologies available around 2000. But SOA quickly split into two camps. The first is the web services (WS) camp, which represents highly architected and formalized management of remote procedures and components. The second is the representational state transfer (REST) camp, which represents the use of internet technology to access remotely hosted components of applications.

The WS model of SOA uses the WSDL to connect interfaces with services and the SOAP to define procedure or component APIs. WS principles were used to link applications via an enterprise service bus (ESB), which helped businesses integrate their applications, ensure efficiency and improve data governance.

A whole series of WS standards were developed and promoted by industry giants, such as IBM and Microsoft. These standards offered a secure and flexible way to divide software into a series of distributed pieces. However, the model was difficult to use and often introduced considerable overhead into the workflows that passed between components of an application.

The WS model of SOA never reached the adoption levels that advocates had predicted; in fact, it collided with another model of remote components based on the internet: REST. RESTful application program interfaces (APIs) offered low overhead and were easy to understand. As the internet integrated more with applications, RESTful APIs were seen as the future.

SOA and microservices

The tension between SOA as a set of principles and SOA as a specific software implementation came to a head in the face of virtualization and cloud computing. The combination of virtualization and cloud encourages software developers to build applications from smaller functional components. Microservices, one of the critical current software trends, was the culmination of that development model. Because more components mean more interfaces and more complicated software design, the trend exposed the complexity and performance faults of most SOA implementations.

Microservice-based software architectures are actually just modernized implementations of the SOA model. The software components are developed as services to be exposed via APIs, as SOA would require. An API broker mediates access to components and ensures security and governance practices are followed. It also ensures there are software techniques to match diverse I/O formats of microservices to the applications that use them.

But SOA is as valid today as it was when first considered. SOA principles have taken us to the cloud and are supporting the most advanced cloud software development techniques in use today.

This was last updated in March 2018

Next Steps

Enterprises can manage applications using Talend ESB and its open source version, Open Studio for ESB.

Continue Reading About service-oriented architecture (SOA)

Dig Deeper on Distributed application architecture

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

Does your organization use SOAP for Web services, or an alternative?
SOAP and REST are probably the two most complete web services. I have to admit that the challenge of choosing between the two was not an easy one.

However, we picked SOAP for one reason – less coding. We have a lot of work to do so we didn’t want to spend additional time on transaction, security, and address codes. Over time, we’ve also learned that SOAP is much better at handling asynchronous processing and invocation.
Thanks for your input, Abby. It sounds like the REST versus SOAP debate is an ongoing one. 
Earlier in the evolutionary timeline of our SOA environment, we had a pretty even mix of both SOAP and ReST services. As the environment evolved SOAP began to gain prominence, and today is the primary choice for our web services, with legacy ReST services being refactored to use SOAP.
Mccorum, what do you like the best about SOAP?
How does your organization still make use of SOA principles?


File Extensions and File Formats

Powered by: