SOA Architecture

It is essential for the Businesses to think a lot more seriously about how best to assemble their systems out of common parts. It requires a lot more planning and investment at the outset, but it also enables Businesses to build faster systems in the long run as the inventory of reusable parts grows at a frantic pace.

In such programs, systems tend to be composed of reusable elements, which are referred to as services. A service can be thought of as a software building block that performs a specific function. These functions are performed via interfaces, which are electronic descriptions of how to call on a service from other services.

SOA represents an evolution of client server architectures. In such architectures, the functions of application logic, data management, and user interface are all separate, enabling each one to be implemented via the use of technologies and platforms that are most appropriate for a given task. When it comes to SOA, on the other hand, such functions are decomposed on a further level – particularly the application logic. So, for instance, instead of having business logic be implemented in a monolithic application server, a SOA-based system is able to clearly incorporate services running on several different software platforms – even if those services happen to be hosted externally by third party providers.

SOA Defined

In reality, there is no universally accepted definition of SOA, other than the fact that it is an architecture that literally relies upon service orientation as its main principle of design. Service orientation is the description of an architecture that makes use of loosely coupled services as a means of supporting the requirements of users and corporate processes. Network resources in an SOA environment are made available as independent services that one can access without having knowledge of the underlying platform implementation. Such concepts can be applied to software, business, as well as other kinds of systems that rely on producers and consumers.

SOA Architectural Features

Let us now take a look at some of the key features of SOA. The best way to go about doing this is to break SOA down in to its alphabetical components. We’ll start with the last letter first: A for Architecture.

We will first examine architecture in reference to SOA. Usually, in the realm of software, architecture tends to define the overall intercommunication and definition of different high level components. To put it simply, this is how a solution is broken down in to logical units – and how they will operate with one another. In a way, SOA is representative of an approach to architecture that focuses on how services are defined and how they interact with one another.

SOA is not something you can just go out and purchase. It is a set of architectural principles. While you might be able to purchase certain middleware that enables services and technologies, this alone does not constitute a SOA.

Now it is time for us to move on to the SO part of SOA. Being “service-oriented” basically means that you are employing an architecture that consists of a variety of services. This might sound familiar to those who have had some experience in the past with Object Oriented Design. In fact, OOD and SOA have a lot in common.

By thinking in terms of services, you are effectively considering how to make your business function so that it stands on its own. This approach is enabled via the use of SOA. It takes into consideration the needs of both the providers and consumers of services.

Providers vs. Consumers

The providers of services offer functionality in the form of interfaces to the service capabilities they are providing. The consumer then accesses those capabilities. Such consumers may be an application or even another service provider. So, for instance, a checking account service may offer a functionality set that relates to a particular checking account. Such an account may offer the possibility to make deposits, withdrawals, create new accounts, and more. These capabilities, you may notice, are very particular to the context of a checking account service. We have not yet stated whether such a service might be provided by an ATM machine, a bank teller, or software.

A lot of people tend to believe that this definition of SOA is merely the latest way to describe the functionality of applications. The fact is, a lot of applications in today’s market have already been built with an end user in mind. Thus, an application may encapsulate a group of several different tasks that are somehow related, yet also retain some degree of discretion.

SOA distinguishes itself in that the consumer of certain application functionalities may very well be another service or application. It is true that human users mostly prefer all functionality to be aggregated together and also accessible through a single user interface. But a lot of other applications do not come with this requirement.

Thus, it is logical to have functionality organized around a set of services which may or may not be self-contained, yet even in the event that they are, they can be somehow woven together to create a higher level of services or functionality.

Once these principles of architecture have been applied, you will find yourself with a lot of services that are able to interact as a means of providing a specific functionality set with benefits for your business. This is when re-use comes into picture. You are now able to quickly build up another solution that will reuse a lot of these services while also providing additional services that the business may require. Such services are woven into a sort of ecosystem of software. In this scenario, they cooperate as a means of achieving some business objective, while possibly participating in some other ecosystems that offer similar service capability for a possibly different end solution.