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


in reply to Starting on SOAP

I had to use SOAP.. so I started with SOAP::Lite.. a good module but very complex, especially if you have to read the internals.... oo maaan :), they are complex.
In the beginning I tried creating objects (bless {...}) and pass them to SOAP to create the xml-message, but this didn't worked well. Most of the times it created SOAP-xml that wasn't what the other side expected i.e. it was useless.
So my final solution was to use SOAP::Lite like wrapper for the communication and build the XML myself via Template-toolkit. I find the pseudo XPath expressions you can use on the result very useful.

The bad thing about this approach is that you have to read .wsdl and .xsd specs :( arggh..
One more thing to know about .wsdl. What SOAP::Lite does is it parses the .wsdl file and creates a module on the fly with all the methods, but that is. It does not go further to parse .xsd schemas, so you are on your own from there.
Another thing to be aware is if you have to preserve sessions and also use WSDL ->service() method i.e. you want to login with the first request and reuse this on subsequent one. To solve this I modified SOAP::Lite itself. At the end of SOAP::Lite::HTTP::new() add the following code :
 use HTTP::Cookies;
 my $c = HTTP::Cookies->new(ignore_discard => 1);
 $self->cookie_jar( $c);

[download]
In normal SOAP::Lite usage afaik you can override this easier, but if want to use the wsdl functionality, then use this

hth

PS> If you decide to use TT like me to build the SOAP message I will recommend you to read the tutorials on : http://www.w3schools.com for XML Schema.
One thing to know 'S' in SOAP does not mean Simple, really .

Replies are listed 'Best First'.
Re^2: Starting on SOAP
by erroneousBollock (Curate) on Nov 14, 2007 at 04:53 UTC
    In the beginning I tried creating objects (bless {...}) and pass them to SOAP to create the xml-message, but this didn't worked well. Most of the times it created SOAP-xml that wasn't what the other side expected i.e. it was useless.
    So my final solution was to use SOAP::Lite like wrapper for the communication and build the XML myself via Template-toolkit. I find the pseudo XPath expressions you can use on the result very useful.
    SOAP::Lite has absorbed some but not all functionality from SOAP::WSDL.

    If you want to send objects (complexTypes) to a SOAP web-service use SOAP::WSDL. It works. Really.

    Hand-building XML for SOAP (even using templates) is just a waste of time. That's what WSDL is for.

    The only conceivably non-useless scenario I can think of for partially building SOAP messages with templates is the case where the web-service expects Document/Literal (or .NET) encoding, but at the same time allows for recursively defined complexTypes to be passed. That's quite a lot more complicated than what most developers have to deal with.

    Everyone should know that "SOAP Interoperability" is a cosmic-scale joke perpetrated on the industry by hermit-like evil geniuses.

    That being said, it's still much better to use SOAP::WSDL and to override its default behaviour where necessary. If you find you're using set of overrides a lot, create a sub-class of SOAP::WSDL. Simple.

    The bad thing about this approach is that you have to read .wsdl and .xsd specs :( arggh..
    One more thing to know about .wsdl. What SOAP::Lite does is it parses the .wsdl file and creates a module on the fly with all the methods, but that is. It does not go further to parse .xsd schemas, so you are on your own from there.
    If you've gone down this path because SOAP::Lite / SOAP::WSDL don't yet implement the WSDL 'import' construct... that's a little drastic :-)

    You have a few options:

    • Alter the web-service (if you wrote it) to "inline" the XSD schemas.
    • Save the WSDL file and modify it by hand to include the imported XSD schemas inline.
    • Get some off-the-shelf XSL to transform the WSDL such that the XSD schemas are inlined. You could even create a WSDL proxy service to automate the process.
    In summary, stop doing things the hard way. ;)

    -David

[reply]
      when I started the project, SOAP::WSDL wasn't so advanced ;(, but I will definitely will give it another try.
      Seems much promising now.

      I don't have access to the SOAP server.(it is Java based server and they have libs only for Java and .NET).

      Everyone should know that "SOAP Interoperability" is a cosmic-scale joke perpetrated on the industry by hermit-like evil geniuses

      liked that ;)

      Didn't knew that import was not supported, thanx for telling me that..
[reply]
Re^2: Starting on SOAP
by harsha.reddy (Acolyte) on Nov 14, 2007 at 05:01 UTC
    As of now using SOAP::Lite it is difficult to construct complex SOAP data structures.
    My statement holds good when the wsdl schema on the server has lots and lots of complex SOAP datatypes.
    In which case using SOAP::Lite will be laborious.

    PHP works smoother, when the wsdl schema has complex datatypes
    (there is something called as wsdl2php which converts the wsdl schema to equivalent php classes) using which one can avoid manually constructing the SOAP equivalent complex php data structures

    SOAP::Lite can be used if the wsdl schema is simple or not so complex, such a google web services.


    In a global sense, SOAP::Lite is better and fully defined, Also usability wise yes, if the wsdl is simple.
[reply]
      As of now using SOAP::Lite is difficult to construct complex SOAP data structures.
      My statement holds good when there is wsdl schema already defined and if this wsdl schema has lots and lots of complex types, the using SOAP::Lite will be laborious.
      Obviously you've trouble with reading. I'll write smaller sentences: Update: It seems I misunderstood whom you were replying to:

      Use SOAP::WSDL.

      It handles the construction of SOAP::Data heirarchies for you when given (blessed or not) hash-based data-structures.

      -David

[reply]

In Section Seekers of Perl Wisdom