SOA explained

Speak to most IT departments concerned about their business users, and they will tell you that one of their biggest challenges is staying agile enough to support those users as conditions change. If a finance company needs to launch a new product, for example, and it wants to reduce its time to market to beat the competition it will need the IT department to provide the necessary software services in short order. In that sense, a service-oriented architecture (SOA) is a new solution to an age-old problem.

The simplest definition of a SOA is a collection of business software components that are defined as services (say, a currency conversion service). These services can be used by any other piece of software within the SOA. In this way, new applications can be built by reusing the services as needed. When building the application to support the new product, the finance company's IT department would be able to use the existing currency conversion service and reduce its development times.

Why SOA was needed

Ever since the development of open systems, when companies began using hardware and software from different suppliers, information technology has faced a growing integration problem. Getting different software applications to talk to each other has become harder as the number and age of applications has grown. For many companies this has created a disconnected set of "stovepipe" applications. Data about the same things (such as customers) is stored more than once in different formats. And different software applications sometimes do the same things in different ways.

This in turn makes it harder for IT to fulfil its role within the company. Businesses increasingly need to be agile, but the more rigid the business applications and the less able they are to share each other's data and processes the more complex and inflexible the business's software becomes and the harder it is to help senior managers take the business quickly in new directions.

The long road to SOA

Technology experts have long understood this problem, but the road to true integration has been a long one. Companies originally used Remote Procedure Calls (RPCs) to let one application access the functions of another. Then, in the early Nineties, companies began carving up large software applications into small "objects" that could be reused in different applications, making them easier to build and integrate with each other.

The Common Object Request Broker Architecture (CORBA) standard was developed to make this happen but it was largely restricted to specialist applications in large finance and telecommunications companies. The development process was very complex and objects could not be reused easily in different configurations.

Enterprise application integration (EAI) attempted to simplify everything with middleware brokering mechanisms. It took outputs from one piece of software and converted them into the proprietary formats used by others. It enabled different pieces of software to interact, but it was still complex and expensive.

Web services - the answer to SOA

In 2000, a new protocol appeared Called the Simple Object Access Protocol (SOAP), enabling software applications to communicate with each other. It was based on the extensible mark up language (XML), which is a plain text language used to create protocols communicable over the Web. SOAP provided an easy way for software applications to access each other's services using a standard interface. Software communicating in this way is called a Web service.

Email to a friend

Print this page