NAME¶
SOAP::WSDL - SOAP with WSDL support
Overview¶
For creating Perl classes instrumenting a web service with a WSDL definition,
read SOAP::WSDL::Manual.
For using an interpreting (thus slow and somewhat troublesome) WSDL based SOAP
client, which mimics SOAP::Lite's API, read on.
Creating Interface classes is the recommended usage.
Did I say you should create interface classes following the steps in
SOAP::WSDL::Manual?
If you're migrating from earlier versions of SOAP::WSDL, you should read the
MIGRATING documentation.
The stuff below is for users of the 1.2x SOAP::WSDL series. All others, please
refer to SOAP::WSDL::Manual
SYNOPSIS¶
my $soap = SOAP::WSDL->new(
wsdl => 'file://bla.wsdl',
);
my $result = $soap->call('MyMethod', %data);
DESCRIPTION¶
SOAP::WSDL provides easy access to Web Services with 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 passed are passed to the corresponding methods.
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::SOM
object (with neither of the above set).
call() can be called in different ways:
- •
- 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. $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.
Is called automatically from
call() if not called directly before.
servicename
portname
call
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 name for deserializing a 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:
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.
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 it's 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¶
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 than 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
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.
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.
In contrast to SOAP::Lite, SOAP::WSDL supports the following output formats:
- •
- SOAP::SOM objects.
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
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 to switch
tracing on/of on a per-object base.
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¶
- •
- $obj == undef does not work in perl 5.8.6 and perl 5.8.7
Due to some strange behaviour in perl 5.8.6 and perl 5.8.7, stringification
overloading is not triggered during comparison with undef.
While this is probably harmless in most cases, it's important to know that
you need to do
defined( $obj->get_value() )
to check for undef values in simpleType objects.
- •
- perl 5.8.0 or higher required
SOAP::WSDL needs perl 5.8.0 or higher. This is due to a bug in perls before
- see http://aspn.activestate.com/ASPN/Mail/Message/perl5-porters/929746
for details.
- •
- Apache SOAP datatypes are not supported
You currently can't use SOAP::WSDL with Apache SOAP datatypes like map.
If you want this changed, email me a copy of the specs, please.
- •
- Incomplete XML Schema definitions support
This section describes the limitations of SOAP::WSDL, that is the
interpreting SOAP client. For limitations of wsdl2perl generated SOAP
clients, see SOAP::WSDL::Manual::XSD.
XML Schema attribute definitions are not supported in interpreting mode.
The following XML Schema definitions varieties are not supported in
interpreting mod:
group
simpleContent
The following 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 with multiple occurences allowed, SOAP::WSDL has
no means of finding out which variant you meant.
Passing in item => [1,2,3] could serialize to
<item>1 2</item><item>3</item>
<item>1</item><item>2 3</item>
Ambiguous data can be avoided by providing data as objects.
- •
- XML Schema facets
Almost no XML schema facets are implemented. The only facets currently
implemented are:
fixed
default
The following facets have no influence:
minLength
maxLength
minInclusive
maxInclusive
minExclusive
maxExclusive
pattern
enumeration
SEE ALSO¶
- •
- SOAP::Lite
Full featured SOAP-library, little WSDL support. Supports rpc-encoded style
only. Many protocols supported.
- •
- XML::Compile::SOAP
Creates parser/generator functions for SOAP messages. Includes SOAP Client
and Server implementations. Can validate XML messages.
You might want to give it a try, especially if you need to adhere very
closely to the XML Schema / WSDL specs.
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¶
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.
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¶
Martin Kutter <martin.kutter fen-net.de>
$Rev: 851 $
$LastChangedBy: kutterma $
$Id: WSDL.pm 851 2009-05-15 22:45:18Z kutterma $
$HeadURL: https://soap-wsdl.svn.sourceforge.net/svnroot/soap-wsdl/SOAP-WSDL/trunk/lib/SOAP/WSDL.pm $