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.
Web services can be accessed by any other Web service, meaning that they can be assembled together to create new applications relatively quickly. An SOA is a collection of these dynamically configurable, reusable Web services.
Often, An SOA will be supported by other things, including a Universal Description, Discovery and Integration (UDDI) registry. Think of this as a directory listing of available Web services along with descriptions of what they do and how they can be accessed.
An enterprise service bus (ESB) coordinates the messaging between different Web services, based on different events and business conditions. This can help to prevent an SOA from becoming too complex and incoherent.
Business
The initial investment overhead for SOAs can be very high because IT departments will often have to adapt a traditional set of monolithic applications to the new, service-based model.
IT departments must understand, however, that SOA is more than just a technology project. Because an SOA can have profound effects on the way that a business develops it is important to get business managers intimately involved when building one. The "service" within SLA will almost inevitably be a business-focused service. Therefore, understanding what services the business needs when defining new business applications is imperative from the start.
