I can't comment well enough on the differences in toolkits, but if you application does not need the features of SOAP (and few do), I would definitely consider sticking with XML/RPC.

They say a Camel is a horse designed by commitee. Hah! A camel is an excellent pack animal, has great endurance, and has magical water conservation features. On the other hand, SOAP is no Camel. It's sort of like a duck-billed platypus designed by commitee.

SOAP is a classic case of why Nash equilibrium is something standards groups should understand... everybody can compromise, and that works...but if everyone wants to get what they want, it never works. Think of the pain of writing a SOAP system by hand, without modules. Ugly. Now think of the joy of doing the same in XML-RPC. Simple, easy, and much cleaner.

I've used both RPC::XML and POE::Component::Server::XMLRPC (which sits on top of XMLRPC::Lite, IMSMR). If you're not doing much in each call, or more to the point not doing anything that'd block, the former's probably your best bet (especially if you don't have any experience with POE). It's a bit simpler to get going, and the ability to have a directory of files with seperate handlers for each call can be handy.

I had great success with SOAP::Lite. It was very easy to use and enabled me to concentrate on my real problem. I had a working system in under a day that moved hundreds of thousands of records securely over HTTPS.

SOAP::Lite uses LWP and gets the benefit of secure connections if you have the right modules installed. I used Crypt::SSLea, but I think there is another one as well. They both use OpenSSL.