The Evolution of Software Services
In the early days, computer programs were written in assembly language and executed in a single memory space. The software services in this case were subroutines written in assembly language, and they communicated digitally via machine registers. Programs written in this way were not portable, and hard to write and maintain.
Soon after assembly language came procedural languages like FORTRAN and COBOL, which provided a layer of abstraction so that programs could be written more easily and run on different machines. The software services in this case were functions that were orchestrated by control structures, and, like assembly subroutines, they all executed in a single memory space (see Figure 1.2).
FIGURE 1.2 Functions communicating within a single memory space
Network computing followed soon after, allowing systems to exchange information in real-time instead of having to transfer data using magnetic tapes. The UNIX operating system had built-in support for the Transmission Control Protocol/Internet Protocol (TCP/IP) network protocol, and C became the most popular language for writing network applications. A technique called
Remote Procedure Call (RPC) was invented to allow functions written in C, FORTRAN or any other procedural language to invoke each other across a network, allowing software services to break free from the confines of individual machines and collaborate on a large scale. A protocol called eXternal Data Representation (XDR) allowed complex data structures to be sent between functions regardless of platform or language (see Figure 1.3).
FIGURE 1.3 Functions communicating between memory spaces using RPC
After procedural languages came functional languages like LISP and object-oriented languages like C++, which provided still higher levels of abstraction and allowed developers to create software objects that resembled their real-world counterparts. And as you've probably guessed, an object is yet another example of a software service, only this time it happens to encapsulate its behavior and support polymorphism. New distributed computing protocols were designed to allow objects to communicate in a more natural fashion than RPC, and the most successful were CORBA (Common Object Request Broker Architecture) and DCOM (Distributed Common Object Model). A consortium of large companies supported CORBA, including IBM, Oracle and Sun, whereas DCOM came from a single vendor, namely Microsoft. Most early deployments of these technologies were in homogenous, closed environments (see Figure 1.4).
FIGURE 1.4 Two LANs, one using CORBA and one using DCOM
Regardless of their relative technical merits, the most annoying thing for developers was that CORBA and DCOM were incompatible, and it was hard work to get them to communicate with each other. If you wanted to link systems that used different protocols, you would typically install protocol converters on each gateway (see Figure 1.5).
Figure 1.5 Two LANs, connected using a CORBA/DCOM bridge
Then the Internet burst onto the scene. Thanks to the inventions of Tim Berners-Lee, anyone could use a browser to surf and enjoy the vast amount of information stored on millions of computers around the world. Traditional geographic barriers started to fall, and consumers were able to purchase from any company that had a web site. The Internet is based on a single, simple set of open standards. HyperText Transport Protocol (HTTP), the transport protocol for sharing data between machines, is quick to implement and rides on top of the ubiquitous lower-level TCP/IP protocol. And Hyper-Text Markup Language (HTML), the format for representing data in a browser-friendly way, can be understood by a teenager in a few hours. Ease of use certainly helped the adoption of the Internet (see Figure 1.6).
FIGURE 1.6 HTML and HTTP make it easy for people to share content across the Internet
The Internet opened a lot of people's eyes to the power of distributed computing, and businesses started investing more time into harnessing the power of networking. But although HTTP and HTML made it easier for consumers to access remote web pages, they didn't simplify the integration of business systems. What was missing was a way to share data and software services across the Internet.
The sharing of data was addressed by XML, a more sophisticated and general-purpose version of HTML that allows any kind of data to be represented in a simple and portable way. By surrounding data with tags that indicate its meaning, XML documents are self-describing and can be easily manipulated and transformed (see Figure 1.7).
FIGURE 1.7 A simple XML document
HTML and HTTP make it easy for people to share content across the Internet
The sharing of services, which is basically what this book is all about, is being tackled by a new set of standards called SOAP1 (Service-Oriented Architecture Protocol), WSDL (Web Services Description Language) and UDDI (Universal Description, Discovery, and Integration). Built on top of HTTP and XML, these standards allow software services to be published, located and invoked in a way that is language, platform and location independent. Software building blocks created and deployed using this technology are called web services (see Figure 1.8).
FIGURE 1.8 SOAP is a universal protocol for connecting everything
Web services are important because they greatly simplify the creation and integration of large-scale distributed systems. In the same way that HTML catalyzed a vast web of human-accessible content, SOAP, WSDL, and UDDI will enable a web of machine-accessible services. Let's take a closer look at these three key technologies.