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.
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.
In architectural terms, a modern architectural design should be Service Oriented, loosely coupled, driven by events, able to support both integration and assembly, aligned with valuable life cycle support processes, and able to leverage existing infrastructure and applications.
When it comes to SOA, it tends to offer a variety of different advantages over more traditional methods of distributing computing. These include offering business services across several platforms; providing location independence; providing authentication as well as authorization support on every tier; a loosely coupled approach; and dynamic search and connectivity to other services. At the same time, it allows services that do not have to be located on a particular system or network.
Some of the short term benefits of Service Oriented Architecture implementation include an enhancement of reliability; a reduction of hardware acquisition costs; an acceleration of movement towards standards based servers and application consolidation; the leveraging of existing development skills; and the providing of a data bridge that connects previously incompatible forms of technology.
There are also numerous long-term benefits of Service Oriented Architecture implementation. These include the creation of a self healing infrastructure that effectively reduces management costs; the proven ability to build composite applications; the access to truly real time decision making applications; the resulting compilation of a unified taxonomy of data across an enterprise, which includes both partners and customers; and a whole lot more.
From the perspective of Business Value, the advantages of Service Oriented Architecture include the ability to meet customer demands at a much faster pace than ever before; a reduction of costs previously associated with the maintenance and acquisition of key technological needs; the management of business functionality at a physically closer location to the business units; a reduction in reliance on pricey custom development; and a leverage of existing investments in the technological sector.
As of the year 2007, service oriented architecture is viewed by industry professionals as an underlying structure that supports communications among different services. In such a context, a service can be thought of as a unit of work that is performed on behalf of some form of computer entity, which might be a human user or another program.
Service Oriented Architecture is now viewed as a method for two separate computer entities, such as programs, to interact in a way that enables one of those entities to perform a unit of work on behalf of the other entity it is connected to. Service interactions are viewed through the utilization of a description language. Every interaction is self contained and coupled loosely, enabling every interaction to be independent of any other interaction.
Simple Object Access Protocol, or SOAP based web services have evolved as the most common SOA implementation. There are, however, non web service implementations that exist that provide similar benefits. Service Oriented Architecture’s protocol independence thus means that consumers can communicate with the service in a variety of ways. In an ideal set up, there should be a management layer that is situated between protocols and consumers as a method for ensuring total flexibility in terms of implementation protocols.
Whether you are aware of it or not, you have most likely come in to contact with Service Oriented Architecture – most likely when you made an online purchase.