Chapter 18. Internet Services
Correct use of sockets is only part of writing programs that communicate over the network. Once you have a way for two programs to talk, you still need a protocol for communication. This protocol lets each party know when to talk, and it precisely defines who is responsible for which part of the service.
Table 18-1. Common Internet protocols
Even something as relatively simple as connecting to a remote computer requires intricate negotiations between client and server. If you had to write the Perl code to implement these protocols each time you wanted to use a network service, you'd probably end up writing a lot of buggy programs, trying to get demoted into a management position, or both.
Fortunately, Perl has modules for these protocols. Most modules implement the client side of the protocol rather than the server side. This is because most clients make one query at a time, whereas a server must be prepared to deal with multiple clients and that code can get quite tricky. That said, there are FTP (Net::FTPServer), HTTP (HTTP::Daemon, POE::Component::Server::HTTP), SMTP (POE::Component:Server::SMTP), and IRC (POE::Component::Server::IRC) servers on CPAN.
Most of these modules fall under the Net:: hierarchy, a common subset of which has been included standard with Perl since v5.8. We use Net::FTP to send and receive files using FTP, Net::NNTP to read and post Usenet news, Net::Telnet (from CPAN) to simulate a connection to another machine, Net::Ping to check whether a machine is alive, and Net::POP3 and Mail::Mailer (from CPAN) to receive and send mail. We cover the CGI protocol in Chapter 19, and with HTTP in Chapter 20.
Recent years have seen a growth in web services, i.e., services offered through the web's HTTP protocol. Chapter 19, Chapter 20, and Chapter 21 address the Web in more detail, but we cover web services in this chapter. The three main ways of offering web services are XML-RPC, SOAP, and REST.
XML-RPC is a simple way to make remote procedure calls. You can transport XML-RPC requests ("I want to call this method with these arguments") and responses ("this fault occurred" or "this is what the method returned") across protocols like HTTP, SMTP, Jabber, and so on. The XMLRPC::Lite modules handle translation between Perl function calls and the XML representation that goes across the wire.
SOAP is more complex than XML-RPC, providing more OO and exception support. It also offers a "document mode," where the response is an XML document rather than an encoded data structure; for example, you might submit an order and get back an XML receipt. SOAP has more built-in data types than XML-RPC and lets you define custom data types using W3C Schema. Like XML-RPC, SOAP runs over a variety of protocols. Both SOAP and XML-RPC are implemented in the SOAP-Lite distribution.
Representational State Transfer (REST) is a different way of viewing web services. Rather than writing remote procedure calls and encoding arguments, which exposes the implementation, REST offers a way to separate implementation from how the client accesses a particular resource. In REST, a URL is an object's address. You can use GET, POST, PUT, and DELETE methods to fetch, change state, create, update, and delete. Because it's more a design philosophy than an API or encoding, we don't cover it here. The book Programming Web Services with Perl, by Randy Ray and Pavel Kulchenko (O'Reilly), gives an introduction to REST.
You can thank Graham Barr, whose IO::Socket modules we used for low-level network communication in Chapter 17, for most of these modules. He also wrote Net::FTP, Net::NNTP, Net::POP3, and Mail::Mailer. Jay Rogers wrote Net::Telnet, and Paul Kulchenko developed the SOAP-Lite toolkit. Thank these folks that you don't have to reinvent these tricky wheels!
Copyright © 2003 O'Reilly & Associates. All rights reserved.