in reply to Re^2: SOAP::Lite, .NET, and complex structures
in thread SOAP::Lite, .NET, and complex structures

Ok, I didn't understand it that way from your description.

The .NET client is likely doing all the right things wrt SOAP, so let's look at the perl web-service (assuming you used the standard tools to generate your proxy class).

Firstly, are you publishing WSDL for your service? If so, how did you construct it?
If your WSDL is not exactly correct, you'll get all sorts of namespace/type/arity issues.

I use Pod::WSDL to generate WSDL from my web-service classes. It requires you to add some POD to each method and class because perl doesn't handle types/arity statically. In practice, this just makes your class better documented.

WSDL descriptions of each method can generally be a little loose because perl (and SOAP::Lite) doesn't really molest the data too much before passing to the method... however, it's really important to properly describe (annotate) your classes (complex types).

I actually have my web-services serve up the WSDL at http://server/path/to/service?WSDL

Microsoft's wsdl.exe proxy class generator tool should have no problem consuming WSDL generated by Pod::WSDL.

-David

Replies are listed 'Best First'.
Re^4: SOAP::Lite, .NET, and complex structures
by MidLifeXis (Monsignor) on Aug 15, 2007 at 15:26 UTC

    Do you have an example of returning a complex structure to the client? I see the examples of returning complex error types, can get arrays of internal types to return with no problem, but cannot, for the life of me, figure out how to get a complex type returned.

    I will be digging into the source, but if there is an example of this somewhere, it would be most helpful.

    thanks,

    --MidLifeXis

      The steps I use are as follows:
      1. Publish the proper WSDL (generate with Pod::WSDL) after having annotated your (dispatchable) classes with POD as described for classes in Pod::WSDL's documentation.
      2. Please check that the generated WSDL actually contains nice-looking descriptions of your classes (properly marked as complex types).
      3. Don't try to "construct" your complex types. Use normal hash-based perl objects. Return them (or arrays of them) directly.

      I'll try to find the time to put up a working example soon.

      Update:

      Example of annotated class:

      Example (excerpt) of complexType generated by Pod::WSDL:

      Example of method returning a list of complex values:

      Example (excerpts) of WSDL generated by Pod::WSDL for above method:

      That all works fine for me.

      Are you doing anything terribly more complicated than that?

      -David.

        Nope, that is pretty much it.

        One thing I did find, however, is a size issue of some sort or another. For example, this list with 9 elements is parsed correctly by the .Net WebServices Studio tool.

        But the same response with an array size of 10 returns a There is invalid data at the root level. Line 1, position 1. error from that tool. Here is the data that is returned (retrieved by sending a request by hand to the service via telnet)

        Whatever the cause, It is a little bit frustrating, to say the least :)

        I am almost to the point of tossing the .NET WebService Studio tool, except that it works with our existing production server. I will update shortly to see if a different version of Apache (the current production setup) causes this to behave.

        Update: Happens in the production version of apache as well (1.3), so it does not look like it is related to Apache. In production, the break point is going from 6 to 7 items in the array.

        Update 2: Oh yeah. I forgot to say, replace all of the localhost:80 stuff with the local server name. It gets replaced on the server side automatically.

        grrrr

        --MidLifeXis