ethrbunny has asked for the wisdom of the Perl Monks concerning the following question:

Is there someway that I could use the threading and logging functions in http::daemon::threaded for a SOAP style server? I have the basic perl-style soap server running ok but it doesn't lend itself well to session vars or any of the proper memory management that I need to implement.

I'm trying not to reimplement the proverbial wheel here and I'm also desperately trying to avoid installing Apache.

Suggestions are appreciated.

Replies are listed 'Best First'.
Re: http::daemon::threaded - soap?
by renodino (Curate) on Aug 03, 2007 at 15:21 UTC
    Sorry, I haven't thought that far ahead (yet). I'm still working on improvements to the apartment threading infrastructure (esp. performance).

    However, once a connection is established, H::D::T::WebClient just forwards stuff to a H::D::T::Content handler based on a regex, so if you can collect the Content-Type for your SOAP, then write a content handler module to accept/process the SOAP request and generate the XML responses, you should be on your way. (I don't know how any of the Perl SOAP modules will play with that environment)

    Also keep in mind that H::D::T is still very young, and the current CPAN version is functionally limited (No SSL, primitive session support, etc.)

    update: fixed minor typo

    Perl Contrarian & SQL fanboy
[reply]
      What Im mostly concerned about is restricting access to the functions. When I implemented this scheme in Axis2 I did a "create a nonce, have both sides encrypt it with a known key and compare. If they're equal then permit access to the functions." The problem Im trying to solve is how to know when a new connection is made so I can create a new nonce - and similarly to know when the existing connection has been properly 'authenticated' or not.

      Its all 'session' management. If I can get cookies working I can probably get something going.
[reply]
        Alas, H::D::T's session mgmt is largely non-existant (tho I'm working on more robust support for another project). It does capture cookies, but you'll have to implement your own H::D::T::Session and SessionCache objects. You may find the classdocs more helpful than the CPAN POD to guide you. But I definitely need to put together a tutorial.

        You also mentioned "memory management issues" in the OP. Care to elaborate ?

        Perl Contrarian & SQL fanboy
[reply]
Re: http::daemon::threaded - soap?
by scorpio17 (Canon) on Aug 03, 2007 at 17:38 UTC

    Are you trying to avoid installing any web server, or just Apache?

    You might consider lighttpd.

    It's much more light-weight than Apache - and may do all you need.

[reply]
      Im trying to install as little as possible. This 'package' will go on 3-500 client machines. The less I need to install and maintain the easier my job will be.

      Im hoping that by creating a standalone SOAP daemon that I can then focus on the classes that run 'behind' it instead of worrying about keeping up the infrastructure around it.

      I will be the only person communicating with this daemon (through a series of perl scripts hosted on local servers) so it doesn't need to be able to juggle dozens of simultaneous clients nor does it need to be super-flexible w/re its configuration.

      It does need to be as secure as I can make it as I will be transporting HIPAA protected information through it.
[reply]
        Don't know anything about threaded, but you could just make a plain old forking server based on HTTP::Daemon. You can then restrict access by checking the peer address, as H:D is an instance of IO::Socket::INET.

        You could create a session id (url?id=12345) and append it to URLs. Reject requests without the ID.

        You can generate cookies from one of the CGI packages. Just stick them in the HTTP::Response and send it. Pull them out of the headers.

[reply]

Back to Seekers of Perl Wisdom