http://www.perlmonks.org?node_id=673709

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

I'm trying to basically make a proxy for a SOAP service. So from a mod_perl2 + HTML::Mason handler, I want to call a SOAP service and return something to the browser. I haven't decided yet if what's returned will be JSON or XML, but I have the following problem before that anyway.

The only way I see to get the "raw XML" returned from the SOAP service is to set $soap->outputxml, then the SOAP call will return XML instead of a SOM object. That would be fine for the proxy, but.... I'd also like to be able to intervene in case there is a SOAP <Fault> returned. In that case, I'll have to tediously parse the raw XML (instead of using the convenient $som->fault method to check if there was a fault). Finally, the question: is there any way, besides copying and pasting the deserializer code from SOAP::Lite's call method, to cleanly have my cake and eat it too? That is, is there any way to retrieve the raw XML but also have the SOAP call return the normal SOM object?

Replies are listed 'Best First'.
Re: SOAP::Lite web proxy
by jhourcle (Prior) on Mar 12, 2008 at 16:45 UTC

    It's been a while since I played with the serializer / deserializer classes in SOAP::Lite (0.60?), but from what I remember, it was tricky to just copy/paste the code, as there was a mix of both methods and function calls to deal with.

    What I'd probably do in your case is define a custom deserializer that did the following:

    1. accept the serialized xml and store it
    2. pass the xml to the default serializer to get the SOM object.
    3. test for a soap fault and generate whatever (serialized) response to handle in that case.
    4. return either the original message or fault response to the original client. (use a custom serializer that does nothing but pass the string through)

    Now, with this plan, you would need to have SOAP::Lite parse the XML into the SOM object, which may be too much overhead for you. (particularly if you can't process it fast enough to get around your client's timeout -- I run into that problem as I'm federating search systems, so have to combine multiple SOAP responses into a single unified response)