Web services didn't spring full-
The web services we have today trace their ancestry back to the Sun Remote Procedure Call (RPC) system. This provided a standard way for a client to interact with a server, using the model of a procedure call. A server might offer many services (procedures, identified by
The problem at the time was that the binary representation of values varied depending on the operating system, hardware, and programming languages that created the value. The Sun RPC system
Microsoft extended this model with DCOM, the Distributed Component Object Model. DCOM overcame many of the limitations of data and interface specifications. Remote objects could be accessed as though they were local, and you could even extend a remote interface. DCOM has never really taken off outside the Microsoft world, though.
The leading competitor to DCOM (and its successor, COM+) is the Common Object Request Broker Architecture, known as CORBA. Also object-oriented, CORBA has recognition and acceptance at high levels within large-scale development projects. At the heart of a CORBA implementation is an Object Request Broker (ORB), which takes incoming
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
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
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
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
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
"If we have a lot of similar services, and machine-readable
descriptions of their interfaces," went the