Re: document/literal style SOAP:Lite service

Fima Furman wrote:
Folks, this seems like a pretty basic question, but I couldn't find a
direct answer, only hints in documentation and other people's article.
Can Soap:Lite implement a service which would work with Document/
literal requests? In my testing I was only able to get it to work with
rpc/encoded style. I would very much appreciate if someone could shed
some light on this.

SOAP::Lite really only supports RPC/Encoded. The SOAP::Lite documentation mentions partial support for Doc/Literal but I believe this never advanced beyond some rudimentary and partial support.

If Soap:lite is incompatible with document/literal, are there
alternatives out there which would allow to implement document/literal
SOAP service in Pearl? I've asked the same question in Soap:Lite yahoo
group and total silence was my answer.

AFAIK There are no alternative modules that do what you want.

I'd love to hear if I am wrong about either of the above!

The good news is that the following process works beautifully:

* Create a SOAP::Lite service in the usual way.

* If you receive or send complex data structures,
Use Perl objects
Return references to arrays instead of arrays
Do not use perl data structures like HoH
Do not use SOAP::Data to construct params or return values.

* Mark up your Perl objects following the instructions
in the POD::WSDL documentation

* Use POD::WSDL to create WSDL for the service

* Use that WSDL to create stubs in technologies that
normally only like Doc/Literal
e.g. C# .NET
I downloaded mono and used it's wsdl.exe to create a
C# stub from the WSDL created by POD::WSDL

* Use those stubs in the normal way.
I could write normal C# code, constructing C# objects and passing
them as params to Perl SOAP::Lite services via methods of a stub
service object. Perl objects emerge as C# objects and vice-versa.

* The receiving Perl service receives full Perl objects
and you can invoke instance methods using those

I have done this with moderately complex parameters such as an array of objects where each object contains various fields and an array of another type of object.

Note that the C# programmer does not have to even know about the distinction between RPC/Encoded and Doc/Literal. Everything just works.

I haven't tried this with Perl's inside-out objects, just the original
traditional hash based objects. The C# classes created in the stub for the parameter and return objects obviously lack methods and accessors,
you just refer to public variables (fields) using object.field notation

Perl service

my @things;
my $thing = new Thing(1,99.9,"aha");
$thing->addWhatsit("foo", 23.3); # inner array of Whatsit objects
$thing->addWhatist("bar", 23.3);
push @things $thing;
$thing = new Thing(2,34.2,"oho");
return \@things;

C# client

// stub gen from WSDL defines ThingService, Thing and Whatsit.
ThingService service = new ThingService();
Thing[] things = service.method(params);
for (int i = 0; i < things.Length; i++) {
Whatsit[] whatsits = things[i].whatsits;
for (int j = 0; j < whatsits.Length; j++) {
Console.WriteLine("This Things contains a Whatsit with name "
+ whatsits[j].name);

No hint of RPC/Encoded or Doc/Literal anywhere in the code you have to write.