|
|
SOAP::Transport::HTTP::CGI - Generic SOAP CGI handler
Use this class to expose SOAP endpoints using vanilla CGI. Here's an example SOAP endpoint exposed using this class:
package ServerDemo;
use strict;
use SOAP::Transport::HTTP::CGI;
sub handler {
my $safe_classes = {
Calculator => undef,
};
SOAP::Transport::HTTP::CGI->handler($safe_classes);
}
1;
(I leave it up to you to figure out how to get Perl scripts to run as CGI scripts - please see your Perl docs for details)
This class encapsulates the details of hooking up to CGI, and then calls SOAP::Transport::HTTP::Server to do the SOAP-specific stuff. This way the Server class can be reused with any web server configuration (including mod_perl), by simply composing it with a different front-end (for instance, SOAP::Transport::HTTP::Apache, for instance.
This is the only method on the class, and you must pass a hash reference whose keys contain the collection of classes that may be invoked at this endpoint. If you specify class FooBar in this list, for instance, and a client sends a SOAP request to http://yourserver/soap?class=FooBar, then the SOAP::Transport::HTTP::Server class will eventually attempt to load FooBar.pm, instatiate a FooBar, and call its handle_request function (see SOAP::Transport::HTTP::Server for more detail). If you don't include a class in this hash, SOAP/Perl won't run it. I promise.
By the way, only the keys in this hash are important, the values are ignored.
Also, nothing is stopping you from messing around with the response
yourself if you'd like to add some headers or whatever;
you can always call print() dump more headers to STDOUT.
Just make sure you finish what you're doing before you
return to SOAP::Transport::HTTP::Server, because at that
point the response is marshaled and sent back.
See SOAP::Transport::HTTP::Server for details on the OptionalDispatcher parameter.
SOAP::Transport::HTTP::Server
Keith Brown