When the client is run, it contacts the server via SOAP, gets a random
number freshly generated for it, and outputs that number. The Perl
modules are handling all the nasty behind-the-scenes work of creating
HTTP headers and encoding XML schemas.
The proxy() method points to the URL of the actual procedure
you want to run on the server — in this case, the script we just wrote.
It's not to be confused with uri(), which is where the
namespace of the server-side SOAP code is defined. The argument to the
uri() method looks like a URL, but it's not. The "http://" part of
uri()'s argument specifies the transport protocol; the server name is
the server name, right; and then the class to be invoked is last. There
isn't a directory called Random on the server.
What's happening behind the scenes is this: The client script sends a
SOAP payload to the server via HTTP. This message consists of an HTTP
header followed by a SOAP envelope generated by the Perl module.
What the client sends to the server actually looks something like this:
POST /random.cgi HTTP/1.1
Content-Type: text/xml; charset="utf-8"
Content-Length: 124
<?xml version="1.0"?>
<s:Envelope
xmlns:s="http://www.w3.org/2001/12/soap-envelope"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<s:Body>
<m:Random xmlns:m="urn:Random">
</m:Random>
</s:Body>
</s:Envelope>
The "xmlns" lines declare default namespaces, whose purpose is to ensure
that there's no conflict between the envelope we're creating and another
one somewhere that might use the same name. We're referring to
predefined namespaces for our schema and envelope, ones that are just
sitting there on the W3C's machines waiting to be used. But this is the
aspect that SOAP::Lite takes care of for you, so understanding it is
secondary for the time being. Again, the W3C specification explains it all in
great detail.
next page»
