Excellent, so you have a working HTTPS server. (You can put it on whatever port you wish... 443 is just a convention.)
Now, you don't want to be changing SOAP or SOAP::Lite for deployment, so the trick is to invert control; instead of SOAP::Lite calling HTTP::Daemon, you create a one-shot HTTP::Request handler around SOAP::Lite, and have that handle the request passed to it by HTTP::Daemon::SSL.
So inside your pre-existing HTTP::Daemon::SSL loop...
(where you'd normally parse the HTTP request and construct some HTTP response)
... firstly, construct an HTTP::Request object:
# I usually molest $raw_request_string a little here...
my $request = HTTP::Request->parse($raw_request_string);
create a one-off soap handler:
my $soap = SOAP::Transport::HTTP::Server
-> new(YOUR_SOAP_SPECIFIC_ARGS)
-> dispatch_to(YOUR_CLASS);
then feed the request object to the soap handler: # and I usually munge headers/SOAPaction here...
$soap->request($request);
dispatch the request to your class via SOAP::Lite: $soap->handle();
finally, pull out the response it built:
my $response = $soap->response;
As I implied earlier in this thread, doing it this way gives you more control over the HTTP request life-cycle... which means you can serve more than just SOAP rpc's from the service.
As an example, you can inspect the request (say before constructing the HTTP::Request object) and determine (based on the URI) whether you want to respond as SOAP rpc, respond with WSDL describing the service, or even respond with HTML explaining how to use the service.
(In my webservice framework I do all those, plus JSONRPC and some dynamic web content.)
-David
|