1SOAP::Transport(3) User Contributed Perl Documentation SOAP::Transport(3)
2
6 SOAP::Transport - an abstract class extended by more specialized
7 transport modules
8
10 Objects of the SOAP::Transport class manage two roles: they manage both
11 the parameters related to transport as set through the containing
12 SOAP::Lite object, and they abstract the selection and loading of an
13 appropriate transport module. This is done with an AUTOLOAD function
14 within the class that intercepts all methods beyond the two defined
15 next and reroutes them to the underlying transport implementation code.
16
18 new
19 $trans = SOAP::Transport->new;
20 This is the constructor, which isn't usually called by an
22 application directly. An application can use this to create a fresh
23 new SOAP::Transport object, which may be installed using the
24 SOAP::Lite->transport method defined earlier. No arguments are
25 recognized.
26 proxy(optional URL string)
28 $trans->proxy('http://www.blackperl.com/SOAP');
29 Gets or sets the proxy (endpoint). This method must be called
31 before any other methods are called. The proper transport code is
32 loaded based on the scheme specified by the URL itself (http,
33 jabber, etc.). Until this method is called the first time with a
34 URL string, the underlying code has yet to be loaded, and the
35 methods aren't available. When getting the current proxy (calling
36 with no parameters), the returned value is a reference to the
37 client object created from the protocol class that matched the
38 endpoint, not the endpoint itself.
39
41 Because the bulk of the work is done within the "SOAP::Lite" module
42 itself, many of the transport-level modules are very simple in their
43 implementations. Transport modules are expected to define both client
44 and server classes within their files. If a module defines only one of
45 the types, it is assumed that the transport protocol itself supports
46 only that side of the conversation. An example is SOAP::Transport::FTP,
47 which provides only a "SOAP::Transport::FTP::Client" class.
48 "SOAP::Transport::FTP" - Client class only
50 "SOAP::Transport::HTTP" - Client, and server classes for CGI, FCGI,
52 Daemon and mod_perl
53 "SOAP::Transport::IO" - Server class only
55 "SOAP::Transport::JABBER" - Server and Client classes
57 "SOAP::Transport::LOCAL" - Client class only
59 "SOAP::Transport::MAILTO" - Client class only
61 "SOAP::Transport::MQ" - Server and Client classes
63 "SOAP::Transport::POP3" - Server class only
65 "SOAP::Transport::TCP" - Server and Client classes
67 METHODS
69 Each SOAP::Transport sub-class is expected to define (or inherit, if it
70 is subclassing another transport class) at least two methods. Any newly
71 developed transport classes are also expected to adhere to this
72 interface. Clients are expected to implement the "new" and
73 "send_receive" methods, and servers are expected to implement the "new"
74 and "handle" methods. Here they are:
75 new(optional key/value pairs)
77 $object = $class->new(%params);
78 Creates a new object instance and returns it. Like the constructors
80 for both "SOAP::Lite" and SOAP::Server classes, all arguments
81 passed in are treated as key/value pairs, where the key is expected
82 to be one of the methods the class supports, and the value is the
83 argument (or list reference of arguments) to the method.
84 send_receive(key/value pairs)
86 $client->send_recieve(%hash_table);
87 (Required for client classes only) When the SOAP::Lite objects
89 attempt to send out requests, the means for doing so is to attempt
90 to call this method on the object held within the SOAP::Transport
91 object contained within the client itself. All clients are expected
92 to provide this, and the call to this method always passes four
93 values for the hash keys:
94 action
96 The URI specifying the action being performed, usually the
97 result from the on_action hook on the client object.
98 encoding
100 The URI of the encoding scheme that governs the message being
101 sent.
102 endpoint
104 The URI specifying the endpoint to which the message is being
105 sent.
106 envelope
108 The XML content of the message to be sent. It is generally the
109 return value of the envelope method from the SOAP::Serializer
110 object instance that the client object maintains.
111 parts
113 Attachments to add to the request. Currently this only supports
114 an array of MIME::Entity objects, but in theory could support
115 attachments of any format.
116 handle
118 $server->handle;
119 (Required for server classes only.) This method is the central
121 point for the various server classes to provide an interface to
122 handling requests. The exact set and nature of parameters generally
123 varies based on the classes themselves.
124 SOAP::Transport::HTTP
126 The most commonly used transport module is the HTTP implementation.
127 This is loaded whenever an endpoint is given that starts with the
128 characters, http:// or https://. This is also the most involved of the
129 transport modules, defining not only a client class but several
130 different server classes as well.
131 HTTP PROXY SETTINGS
133 Because "SOAP::Client" inherits from "LWP::UserAgent", you can use any
135 of "LWP::UserAgent"'s proxy settings. For example:
136 SOAP::Lite->proxy("http://endpoint.server/",
138 proxy => ["http" => "http://my.proxy.server"]);
139 or
141 $soap->transport->proxy("http" => "http://my.proxy.server");
143 The above code samples should specify a proxy server for you. And
145 should you use "HTTP_proxy_user" and "HTTP_proxy_pass" for proxy
146 authorization, "SOAP::Lite" will handle it properly.
147 HTTP BASIC AUTHENTICATION
149 HTTP Basic authentication is accomplished by overriding the
151 get_basic_credentials suboutine in "LWP::UserAgent" (which
152 "SOAP::Transport::HTTP::Client" is a subclass):
153 BEGIN {
155 sub SOAP::Transport::HTTP::Client::get_basic_credentials {
156 return 'username' => 'password';
157 }
158 }
159 COOKIE-BASED AUTHENTICATION
161 use HTTP::Cookies;
163 my $cookies = HTTP::Cookies->new(ignore_discard => 1);
164 # you may also add 'file' if you want to keep them between sessions
165 my $soap = SOAP::Lite->proxy('http://localhost/');
166 $soap->transport->cookie_jar($cookies);
167 Or, alternatively, you can do the above on a single line:
169 $soap->proxy('http://localhost/',
171 cookie_jar => HTTP::Cookies->new(ignore_discard => 1));
172 Cookies will be taken from the response and provided to the request.
174 You may access and manipulate cookies received, as well as add cookies
175 of your own by using the "HTTP::Cookies" interfaces.
176 SSL CERTIFICATE AUTHENTICATION
178 To get certificate authentication working you need to set three
180 environment variables: "HTTPS_CERT_FILE", "HTTPS_KEY_FILE", and
181 optionally "HTTPS_CERT_PASS". This can be done either through the
182 command line, or directly within your Perl script using the $ENV
183 variable:
184 $ENV{HTTPS_CERT_FILE} = 'client-cert.pem';
186 $ENV{HTTPS_KEY_FILE} = 'client-key.pem';
187 These settings are referrenced by "Crypt::SSLeay", the module
189 SOAP::Lite used for HTTPS support. Other options (e.g. CA peer
190 verification) can be specified in a similar way. See Crypt::SSLeay
191 documentation for more information.
192 Those who would like to use encrypted keys may find the following
194 thread in the SOAP::Lite newsgroup helpful:
195 http://groups.yahoo.com/group/soaplite/message/729
197 COMPRESSION
199 SOAP::Lite provides you with the option for enabling compression over
201 the wire using HTTP only in both the server and client contexts,
202 provided that you have Compress::Zlib installed. Compression and
203 decompression is done transparantly to your application.
204 A server will respond with an encoded/compressed message only if the
206 client has asserted that it can accept it (indicated by client sending
207 an "Accept-Encoding" HTTP header with a 'deflate' or '*' value).
208 "SOAP::Lite" clients all have fallback logic implemented so that if a
210 server doesn't understand the specified encoding (i.e. "Content-
211 Encoding: deflate") and returns the proper HTTP status code (415 NOT
212 ACCEPTABLE), the client will repeat the request without using
213 encoding/compression. The client will then store this server in a per-
214 session cache, so that all subsequent requests to that server will be
215 transmitted without encoding.
216 Compression is enabled on the client side by specifying the
218 "compress_threshold" option, and if the size of the current request
219 exceeds that threshold.
220 Client Code Sample
222 print SOAP::Lite
224 ->uri('http://localhost/My/Parameters')
225 ->proxy('http://localhost/', options => {compress_threshold => 10000})
226 ->echo(1 x 10000)
227 ->result;
228 Servers will respond with a compressed message if the
230 "compress_threshold" option has been specified, if the size of the
231 current response exceeds that threshold, and if the calling client
232 transmitted the proper "Accept-Encoding" HTTP Header.
233 Server Code Sample
235 my $server = SOAP::Transport::HTTP::CGI
237 ->dispatch_to('My::Parameters')
238 ->options({compress_threshold => 10000})
239 ->handle;
240 See also: Compress::Zlib
242 SOAP::Transport::HTTP::Client
244 Inherits from: SOAP::Client, LWP::UserAgent (from the LWP package).
246 With this class, clients are able to use HTTP for sending messages.
248 This class provides just the basic new and send_receive methods.
249 Objects of this class understand the compress_threshold option and use
250 it if the server being communicated to also understands it.
251 CHANGING THE DEFAULT USERAGENT CLASS
253 By default, "SOAP::Transport::HTTP::Client" extends "LWP::UserAgent".
255 But under some circumstances, a user may wish to change the default
256 UserAgent class with their in order to better handle persist
257 connections, or to "LWP::UserAgent::ProxyAny", for example, which has
258 better Win32/Internet Explorer interoperability.
259 One can use the code below as an example of how to change the default
261 UserAgent class.
262 use SOAP::Lite;
264 use SOAP::Transport::HTTP;
265 $SOAP::Transport::HTTP::Client::USERAGENT_CLASS = "My::UserAgent";
266 my $client = SOAP::Lite->proxy(..)->uri(..);
267 my $som = $client->myMethod();
268 There is one caveat, however. The UserAgent class you use, MUST also be
270 a subclass of "LWP::UserAgent". If it is not, then "SOAP::Lite" will
271 issue the following error: "Could not load UserAgent class <USERAGENT
272 CLASS>."
273 HTTP-KEEP-ALIVE, TIMEOUTS, AND MORE
275 Because "SOAP::Transport::HTTP::Client" extends "LWP::UserAgent", all
277 methods available "LWP::UserAgent" are also available to your SOAP
278 Clients. For example, using "LWP::UserAgent" HTTP keep alive's are
279 accomplished using the following code:
280 my $ua = LWP::UserAgent->new(
282 keep_alive => 1,
283 timeout => 30
284 );
285 Therefore, the same initialization parameters you would pass to
287 "LWP::UserAgent" can also be passed to your SOAP::Lite client's "proxy"
288 subroutine like so:
289 my $soap = SOAP::Lite
291 ->uri($uri)
292 ->proxy($proxyUrl,
293 timeout => 30,
294 keep_alive => 1,
295 );
296 This is true for all initialization parameters and methods of
298 "LWP::UserAgent".
299 METHODS
301 http_request
303 This method gives you access to a prototype of the HTTP Request
304 object that will be transmitted to a SOAP::Server. The actual
305 request used is a copy of that object.
306 Do not use this method for anything else than setting prototypic
308 behaviour for the client object.
309 http_response
311 This method gives you access to the HTTP Response object that will
312 be, or was transmitted to a SOAP Server. It returns a
313 HTTP::Response object.
314 SOAP::Transport::HTTP::Server
316 Inherits from: SOAP::Server.
318 This is the most basic of the HTTP server implementations. It provides
320 the
321 basic methods, new and handle. The handle method's behavior is defined
322 here,
323 along with other methods specific to this class. The role of this
324 class is
325 primarily to act as a superclass for the other HTTP-based server
326 classes.
327 handle
329 $server->handle;
330 Expects the request method to have been used to associate a
332 HTTP::Request object with the server object prior to being called.
333 This method retrieves that object reference to get at the request
334 being handled.
335 request(optional value)
337 $server->request($req_object)
338 Gets or sets the HTTP::Request object reference that the server
340 will process within the handle method.
341 response(optional value)
343 $server->response(HTTP::Response->new(...));
344 Gets or sets the HTTP::Response object reference that the server
346 has prepared for sending back to the client.
347 make_response(code, body)
349 $server->make_response(200, $body_xml);
350 Constructs and returns an object of the HTTP::Response class, using
352 the response code and content provided.
353 make_fault(fault arguments)
355 $server->response($server->make_fault(@data));
356 Creates a HTTP::Response object reference using a predefined HTTP
358 response code to signify that a fault has occurred. The arguments
359 are the same as those for the make_fault method of the SOAP::Server
360 class.
361 product_tokens
363 This method takes no arguments and simply returns a string
364 identifying the elements of the server class itself. It is similar
365 to the product_tokens methods in the HTTP::Daemon and Apache
366 classes.
367 SOAP::Transport::HTTP::CGI
369 Inherits from: SOAP::Transport::HTTP::Server.
371 This class is a direct subclass of SOAP::Transport::HTTP::Server and
373 defines no additional methods. It includes logic in its implementation
374 of the handle method that deals with the request headers and parameters
375 specific to a CGI environment.
376 EXAMPLE CGI
378 The following code sample is a CGI based Web Service that converts
380 celcius to fahrenheit:
381 #!/usr/bin/perl
383 use SOAP::Transport::HTTP;
384 SOAP::Transport::HTTP::CGI
385 ->dispatch_to('C2FService')
386 ->handle;
387 BEGIN {
388 package C2FService;
389 use vars qw(@ISA);
390 @ISA = qw(Exporter SOAP::Server::Parameters);
391 use SOAP::Lite;
392 sub c2f {
393 my $self = shift;
394 my $envelope = pop;
395 my $temp = $envelope->dataof("//c2f/temperature");
396 return SOAP::Data->name('convertedTemp' => (((9/5)*($temp->value)) + 32));
397 }
398 }
399 EXAMPLE APACHE::REGISTRY USAGE
401 Using a strictly CGI based Web Service has certain performance
403 drawbacks. Running the same CGI under the Apache::Registery system has
404 certain performance gains.
405 httpd.conf
407 Alias /mod_perl/ "/Your/Path/To/Deployed/Modules"
409 <Location /mod_perl>
410 SetHandler perl-script
411 PerlHandler Apache::Registry
412 PerlSendHeader On
413 Options +ExecCGI
414 </Location>
415 soap.cgi
417 use SOAP::Transport::HTTP;
419 SOAP::Transport::HTTP::CGI
421 ->dispatch_to('/Your/Path/To/Deployed/Modules', 'Module::Name', 'Module::method')
422 ->handle;
423 WARNING: Dynamic deployments with "Apache::Registry" will fail because
425 the module will be only loaded dynamically the first time. Subsequent
426 calls will produce "denied access" errors because once the module is
427 already in memory "SOAP::Lite" will bypass dynamic deployment. To work
428 around this, simply specify both the full PATH and MODULE name in
429 "dispatch_to()" and the module will be loaded dynamically, but will
430 then work as if under static deployment. See
431 examples/server/soap.mod_cgi as an example.
432 SOAP::Transport::HTTP::Daemon
434 Inherits from: SOAP::Transport::HTTP::Server.
436 The SOAP::Transport::HTTP::Daemon class encapsulates a reference to an
438 object of the HTTP::Daemon class (from the LWP package). The class
439 catches methods that aren't provided locally or by the superclass and
440 attempts to call them on the HTTP::Daemon object. Thus, all methods
441 defined in the documentation for that class are available to this class
442 as well. Any that conflict with methods in
443 SOAP::Transport::HTTP::Server (such as product_tokens) go to the
444 superclass. Additionally, the behavior of the handle method is specific
445 to this class:
446 handle
448 When invoked, this method enters into the typical accept loop in
449 which it waits for a request on the socket that the daemon object
450 maintains and deals with the content of the request. When all
451 requests from the connection returned by the accept method of the
452 HTTP::Daemon object have been processed, this method returns.
453 REUSING SOCKETS ON RESTART
455 Often when implementing an HTTP daemon, sockets will get tied up when
457 you try to restart the daemon server. This prevents the server from
458 restarting. Often users will see an error like "Cannot start server:
459 port already in use." To circumvent this, instruct SOAP::Lite to reuse
460 open sockets using "Reuse => 1":
461 my $daemon = SOAP::Transport::HTTP::Daemon
463 -> new (LocalPort => 80000, Reuse => 1)
464 EXAMPLE DAEMON SERVER
466 use SOAP::Transport::HTTP;
468 # change LocalPort to 81 if you want to test it with soapmark.pl
469 my $daemon = SOAP::Transport::HTTP::Daemon
470 -> new (LocalAddr => 'localhost', LocalPort => 80)
471 # specify list of objects-by-reference here
472 -> objects_by_reference(qw(My::PersistentIterator My::SessionIterator My::Chat))
473 # specify path to My/Examples.pm here
474 -> dispatch_to('/Your/Path/To/Deployed/Modules', 'Module::Name', 'Module::method')
475 ;
476 print "Contact to SOAP server at ", $daemon->url, "\n";
477 $daemon->handle;
478 SOAP::Transport::HTTP::Apache
480 Inherits from: SOAP::Transport::HTTP::Server.
482 This class provides an integration of the SOAP::Server base class with
484 the mod_perl extension for Apache. To work as a location handler, the
485 package provides a method called handler, for which handle is made an
486 alias. The new method isn't functionally different from the superclass.
487 Here are the other methods provided by this class:
488 handler(Apache request)
490 $server->handler($r)
491 Defines the basis for a location handler in the mod_perl fashion.
493 The method expects an Apache request object as the parameter, from
494 which it pulls the body of the request and calls the superclass
495 handle method.
496 Note that in this class, the local method named handle is aliased
498 to this method.
499 configure(Apache request)
501 $server->configure(Apache->request);
502 Per-location configuration information can be provided to the
504 server object using the Apache DirConfig directive and calling this
505 method on the object itself. When invoked, the method reads the
506 directory configuration information from Apache and looks for lines
507 of the form:
508 method => param
510 Each line that matches the pattern is regarded as a potential
512 method to call on the server object, with the remaining token taken
513 as the parameter to the method. Methods that take hash references
514 as arguments may be specified as:
515 method => key => param, key => param
517 The key/value pairs will be made into a hash reference on demand.
519 If the server object doesn't recognize the named method as valid,
520 it ignores the line.
521 EXAMPLE APACHE MOD_PERL SERVER
523 See examples/server/Apache.pm and Apache::SOAP for more information.
525 httpd.conf
527 <Location /soap>
529 SetHandler perl-script
530 PerlHandler SOAP::Apache
531 PerlSetVar options "compress_threshold => 10000"
532 </Location>
533 SOAP::Apache.pm
535 package SOAP::Apache;
537 use SOAP::Transport::HTTP;
538 my $server = SOAP::Transport::HTTP::Apache
539 ->dispatch_to('/Your/Path/To/Deployed/Modules', 'Module::Name', 'Module::method');
540 sub handler { $server->handler(@_) }
541 1;
542 See also Apache::SOAP.
544 SOAP::Transport::HTTP::FCGI
546 Inherits from: SOAP::Transport::HTTP::CGI.
548 This is an extension of the SOAP::Transport::HTTP::CGI that implements
550 the differences needed for the FastCGI protocol. None of the methods
551 are functionally different.
552 SOAP::Transport::IO
554 The SOAP::Transport::IO-based class allows for a sort of I/O proxying
555 by allowing the application to configure what files or filehandles are
556 used. This module supplies only a server class.
557 SOAP::Transport::IO::Server
559 Inherits from: SOAP::Server.
561 The server class defined here inherits all methods from SOAP::Server,
563 and adds two additional methods specific to the nature of the class:
564 in
566 $server->in(IO::File->new($file));
567 Gets or sets the current filehandle being used as the input source.
569 out
571 $server->out(\*STDERR);
572 Gets or sets the filehandle being used as the output destination.
574 SOAP::Transport::LOCAL
576 The SOAP::Transport::LOCAL module is designed to provide a no-transport
577 client class for tracing and debugging communications traffic. It links
578 SOAP::Client and SOAP::Server so that the same object that "sends" the
579 request also "receives" it.
580 SOAP::Transport::LOCAL::Client
582 Inherits from: SOAP::Client, SOAP::Server. The implementations of the
584 new and send_receive methods aren't noticeably different in their
585 interface. Their behavior warrants description, however:
586 new When the constructor creates a new object of this class, it sets up
588 a few things beyond the usual SOAP::Client layout. The is_success
589 method is set to a default value of 1. The dispatch_to method
590 inherited from SOAP::Server is called with the current value of the
591 global array @INC, allowing the client to call any methods that can
592 be found in the current valid search path. And as with most of the
593 constructors in this module, the optional key/value pairs are
594 treated as method names and parameters.
595 send_receive
597 The implementation of this method simply passes the envelope
598 portion of the input data to the handle method of SOAP::Server.
599 While no network traffic results (directly) from this, it allows
600 for debug signals to be sent through the SOAP::Trace facility.
601 SOAP::Transport::MAILTO
603 This transport class manages SMTP-based sending of messages from a
604 client perspective. It doesn't provide a server class. The class gets
605 selected when a client object passes a URI to proxy or endpoint that
606 starts with the characters, mailto:.
607 SOAP::Transport::MAILTO::Client
609 Inherits from: SOAP::Client.
611 The client class for this protocol doesn't define any new methods. The
613 constructor functions in the same style as the others class
614 constructors. The functionality of the send_receive method is slightly
615 different from other classes, however.
616 When invoked, the send_receive method uses the MIME::Lite package to
618 encapsulate and transmit the message. Because mail messages are one-way
619 communications (the reply being a separate process), there is no
620 response message to be returned by the method. Instead, all the status-
621 related attributes (code, message, status, is_success) are set, and no
622 value is explicitly returned.
623 SOAP::Transport::POP3
625 POP3 support is limited to a server implementation. Just as the MAILTO
626 class detailed earlier operates by sending requests without expecting
627 to process a response, the server described here accepts request
628 messages and dispatches them without regard for sending a response
629 other than that which POP3 defines for successful delivery of a
630 message.
631 SOAP::Transport::POP3::Server
633 Inherits from: SOAP::Server.
635 The new method of this class creates an object of the Net::POP3 class
637 to use internally for polling a specified POP3 server for incoming
638 messages. When an object of this class is created, it expects an
639 endpoint to be specified with a URI that begins with the characters
640 pop:// and includes user ID and password information as well as the
641 hostname itself.
642 The handle method takes the messages present in the remote mailbox and
644 passes them (one at a time) to the superclass handle method. Each
645 message is deleted after being routed. All messages in the POP3 mailbox
646 are presumed to be SOAP messages.
647 Methods for the Net::POP3 object are detected and properly routed,
649 allowing operations such as $server->ping( ).
650 This means that the endpoint string doesn't need to provide the user ID
652 and password because the login method from the POP3 API may be used
653 directly.
654 SOAP::Transport::TCP
656 The classes provided by this module implement direct TCP/IP
657 communications methods for both clients and servers.
658 The connections don't use HTTP or any other higher-level protocol.
660 These classes are selected when the client or server object being
661 created uses an endpoint URI that starts with tcp://. Both client and
662 server classes support using Secure Socket Layer if it is available. If
663 any of the parameters to a new method from either of the classes begins
664 with SSL_ (such as SSL_server in place of Server), the class attempts
665 to load the IO::Socket::SSL package and use it to create socket
666 objects.
667 Both of the following classes catch methods that are intended for the
669 socket objects and pass them along, allowing calls such as
670 $client->accept( ) without including the socket class in the
671 inheritance tree.
672 SOAP::Transport::TCP::Client
674 Inherits from: SOAP::Client.
676 The TCP client class defines only two relevant methods beyond new and
678 send_receive. These methods are:
679 SSL(optional new boolean value)
681 if ($client->SSL) # Execute only if in SSL mode
682 Reflects the attribute that denotes whether the client object is
684 using SSL sockets for communications.
685 io_socket_class
687 ($client->io_socket_class)->new(%options);
688 Returns the name of the class to use when creating socket objects
690 for internal use in communications. As implemented, it returns one
691 of IO::Socket::INET or IO::Socket::SSL, depending on the return
692 value of the previous SSL method.
693 If an application creates a subclass that inherits from this client
695 class, either method is a likely target for overloading.
696 The new method behaves identically to most other classes, except that
698 it detects the presence of SSL-targeted values in the parameter list
699 and sets the SSL method appropriately if they are present.
700 The send_receive method creates a socket of the appropriate class and
702 connects to the configured endpoint. It then sets the socket to
703 nonblocking I/O, sends the message, shuts down the client end of the
704 connection (preventing further writing), and reads the response back
705 from the server. The socket object is discarded after the response and
706 appropriate status codes are set on the client object.
707 SOAP::Transport::TCP::Server
709 Inherits from: SOAP::Server.
711 The server class also defines the same two additional methods as in the
713 client class:
714 SSL(optional new boolean value)
716 if ($client->SSL) # Execute only if in SSL mode
717 Reflects the attribute that denotes whether the client object is
719 using SSL sockets for communications.
720 io_socket_class
722 ($client->io_socket_class)->new(%options);
723 Returns the name of the class to use when creating socket objects
725 for internal use in communications. As implemented, it returns one
726 of IO::Socket::INET or IO::Socket::SSL, depending on the return
727 value of the previous SSL method. The new method also manages the
728 automatic selection of SSL in the same fashion as the client class
729 does.
730 The handle method in this server implementation isn't designed to
732 be called once with each new request. Rather, it is called with no
733 arguments, at which time it enters into an infinite loop of waiting
734 for a connection, reading the request, routing the request and
735 sending back the serialized response. This continues until the
736 process itself is interrupted by an untrapped signal or similar
737 means.
738
740 Special thanks to O'Reilly publishing which has graciously allowed
741 SOAP::Lite to republish and redistribute large excerpts from
742 Programming Web Services with Perl, mainly the SOAP::Lite reference
743 found in Appendix B.
744
746 Copyright (C) 2000-2004 Paul Kulchenko. All rights reserved.
747 This library is free software; you can redistribute it and/or modify it
749 under the same terms as Perl itself.
750
752 Paul Kulchenko (paulclinger@yahoo.com)
753 Randy J. Ray (rjray@blackperl.com)
755 Byrne Reese (byrne@majordojo.com)
757perl v5.12.3 2010-06-03 SOAP::Transport(3)