SOA Concepts
Today, the concept of Service Oriented Architecture has become ubiquitous. Evidence from recent years establish that SOA is not just about hype, but a part of every major Business environment. The truth is, Service Oriented Architecture can be beneficial to Business only when it is utilized properly.
Service Oriented Architecture is no longer a theory – it has moved into the realm of actual initiatives that can ensure that Businesses and investors receive high returns on their investments. It is vital to possess a keen understanding of various Service Oriented Architecture concepts in order to decide whether Service Oriented Architecture is suitable for your Business or not.
This article will thus focus on some of the main concepts behind Service Oriented Architecture and provides you with conceptual knowledge that will help you apply the principles of Service Oriented Architecture to actual projects. It does not matter if you are a member of a software development team or an Information Technology Business working on new applications – these principles are guaranteed to help you reap some of the numerous benefits of Service Oriented Architecture.
Why use Service Oriented Architecture?
Vast majority of Businesses working in the field of Information Technology have to justify their projects with a return on their investments. This puts Information Technology, as a field under enormous pressure. Information Technology must boast requirements that are increasingly responsive and flexible to the shifting needs of different Businesses.
Firms dealing with Information Technology must also be able to face the challenge of taking on an array of software systems that may or may not be compatible with one another. Moreover, Information Technology has to face demands to bring new commercial services to a much wider array of customers. Customers may access services through web interfaces, or may be part of a supply chain that needs to decrease the time and cost of manufacturing.
Thus, Information Technology companies are always on the look out for solutions that will help them meet the above demands – without having to spend a lot of money.
While Service Oriented Architecture may not solve all the problems posed by the increasingly complex realm of Information Technology, employing SOA tactics can bring a lot of benefits and rewards to a company. Typically, these benefits fit into one of the following three categories:
-Standardized interfaces and data models
-Re-use
-Composability
SOA Elements
Let us now take a look at some of the key features of Service Oriented Architecture. The best way to go about doing this is to break SOA down into its acrimonial elements. We’ll start with the last letter first: A for Architecture.
We will first examine architecture in reference to Service Oriented Architecture. Usually, in the realm of software, architecture tends to define the overall intercommunication and definition of different high level components. To put it simply, it is how a solution is broken down into logical units – and how they operate with one another. In a way, Service Oriented Architecture is representative of an approach to architecture that focuses on how services are defined and how they interact with one another.
Service Oriented Architecture is not something you can just go out and purchase. It is a set of architectural principles. While you might be able to directly purchase certain middleware that enables services and technologies, they alone do not constitute a Service Oriented Architecture.
Let us consider 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, Object Oriented Design and Service Oriented Architecture do have a lot of things 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 Service Oriented Architecture. It takes into consideration the needs of both providers and consumers of services.
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 Service Oriented Architecture is merely the latest way to describe the functionality of applications. The fact is, a lot of applications in today’s day and age 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.
Service Oriented Architecture 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, can be somehow woven together in order 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 the game. 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 software system. In this scenario, they co-operate as a means of achieving Business objective, while possibly participating in some other systems that offer similar service capability for a possibly different end solution.
SOA vs. Web Services
People tend to associate Service Oriented Architecture with World Wide Web based services. The two, however, are not one and the same, and thus must be distinguished from one another. Web services will have to be elucidated elsewhere.
For the moment, we are going to focus on Service Oriented Architecture in order to understand how it is distinct from Web based services.
When Object Oriented programming first began to get popular, C++ was an emerging programming language that also had strong support for object oriented methods of programming. But it was not correct to say that a C++ program was object oriented. While object orientation happens to be an architectural approach, C++ is a language through which such an architecture is attained.
One can say the same thing when it comes to Web services and Service Oriented Architecture. “Service Oriented Architecture” is the term that designates a philosophical approach to a solution’s design. The utilization of web services is one method by which such an architecture might be attained.
But the use of web services is not the only way one might go about building a Service Oriented Architecture. Just as it is possible to utilize C++ language without the use of an object oriented program, one can also have web services without the use of Service Oriented Architecture.
SOA vs. Other Architectures
Some observers claim that Service Oriented Architecture is merely another way that services and software can be sold. But SOA is a lot more than merely a buzz word. At the beginning, software was a set of code that ran somewhere on a large mainframe computer. This was where input was provided in the form of, say, punch cards.
As computer technology began to evolve, users would make use of simple text based terminals as a means of entering data, schedule jobs, etc. But software continued to grow larger. Rarely would other forms of software be relied upon to do these jobs.
Business logic steadily evolved over time so that much of the interface was moved to individual users’ desktops, while core Business logic and storage remained on a back room main computer. A lot of these applications still function in Businesses around the globe.
