First - thank you for SOAP::WSDL - great module - really appreciate it.
We (donor.com) are almost done writing a new CPAN module called POE::Component::Server::SOAP::WSDL - the existing POE::Component::Server::SOAP module is based on SOAP::Lite and we needed to use SOAP::WDL but still wanted to use POE. As part of this, we are also doing a little tool that converts some YAML meta data about a module into a WS-I WSDL. We can then use wsdl2perl to generate the server classes, and give the same wsdl file to the clients. Since we have 500+ APIs we really didn't want to manually wrap them all for SOAP::WSDL, so we adapted SOAP::WSDL::Server.pm to POE::Component::Server::SOAP::WSDL::Server to handle the dispatching and wrapping. The goal of this approach is to allow any API that returns a hash ref to be served up using the following process:
1) Write a simple metadata file about the module to be exposed. For example:
--- #YAML:1.0
module: HelloWorld
methods:
- sayHello:
in:
first_name: string
last_name: string
out:
result_code: integer
result_message: string
greeting: string
- sayGoodBye:
in:
first_name: string
last_name: string
out:
result_code: integer
result_message: string
language_list:
language_code: string
translation: string
name: string
2) Run the new tool meta2wsdl to generate a WS-I document style WSDL file
3) Run the SOAP::WSDL wsdl2perl to generate the server and the generated classes
4) Start up the POE::Component::Server::SOAP::WSDL server, passing in the right configs
At that point you should have a fully functioning WSDL server exposing existing Perl APIs without having to write any custom wrappers. And almost as important, both the clients and the server are using the same WSDL to generate their code.
The only thing we needed in doing all that was a way to map from methods to Element classes (helpful for knowing the right way to serialize the hashref response for the wrapped Perl module using the correct SOAP::WSDL serializer). We poked around the generated code, but we are wondering of the code that generates the $action_map_ref in MyServer::HelloWorld::HelloWorldSOAP.pm :
my $action_map_ref = {
'urn:HelloWorld#sayHello' => 'sayHello',
'urn:HelloWorld#sayGoodBye' => 'sayGoodBye',
};
Could it also generate these two maps as well?
my $request_map_ref = {
'urn:HelloWorld#sayHello' => 'MyElements::sayHelloRequest',
'urn:HelloWorld#sayGoodBye' => 'MyElementssayGoodByeRequest',
};
my $response_map_ref = {
'urn:HelloWorld#sayHello' => 'MyElements::sayHelloResponse',
'urn:HelloWorld#sayGoodBye' => 'MyElements::sayGoodByeResponse',
};
Technically we only need the map to find the response class, but I suppose the request classes might be useful to someone else at some point.
SUMMARY:
1) Is there a better way to map from a method/action back to an Element class that we should be using instead?
2) Could you point us to where we should adjust the code generation of the Server class? Is this even feasible?
3) If we gave you a patch to add those two maps to the generated Server class, would you even want the patch? Not sure how this fits in with your long term goals for SOAP::WSDL.
Thanks again for a great module - you have made it possible to actually serve Perl based APIs to .Net clients for us. Thanks!
Mike.
