Defining SOA service-oriented architecture

Defining SOA service-oriented architecture

This section will address defining SOA service-oriented architecture and look at what makes it unique.

Key elements

It's important to understand the key elements of service-oriented architecture SOA. With that goal in mind, let's begin by breaking down the service-oriented architecture SOA acronym into its core elements. We'll start with the last part first: architecture.

Let's look at the architecture in the context of service-oriented architecture SOA. Typically in software, architecture defines the overall definition and intercommunication of various high-level components. In simple terms, it's how we break down a solution into logical units and how they'll interoperate. In this sense, SOA represents an architectural approach that's focused on the definition and interaction of services.

Because service-oriented architecture SOA is a set of architectural principles, you can't go out and buy one. You may be able to buy middleware components that provide enabling technologies and core services. But by themselves, they aren't an SOA.

Let's move on to another piece of SOA: service-oriented. Service-oriented means that we'll center our solution architecture on a collection of services. If you've had experience with Object Oriented Design (OOD), this may seem familiar. In fact, these two approaches have many elements in common.

A service is a way of thinking about and organizing business functionality so it can effectively stand on its own. The service-oriented architecture SOA approach considers this functionality in terms of service providers and service consumers.

Service providers offer functionality as a set of interfaces to the service capabilities they provide. Service consumers will access the service capabilities provided by the service provider. These consumers may be an application or even a service provider. For example, a checking account service may offer a set of functionality relating to a checking account. This account may offer the ability to make a deposit, make a withdrawal, create a new account, etc. Notice that the capabilities we've described are very specific to the concept of checking account service. Also notice that we haven't yet said whether this service is provided by some banking software, by an ATM machine, by a teller in a bank, or all of the above.

Some may argue that this definition of service-oriented architecture SOA is just the latest way to describe and model application functionality. But it is important to realize that most applications today have been built with an end user in mind. To that end, an application may encapsulate a group of tasks that are related in some ways but are also discrete.

One of the key distinctions of an SOA service-oriented architecture is the fact that the consumer of some application functionality may in fact be another application or service. While human users tend to prefer all functionality aggregated together and accessible through one user interface, other applications don't have the same requirement. As a result, it makes sense to have functionality organized around a set of services that can be self-contained and yet can be woven together to create higher level functionality or services.

Once you apply these architectural principles, you'll end up with a set of services that can interact to provide a specific set of functionality with a business benefit. And now re-use comes into play: You could rapidly build another solution that reuses some of these services as well as some additional services that may be required to satisfy the business requirements. In the end, these services are woven into a kind of software ecosystem. Here, they cooperate to achieve a business objective but may also participate in other ecosystems that offer the same service capability for potentially different end solutions.