1.2 The Web Services Dream

From this melting pot of history came web services. Dissatisfaction with various aspects of Sun RPC, COM, and CORBA lead programmers to look for glue that had the best parts of all of these systems (cross-platform, high-level, interlanguage) and left behind the drawbacks (complex ORB systems, proprietary ownership, and confusing IDLs).

Web services escape being shackled to particular hardware or languages by using the Extensible Markup Language (XML) to represent data. There are XML parsers available for everything from embedded systems to supercomputers, and almost every conceivable programming language (including Perl!). The ubiquity of XML parsers and the platform neutrality of the XML standard means that web services designers don't have to worry about the issues of byte ordering and datatype size that were a major hurdle for the Sun RPC designers.

To get away from the complexity of ORBs, sockets, and all manner of connectivity hassles, web services are built on top of the Hypertext Transfer Protocol (HTTP). HTTP is also ubiquitous, with web servers available for almost every platform. A server is identified by a URL, and managing communication simply becomes a problem of mapping a procedure call onto an HTTP request and response (this mapping is quite natural, as we'll see in Chapter 2).

XML-RPC was the first web service protocol, forked from the early development of SOAP (Simple Object Access Protocol). As the name XML-RPC suggests, it only tries to encode procedure calls. It defines a standard way to encode data, method calls, and exceptions. It's quite simple, and has gained popularity in the world of scripting languages such as Perl and Python, because its type system is very similar to those of most scripting languages. Chapter 3 and Chapter 4 show how to develop XML-RPC servers and clients in Perl.

SOAP attempts to solve more problems than XML-RPC. It introduces headers for extensibility, which opens the door to security, routing, and other concepts. It separates somewhat from HTTP so that you can use other systems, such as instant messaging or low-level network connections, to pass messages between servers and clients. You can have requests without responses (in an asynchronous environment you may never get a response) and responses without requests (continually broadcasting temperature data, for example). It can also be used in document style, in which servers and clients exchange XML documents that don't necessarily represent method calls and responses (invoices and receipts, for example).

The increased power of SOAP comes at a price, though: complexity. As you'll see in Chapter 5, the SOAP standard is considerably harder to grasp than XML-RPC. But the power of SOAP has attracted many in corporate and enterprise programming, where SOAP is often used for systems integration. Chapter 6, Chapter 7, and Chapter 8 show how to develop SOAP clients and servers in Perl.

Web services designers tried hard not to throw out the baby with the bathwater, though. CORBA's IDL, from which glue code is automatically generated, has a counterpart in the Web Services Description Language (WSDL). A WSDL document is an XML file that describes the interfaces (method names , parameters, return values) offered by a service. While primarily the realm of statically typed precompiled languages such as Java and C++, Perl can produce and consume WSDL. Chapter 9 explains more about this.

"If we have a lot of similar services, and machine-readable descriptions of their interfaces," went the next web services brainwave , "why not have our client programs find and use a service at runtime instead of hardwiring a particular server and interface in at compile-time?" The Universal Description, Discovery, and Integration (UDDI) project provides a system to do just this kind of loose coupling of server and client. It's like a search engine for web services, so your program only has to know which UDDI server(s) to learn the details of any service it wants to talk to. UDDI is the focus of Chapter 10.