Service-oriented architecture simplified: Key benefits and challenges

Each component in an SOA performs one of three different roles: service providers create web services and provide relevant information to the service registry (or broker) so they can be subsequently discovered and re-used. The service requester locates the service it needs via the broker and binds with the service provider to invoke the functionality it requires.

Service oriented architecture

How did SOA come about?

SOA emerged at the start of this century as a response to a prevailing IT environment where software development was unwieldy and slow – and was all-too-frequently delivered late and over-budget as a result. Not only that, but the resulting applications were highly interrelated and therefore hard to modify or upgrade: updates might have unintended (and negative) consequences for another part of the application and so implementing change involved a huge amount of testing and was glacially slow.

Instead of approaching application development as the creation of a single monolithic entity, SOA sought to break apart these monoliths into smaller, more manageable chunks – or services. In this context, services are not fully-fledged applications but components that can be combined in different ways to make those applications. The SOA provides a set of design principles that provide structure for the creation of these components and their aggregation into fully-featured applications.

What is a service?

There are many different definitions of a service but that from the Open Group is as good as any. According to them, a service:

• Represents a discrete business activity with a specified outcome.
• Is largely self-contained.
• Is a ‘black box’ for those that use it, meaning that there is no requirement to understand the service's inner workings.
• May include (or even consist entirely) of other services.

These services are generally loosely coupled and so largely independent of the other services in the application – meaning they can be modified easily without the ‘knock-on’ effects described above. The same service can also be reused if the same functionality is required by a different part of the application.

In the context of service-oriented architecture, services are the foundational components that enable the flexibility, scalability, and reusability of this approach.

SOA leverages these services to create an ecosystem where different applications and systems can interact with each other. By treating each service as a modular unit with a defined purpose and outcome, service oriented architecture makes it possible for businesses to adapt quickly to evolving needs and minimize system dependencies.

What are the benefits of a service-oriented architecture?

The net effect of all of this is that SOA addresses many of the frustrations outlined earlier in this article. It drastically reduces the cost and complexity associated with enterprise software development. It also massively increases the speed with which new applications can be created and deployed – and existing ones upgraded. To the business, an SOA simply means that the IT department is far more responsive to their needs and the organization is significantly more agile as a result.

Additionally, in some cases, service-oriented architecture can provide a solid foundation for integrating modern technologies like cloud computing, APIs, and microservices to enable organizations to stay competitive.

1. Scope

SOA is made up of a portfolio of applications and services operating at the enterprise level, requiring developers to have a complete understanding of the application and all its dependencies to code successfully.

Microservices, on the other hand, is an application architecture. It breaks down a single application into multiple independent services, each serving a specific functionality. In other words, each functionality does one job very well, reducing the scope of understanding developers need to work on each module. However, it also reduces the ease at which code can be re-used between functionalities.

In short, where microservices is inward-looking—into the internal architecture of the application—SOA is concerned with the enterprise-level architecture.

2. Granularity

Service-oriented architecture is "coarse-grained," meaning it focuses on large, business-domain functionalities. As a consequence of this, each functionality has a long list of dependencies.

Microservices is much “finer-grained”, creating a mesh of functionalities that each has a single focus called a bounded context. Each bounded context is independent—only loosely coupled—and far more focused than the domain functions of an SOA.

This also makes microservices far more scalable than SOAs, as they can be built grain-by-grain.

3. Technical implementation

SOA requires software that handles communication. Historically, businesses have used web service access protocols like SOAP to expose and then transact with each functionality. However, connecting all a business’s applications negatively affects the system’s scalability and can require time-consuming maintenance.

This is why service oriented architecture uses a middleware tool called an Enterprise Service Bus (ESB) that handles the communication and reduces the number of point-to-point connections between functionalities. However, ESBs also create a single point of failure: should the ESB go down, then all the SOA services would be inaccessible.

When it comes to a microservices architecture, each individual service operates and scales independently and so each has their own separate point of failure, making microservices far more resilient and agile, and enabling the independent coding of each individual functionality.

Does OutSystems promote a service-oriented architecture?

In a word, yes. OutSystems was created to address the problems associated with enterprise software development described earlier, and we share SOA’s ambitions of delivering greater agility, reusability, and time to market. Like all service-oriented architecture environments, the OutSystems platform delivers applications that are functionally complete and that address non-functional requirements using services that are properly governed and easily discoverable.

So, how does OutSystems differ from other service-oriented architectures?

Well, all Ferraris are cars, but it’s not the case that all cars are Ferraris! In the same way, while all the applications created by our customers are examples of an SOA, not all SOAs share the attributes of OutSystems. There are two key distinctions:

1. Platform versus toolkit: Most service-oriented architecture vendors provide a set of tools and a structure with which to create services; but these are provided without any intellectual property, so all services have to be created using in-house intelligence.
   
   With OutSystems, business logic is included with each component in the platform, enhancing the speed with which applications can be created.
   
   Any changes to the component are automatically replicated in every instance where that component is used, so incremental adjustments to an application can be deployed in hours. Being a platform, OutSystems provides greater automation for service deployment, discovery, governance, and impact analysis on service changes, which are fundamental to achieving greater agility.
2. Visual development versus object-oriented: Most SOAs are object-oriented, meaning that every aspect of the architecture is represented as objects, which are then used to build services. Working with objects is much quicker than coding from scratch but still requires extensive developer training.
   
   OutSystems provides a visual abstraction of the application so it can be built using a ‘drag and drop’ approach—with much of the repetitive work handled automatically in the background—an approach that promotes much greater developer productivity.
   
   The use of visual programming also means that other people in the business are able to use the OutSystems platform and that—at a time when developer resources are expensive and scarce—people with little to no coding background can become fluent in the development environment in only a few months.

To learn more about OutSystems application architecture, take a look at Application Architecture: Best Practices for Future-Proofing Your Apps.

Learn the fundamentals of modern development

SOA frequently asked questions