2: They don't. There is NO standard for serving WSDL in relation to the web service.. Some services will return it if they get a QUERY_STRING of wsdl. So for instance, if your access URL is http://server/path, someone might ask for http://server/path?wsdl. WSDL discovery is supposed to be handled through UDDI, but that's just adding a whole 'nother level of complexity to things. As for SOAP::Lite generating WSDL -- it doesn't. It can use it for connecting as a client, but it can't do anything with them as a server. There's SOAP::WSDL, which is supposed to make sure that your return message is properly serialized (as you have to bless your elements with the names that were used for complex types in the WSDL, so that strictly typed languages like Java don't choke on SOAP::Lite's RPC/encoded messages.)

1: I have no idea. I don't run it as a Daemon -- but you can connect to the port w/ telnet, and make sure it's still returning responses, which should give you a clue if it's a problem.

But anyway, a bit of advice on the WSDL side of things -- write the WSDL first, then the service to match the WSDL. The WSDL doesn't have to describe everything, just the best case incoming scenario, and any responses that might be returned from that case. It's much easier than trying to write a WSDL to describe all of the existing quirks in your service. I think getting all of the quirks out of <a href="http://vso1.nascom.nasa.gov/API/sdacVSOi_strict.wsdl">our WSDL</a> took more than a month, and we replaced the serializer to straighten up some of the formatting.

As far as I understand your concurrent I can provide the following answer.

I do it this way: I have a single daemon but I use threads to process the request. Hence, the daemon is more or less immideately back for other clients.