Perl web-service (server) best practices

Question

I'm currently using a modified HTTP::Daemon::Threaded server in combination with SOAP::WSDL and Pod::WSDL to provide web services used by a variety of client types and roles.

---- that's not the question, the following is -----

I'd like to arrive at an optimal solution (as far as is possible) with respect to the following topics:

• Request/Dispatch/Response speed
• Protocol security (proper use of client-authenticated SSLv3/TLS)
• Resource security (security roles/traits on per-resource & per-method bases)
• Declarative specification of types, method signatures, and required security roles & traits.

Questions:

1. I'd like to be using an IO::Select or IO::Async::Loop::IO_Ppoll -based server, but I understand that this is not compatible with in-server client authenticated SSL. Is my understanding correct?

2. I'd like to move away from verifying the client certificate on each request, to something like CA SiteMinder, where I give out a time-limited session cookie after successful client certificate verification, which can be used on subsequent requests to avoid this time penalty (and to lessen server load). Is this going to be as secure? (or even good enough?)

3. Is there some module/framework I can build on to provided Trait and Role -based Authorisation for the exposed object and methods. Pod::WSDL really only deals with types (and not even complex ones). I'd like to use/implement some declarative annotation (or external YAML) -based scheme to handle complex WSDL typing as well as Trait & Role Authorisation. Has anyone done this? (even separately?) Are there any other modules which might be a good starting point?

4. Finally - Am I just crazy for doing this in Perl5 ? ;)

Answer 1

You're crazy for doing this in Perl :-)

Seriously though, more power to you. My question is, presuming you have some reason to reinvent this wheel, is why not consider Python? Perl is alive and well but so much of this kind of thing (low level scripting) is being done in Python now.

Finally, presuming you don't have an actual reason to be doing this (aside from fun), you should really consider a Web Framework (Django of course) and something like nginx to handle the HTTP interaction.

Answer 2

Ok, everyone's answering everything but the real questions.

I'll break this out into specific questions in separate posts, and won't make any mention at all of the server make-up - a topic which everyone in this thread seems to want to discuss, and which is completely irrelevant.