Fima said:
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:
ata 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
objects!
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
.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.