SOAP::WSDL(3pm)
β¨ NAME β¨
SOAP::WSDL β SOAP with WSDL support π
(yeah bestie, this is the SOAP::WSDL(3pm) page from the User Contributed Perl Documentation, and we're gonna get through it together π«Ά)
π¨ NOTICE π¨
okay so, real talk first: this module is NOT recommended for new application development. Please useXML::Compile::SOAPorSOAP::Liteinstead if you possibly can. π
This module has a large number of known bugs and is not being actively developed. The 3.0 release is just here to update the module so it passes tests on newer Perls. It's a service to existing applications that are already dependent on this module β that's it, that's the whole reason. No new glow-ups. π
πΈ SYNOPSIS πΈ
my $soap = SOAP::WSDL->new(
wsdl => 'file://bla.wsdl',
);
my $result = $soap->call('MyMethod', %data);
look at that. three lines and you're SOAPing. iconic. β¨
π¦ DESCRIPTION π¦
If you want to create Perl classes that instrument a web service using a WSDL definition, go read SOAP::WSDL::Manual instead, bestie. That's the good path.
If you want to use an interpreting WSDL-based SOAP client β which is, quoting the source, thus slow and somewhat troublesome β and which mimics SOAP::Lite's API... keep reading. π
Creating Interface classes is the recommended usage. π
Did I say you should create interface classes following the steps in SOAP::WSDL::Manual? Because you should. Consider this your reminder. π
If you're migrating from earlier versions of SOAP::WSDL, you should read the MIGRATING documentation.
Everything below is for users of the 1.2x SOAP::WSDL series. All others, please refer to SOAP::WSDL::Manual.
So what does this thing even do? SOAP::WSDL provides easy access to Web Services that have WSDL descriptions.
- The WSDL is parsed and stored in memory. π§
- Your data is serialized according to the rules in the WSDL. β¨
- The only transport mechanisms currently supported are http and https. π₯
π METHODS π
π new
Constructor. All parameters you pass in get passed to the corresponding methods. That's it. Slay.
π call
Performs a SOAP call. The result is either:
- an object tree (with
outputtree), - a hash reference (with
outputhash), - plain XML (with
outputxml), - or a
SOAP::SOMobject (with neither of the above set).
call() can be called in different ways, so pick your fighter:
- Old-style idiom
my $result = $soap->call('method', %data);
Does not support SOAP header data. π
- New-style idiom
my $result = $soap->call('method', $body_ref, $header_ref );
Does support SOAP header data. Both $body_ref and $header_ref may either be hash refs or SOAP::WSDL::XSD::Typelib::* derived objects.
Result headers are accessible via the result SOAP::SOM object.
If outputtree or outputhash are set, you may also use the following to access response header data:
my ($body, $header) = $soap->call('method', $body_ref, $header_ref );
π wsdlinit
Reads the WSDL file and initializes SOAP::WSDL for working with it.
It's called automatically from call() if you didn't call it directly beforehand. convenient fr fr β¨
servicenameportnamecall
You may set servicename and portname by passing them as attributes to wsdlinit:
$soap->wsdlinit(
servicename => 'MyService',
portname => 'MyPort',
);
β¨ CONFIGURATION METHODS β¨
π outputtree
When outputtree is set, SOAP::WSDL will return an object tree instead of a SOAP::SOM object.
You have to specify a class_resolver for this to work. See class_resolver. π
π class_resolver
Set the class resolver class (or object).
Class resolvers must implement the method get_class, which has to return the name of the class for deserializing an XML node at the current XPath location.
Class resolvers are typically generated by using the generate_typemap method of a SOAP::WSDL::Generator subclass.
Example time, bestie:
XML structure (SOAP body content):
<Person>
<Name>Smith</Name>
<FirstName>John</FirstName>
</Person>
Class resolver:
package MyResolver;
my %typemap = (
'Person' => 'MyPersonClass',
'Person/Name' => 'SOAP::WSDL::XSD::Typelib::Builtin::string',
'Person/FirstName' => 'SOAP::WSDL::XSD::Typelib::Builtin::string',
);
sub get_class { return $typemap{ $_[1] } };
1;
You'll need a MyPersonClass module in your search path for this to work β see SOAP::WSDL::XSD::ComplexType on how to build / generate one. π
π servicename
$soap->servicename('Name');
Sets the service to operate on. If no service is set via servicename, the first service found is used.
Returns the soap object, so you can chain calls like:
$soap->servicename->('Name')->portname('Port');
π portname
$soap->portname('Name');
Sets the port to operate on. If no port is set via portname, the first port found is used.
Returns the soap object, so you can chain calls like:
$soap->portname('Port')->call('MyMethod', %data);
π no_dispatch
When set, call() returns the plain request XML instead of dispatching the SOAP call to the SOAP service. Handy for testing/debugging. π§ͺ
π ACCESS TO SOAP::WSDL's internals π
π§ get_client / set_client
Returns the SOAP client implementation used (normally a SOAP::WSDL::Client object).
π EXAMPLES π
See the examples/ directory. go look, it's right there π
π Differences to previous versions π
- WSDL handling
SOAP::WSDL 2 is a complete rewrite. While SOAP::WSDL 1.x attempted to process the WSDL file on the fly by using XPath queries, SOAP::WSDL 2 uses a Expat handler for parsing the WSDL and building up a object tree representing its content.
The object tree has two main functions: It knows how to serialize data passed as hash ref, and how to render the WSDL elements found into perl classes.
Yup you're right; there's a builtin code generation facility. Read SOAP::WSDL::Manual for using it. π
- no_dispatch
call() with no_dispatch set to true now returns the complete SOAP request envelope, not only the body's content.
- outputxml
call() with outputxml set to true now returns the complete SOAP response envelope, not only the body's content.
- servicename/portname
Both servicename and portname can only be called after calling wsdlinit().
You may pass the servicename and portname as attributes to wsdlinit, though.
π Differences to previous versions π
(yeah, same heading twice, they said what they said π« )
The following functionality is no longer supported:
β οΈ Operation overloading
The SOAP standard allows operation overloading β that is, you may specify SOAP operations with more than one message. The client/server then can choose which message to send. This SOAP feature is usually used similar to the use of methods with different argument lists in C++.
Operation overloading is no longer supported. The WS-I Basic profile does not [allow] operation overloading. The same functionality as operation overloading can be obtained by using a choice declaration in the XML Schema.
β οΈ readable
readable has no effect any more. If you need readable debug output, copy the SOAP message to your favorite XML editor and run the source format command. Outputting readable XML requires lots of programming for little use: the resulting XML is still quite unreadable. π
β οΈ on_action
Setting on_action is not required any more β the appropriate value is automatically taken from the WSDL. on_action is a no-op, and is just here for compatibility issues.
π Differences to SOAP::Lite π
π« readable
readable is a no-op in SOAP::WSDL. Actually, the XML output from SOAP::Lite is hardly readable, either with readable switched on.
If you need readable XML messages, I suggest using your favorite XML editor for displaying and formatting. π
π« Message style/encoding
While SOAP::Lite supports rpc/encoded style/encoding only, SOAP::WSDL currently supports document/literal style/encoding.
π« autotype / type information
SOAP::Lite defaults to transmitting XML type information by default, where SOAP::WSDL defaults to leaving it out.
autotype(1) might even be broken in SOAP::WSDL β it's not well-tested, yet. β οΈ
π« Output formats
In contrast to SOAP::Lite, SOAP::WSDL supports the following output formats:
SOAP::SOMobjects.
This is the default. SOAP::Lite is required for outputting SOAP::SOM objects.
- Object trees.
This is the recommended output format. You need a class resolver (typemap) for outputting object trees. See class_resolver above. π
- Hash refs
This is for convenience: A single hash ref containing the content of the SOAP body.
- xml
See below. π
π« outputxml
SOAP::Lite returns only the content of the SOAP body when outputxml is set to true. SOAP::WSDL returns the complete XML response.
π« Auto-Dispatching
SOAP::WSDL does not support auto-dispatching.
This is on purpose: You may easily create interface classes by using SOAP::WSDL::Client and implementing something like
sub mySoapMethod {
my $self = shift;
$soap_wsdl_client->call( mySoapMethod, @_);
}
You may even do this in a class factory β see wsdl2perl for creating such interfaces. β¨
π« Debugging / Tracing
While SOAP::Lite features a global tracing facility, SOAP::WSDL allows one to switch tracing on/off on a per-object basis.
This has to be done in the SOAP client used by SOAP::WSDL β see get_client for an example and SOAP::WSDL::Client for details.
π BUGS AND LIMITATIONS π
okay bestie, sit down, we gotta talk β¨ The bug tracker lives at <https://rt.cpan.org/Dist/Display.html?Queue=SOAP-WSDL> β that's where the ~lore~ gets recorded.
Real talk: this module is in legacy maintenance mode. That means only show stopper bugs are getting fixed, and that's the situation until/unless someone is like "actually I wanna do active development on this again." Scott Walters, scott@slowass.net, got co-maintainer status from the CPAN admins specifically so he could apply the fixes people have already submitted to the RT tracker, and apply other fixes as needed to get the module to install and run on newer Perls. That's the whole mission. π«‘
So here's the vibe: non show-stopper bug reports that don't come with fixes just get added to this very list of limitations. Not me being shady β that's just the deal. And of course, fixes for these and other bugs are always welcome, literally everyone would be obsessed. π
Heads up: Scott does not get email fromrt.cpan.org, so if you open a ticket there, please also drop him an email atscott@slowass.net. Otherwise he will simply never see it. π
Here are the known limitations, no cap:
- Breaks the idiom
$package->can("SUPER::method")in your code
If you redefine UNIVERSAL::can(), and somebody tries to do $package->can("SUPER::method"), it's gonna look at your package's @ISA, not theirs. And this module does precisely that, because of its dependency on Class::Std::Fast. π
$obj == undefdoes not work in perl 5.8.6 and perl 5.8.7
There's some strange behaviour in perl 5.8.6 and perl 5.8.7 where stringification overloading just does not get triggered during a comparison with undef. Probably harmless in most cases, ngl, but you need to know that the move is:
defined( $obj->get_value() )
That's how you check for undef values in simpleType objects. π
- perl 5.8.0 or higher required
SOAP::WSDL needs perl 5.8.0 or higher, and the reason is a bug in perls before that. See <http://aspn.activestate.com/ASPN/Mail/Message/perl5-porters/929746> for the receipts. π§Ύ
- Apache SOAP datatypes are not supported
You can't use SOAP::WSDL with Apache SOAP datatypes like map. Sorry bestie, it's a no. π
- Incomplete XML Schema definitions support
This section is about the limitations of SOAP::WSDL β that's the interpreting SOAP client, okay? For the limitations of wsdl2perl-generated SOAP clients, go read SOAP::WSDL::Manual::XSD. π
XML Schema attribute definitions are not supported in interpreting mode.
These XML Schema definition varieties are not supported in interpreting mode:
group
simpleContent
And this XML Schema definition content model is only partially supported in interpreting mode:
complexContent - only restriction variety supported
See SOAP::WSDL::Manual::XSD for details. β
- Serialization of hash refs does not work for ambiguous values
If you have list elements where multiple occurrences are allowed, SOAP::WSDL has no means of figuring out which variant you meant. Like, none. π
So passing in item => [1,2,3] could serialize to:
<item>1 2</item><item>3</item>
<item>1</item><item>2 3</item>
You can dodge the ambiguous data entirely by providing your data as objects. π
- XML Schema facets
Almost no XML schema facets are implemented. The only facets currently implemented are:
fixed
default
And these facets have no influence whatsoever, they're just vibing in the background:
minLength
maxLength
minInclusive
maxInclusive
minExclusive
maxExclusive
pattern
enumeration
π SEE ALSO π
Related projects π¦
- SOAP::Lite
Full featured SOAP-library, with little WSDL support. Supports rpc-encoded style only. Many protocols supported. It's giving "extremely capable, slightly chaotic." β¨
- XML::Compile::SOAP
Creates parser/generator functions for SOAP messages. Includes SOAP Client and Server implementations. Can validate XML messages. π
You might wanna give it a try β especially if you need to adhere very closely to the XML Schema / WSDL specs. That's its whole main character thing.
Sources of documentation π
- SOAP::WSDL homepage at sourceforge.net
<http://soap-wsdl.sourceforge.net>
- SOAP::WSDL forum at CPAN::Forum
<http://www.cpanforum.com/dist/SOAP-WSDL>
π«Ά ACKNOWLEDGMENTS π
Scott Walters wrote:
This code incorporates fixes contributed by NORDIC@cpan.org, dam@cpan.org, sven.schober@uni-ulm.de, myself, and others.
Martin Kutter wrote:
There are many people out there who fostered SOAP::WSDL's development. I would like to thank them all (and apologize to all those I have forgotten). π
Giovanni S. Fois wrote a improved version of SOAP::WSDL (which eventually became v1.23).
David Bussenschutt, Damian A. Martinez Gelabert, Dennis S. Hennen, Dan Horne, Peter Orvos, Mark Overmeer, Jon Robens, Isidro Vila Verde and Glenn Wood (in alphabetical order) spotted bugs and/or suggested improvements in the 1.2x releases.
JT Justman and Noah Robin provided early feedback and bug reports for the 2.xx pre-releases.
Adam Kennedy checked and suggested improvements on metadata and dependencies in the 2.xx pre-releases.
Andreas 'ac0v' Specht constantly asked for better performance. (constantly. respect. π₯)
Matt S. Trout encouraged me "to get a non-dev-release out."
CPAN Testers provided most valuable (automated) feedback. Thanks a lot.
Numerous people sent me their real-world WSDL files and error reports for testing. Thank you. πΈ
Noah Robin contributed lots of documentation fixes, and the mod_perl server, and eventually joined SOAP::WSDL's development. Thanks.
Mark Overmeer wrote XML::Compile::SOAP - competition is good for business. π
Paul Kulchenko and Byrne Reese wrote and maintained SOAP::Lite and thus provided a base (and counterpart) for SOAP::WSDL.
π LICENSE AND COPYRIGHT π
Copyright 2004-2008 Martin Kutter.
This file is part of SOAP-WSDL. You may distribute/modify it under the same terms as perl itself.
βοΈ AUTHOR π
Scott Walters <scott@slowass.net<gt> 2014
Martin Kutter <martin.kutter fen-net.de> 2004-2008
ποΈ REPOSITORY INFORMATION β
https://github.com/scrottie/SOAP-WSDL
and that's a wrap bestie!! ππ this page was rendered with perl v5.36.0 and it's dated 2022-10-14, and yep, it's SOAP::WSDL(3pm) β the one and only. go forth and parse some WSDL, you absolute icon. πβ¨π¦
π¦ where this page comes from
- ubuntu noble: libsoap-wsdl-perl 3.004-2 Β· Artistic-1.0-Perl OR GPL-1.0-or-later
- ubuntu resolute: libsoap-wsdl-perl 3.004-2 Β· Artistic-1.0-Perl OR GPL-1.0-or-later
- ubuntu stonking: libsoap-wsdl-perl 3.004-2 Β· Artistic-1.0-Perl OR GPL-1.0-or-later
- π girlified by deepseek-ai/DeepSeek-V4.1-Flash on : a language model's rewrite of the original, under its terms