service-oriented architecture (SOA)

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. 

The general concept that emerged was the remote procedure call (RPC) which allowed one software process to invoke another as though it were local, even though the other process might be resident in a different application, computer or data center.

The problem with the general RPC model was that it allowed too much variation in implementation, and lacked:

• any systematic set of tools to provide security for the information flows;
• governance with respect to access rights to the business processes involved; or
• discovery, connection with, and message formats for, the services themselves.

While the concept of services introduced by SOA is an integral part of modern cloud computing and virtualization, SOA itself has been largely displaced.

Major objectives of SOA

There are three major objectives of SOA; each objective focuses 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.

Implementation

SOA is independent of vendors and technologies. This means a wide variety of products can be used to implement the architecture. The decision of what to use depends on the end goal of the system.

SOA is typically implemented with web services such as simple object access protocol (SOAP) and web services description language (WSDL). Other available implementation options include:

• Windows Communication Foundation (WCF);
• gRPC; and
• messaging -- such as with Java Message Service (JMS), ActiveMQ and RabbitMQ.

SOA implementations can use one or more protocols and may also use a file system tool to communicate data. The protocols are independent of the underlying platform and programming language. The key to a successful implementation is the use of independent services that perform tasks in a standardized way, without needing information about the calling application, and without the calling application requiring knowledge of the tasks the service performs.

Common applications of SOA include:

• SOA is used by numerous armies and air force to deploy situational awareness systems.
• Healthcare organizations use SOA to improve healthcare delivery.
• SOA allows Mobile apps and games to use the mobile device's built-in functions, such as GPS.
• Museums use SOA to create virtualized storage systems for their information and content.

WS and WSDL models of SOA

Initially, SOA implementations were based on RPC and object-broker technologies available around 2000. Since then, two SOA models have been formed:

• The web services (WS) model, which represents highly architected and formalized management of remote procedures and components.
• The representational state transfer (REST) model, which represents the use of internet technology to access remotely hosted components of applications.

The WS model of SOA uses WSDL to connect interfaces with services and SOAP to define procedure or component APIs. WS principles link applications via an enterprise service bus (ESB), which helps businesses integrate their applications, ensure efficiency and improve data governance. This approach never gained broad traction and is no longer favored by developers.

The REST model has instead gained attention. RESTful APIs offer low overhead and are easy to understand.

Benefits of Service-Oriented Architecture

SOA retains the procedure-call model commonly used in structured programming and standardizes the way in which business processes are automated and used, doing so in a way that maintains security and governance.

Other benefits of SOA include:

• Reusable. Services can be reused to make multiple applications. This is facilitated by the fact that SOA services are held in a service repository and linked on demand, making each service a generalized resource available to all -- subject to governance constraints. Reusing services allows organizations to save time and lower costs associated with development.
• Easily maintained. Since all services are independent, they can be easily modified and updated without affecting other services. This will also lower an organization's operating costs.
• Promotes interoperability. The use of a standardized communication protocol allows platforms to easily transmit data between clients and services regardless of the languages they're built on.
• High availability. SOA facilities are available to anyone upon request.
• Increased reliability. SOA generates more reliable applications because it is easier to debug small services than large code.
• Scalable. SOA allows services to run on different servers, thus increasing scalability. In addition, using a standard communication protocol allows organizations to reduce the level of interaction between clients and services. Lowering the level of interaction allows applications to be scaled without adding extra pressure.

SOA disadvantages

The WS model of SOA has never been widely accepted or adopted, in part because of its inherent complexity, but also because of the incompatibility between the WS approach and the RESTful API model of the internet. The internet, and the related cloud computing model, exposed specific issues with SOA/WS, and overall, the industry has moved to a different model.

Other disadvantages of SOA include:

• Implementation of SOA requires a large initial investment.
• Service management is complicated since the services exchange millions of messages that are hard to track.
• The input parameters of services are validated every time services interact, thus decreasing performance and increasing load and response times.

SOA and microservices

REST and the internet supplanted SOA before it really gained significant traction, confining SOA to legacy applications, often built around the ESB. The broader notion of "services" was converted by RESTful thinking into "software processes" instead of "business processes," and the software-centric view became known as microservices -- the term in use today.

The term "web services" is still used in the cloud, where it means the set of packaged cloud-provider services offered to facilitate development of cloud-based applications. There are dozens of these services available from all the public cloud providers, and they are all accessed through REST interfaces.

Microservices, the latest evolution of the services concept, are small software feature components, accessed through a REST interface. Modern practice is to enforce security and governance outside the service/microservice APIs, usually via a service broker that acts as an intermediary to authenticate access rights. Because software processes and microservices build applications, and because application components are explicitly linked and not invoked according to workflow, SOA-like discovery and service repositories are not relevant. Microservice discovery and binding is instead defined to support scalability under load and resilience -- properties of software in the cloud.

Microservices can be shared among applications, and cloud providers may offer serverless pay-as-you-use models for microservice hosting. In these cases, there may be a formal commercial microservice or service contract to describe the specific performance guarantees and the payment terms. Even internal microservices may have a contract if the IT organization charges departments back for usage.

SOA vs. SaaS

SaaS, or software-as-a-service, is a form of public cloud computing where a service provider -- or a public cloud provider -- offers a complete business application to a service consumer via a RESTful API from the cloud.

SaaS is another cloud development that's impacted SOA, and in one limited sense, it may even return a bit to the original SOA principles. SaaS could more properly be called "application-as-a-service," because the goal is to provide complete support for a business process in the cloud. Since the "service" is a business process, SaaS is like SOA. SaaS is also like some forms of microservices, in that SaaS will be offered in accordance with a service contract that describes service levels and pricing.

SaaS services will almost always offer APIs to support the integration of SaaS work with other business processes still hosted in the data center, or even in another cloud. However, these interfaces will obey modern microservice and API conventions and not SOA/WS conventions.