Service Oriented Architecture : Why SOA?
The vast majority of businesses working in the field of Information Technology in this day and age find themselves having to justify their projects with a return on their investments. This puts Information Technology, as a field, under an enormous amount of pressure. IT 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. What is more, IT has to face demands to bring new commercial services to a much wider array of customers. Customers these days may be accessing 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 these days for solutions that will help them meet these 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 in to one of the following three categories:
- Standardized interfaces and data models
- Re-use
- Composability
Why Use Service Oriented Architecture Now?
One question that people commonly asked after being introduced to the wonders of Service Oriented Architecture is, why haven’t people been using this for the last twenty years? People tend to forget that one of the main things you will need in order to build a system out of parts is a standard method of representing software parts. If no such standard exists, then things can be incredibly difficult. Service Oriented Architecture is not exactly a new thing. Businesses have spent the last fifteen years trying to come up with a set standard. While CORBA and DCOM have been in existence for a while, they never became world wide standards.
It is the Internet that has in many ways set up standards – namely HTTP and HTML – that link together people all over the globe. Businesses witnessing the growth and the development of the Internet decided to use similar strategies to link their own computer systems together. Such businesses first came up with Web services standards. Such services are based on technologies that originated on the Internet and make use of such technologies as XML and HTTP as a means for representing software parts and linking together a number of different computer systems.
In recent years, there has been an adoption of web services as the standards upon which to base Service Oriented Architecture. Software vendors such as webMethods have brought out on to the market a variety of products that have made Service Oriented Architecture quite useful.
What is Service Oriented Architecture?
Businesses are now having to think a lot more seriously about how to best assemble their systems out of common parts. Service Oriented Architecture has caused this change in the way such systems are thought of. 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 architectural programs, systems tend to be composed of reusable elements, which are referred to as services. A services can be thought of as a software building block that performs a specific function – one of them might be retrieving data about a customer from a database. These functions are performed via well defined interfaces, which are electronic descriptions of how to call on a service from other services.
Service Oriented Architecture represents in many ways 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 Service Oriented Architecture, 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 Service Oriented Architecture based system is able to clearly incorporate services running on several different software platforms – even if those services happen to be hosted externally buy third party providers of services.
In truth, there is not a universally agreed upon definition of Service Oriented Architecture, 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 a Service Oriented Architecture 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.
Aspects of Service Oriented Architecture
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 in to 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, this is how a solution is broken down in to logical units – and how they will 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.
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, 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 in to 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 in to 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 in to a sort of ecosystem of software. In this scenario, they cooperate as a means of achieving some sort of business objective, while possibly participating in some other ecosystems that offer similar service capability for a possibly different end solution.
