Service Fundamentals

A service defines a contract between a calling client and the service itself. In English, this contract states something like this: “If you send me data in this format, I will process it and return you the results in this other format.” The format of this data and the communication parameters of these calls are based on open standards (such as HTTP, XML, JSON, SOAP, and WSDL). These service standards apply across technology boundaries and therefore make services attractive for exchanging data between heterogeneous environments.

To frame the benefits of services, it can be helpful to think of them within the context of the problems they were designed to solve. For example, many large companies have multiple applications that need to access and update similar information. They might, for instance, rely on customer data records inside a customer relationship management (CRM) system, an order-processing application, a logistics tool, an enterprise resource planning (ERP) system, and a reporting package. In this case, the customer record is duplicated per system. This means the data may be contradictory (or out of date) in any one system. Companies might have band-aids in place, such as batch processing that tries to keep the data in sync on a regular basis. Figure 19.1 illustrates this problem example.

FIGURE 19.1 Heterogeneous applications often share data and have similar needs around that data. Nightly batch processing to update data across applications is not the best way to solve this dilemma.

What’s worse, a company might have multiple systems that offer the same functionality (such as two CRM systems). This can happen if the company has grown through acquisition and merger activities or if each department has chosen its own technology. In fact, even if a company wrote all these applications from scratch, you often see duplicate (or similar) code in each application for doing the same thing. This code, of course, has to be maintained, and changes to it can often have unintended consequences on the other systems.

These problems are what service-oriented solutions are intended to solve. Consider that each of the applications in the earlier example might work on different servers running different code on different operating systems. They often even have different database technologies. Therefore, a reusable component that could be plugged into each application could not be easily created. Even if it did, the need to centralize this information into a common view would still exist. For example, an update to a customer record in one system needs to somehow be recorded in the other systems.

What is required to solve this problem (and problems like it) is a common shared interface into a centralized view of the data (in this example, customer data). This interface should be able to work across application boundaries such as protocols, data types, and processes. Architects recognized this problem but did not see a viable solution until the advent of the Web. With web technologies, the HTTP protocol was ubiquitous. Servers could talk to each other. Then along came the XML standard for describing messages and later the more lightweight JavaScript Object Notation (JSON). With a ubiquitous protocol such as HTTP and standard message formats like XML and JSON, applications running on different platforms had a way to communicate.