SOAP::WSDL (3)

Leading comments

Automatically generated by Pod::Man 2.28 (Pod::Simple 3.29)

Standard preamble:
========================================================================

(The comments found at the beginning of the groff file "man3/SOAP::WSDL.3pm".)

NAME

SOAP::WSDL - SOAP with WSDL support

NOTICE

This module is not recommended for new application development. Please use XML::Compile::SOAP or SOAP::Lite instead if possible.

This module has a large number of known bugs and is not being actively developed. This 3.0 release is intended to update the module to pass tests on newer Perls. This is a service to existing applications already dependent on this module.

SYNOPSIS

 my $soap = SOAP::WSDL->new(
    wsdl => 'file://bla.wsdl',
 );

 my $result = $soap->call('MyMethod', %data);

DESCRIPTION

For creating Perl classes instrumenting a web service with a definition, read SOAP::WSDL::Manual.

For using an interpreting (thus slow and somewhat troublesome)

based client, which mimics SOAP::Lite's 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

you should read the documentation.

The stuff below is for users of the 1.2x

series. All others, please refer to SOAP::WSDL::Manual

provides easy access to Web Services with descriptions.

The

is parsed and stored in memory.

Your data is serialized according to the rules in the

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 call. The result is either an object tree (with outputtree), a hash reference (with outputhash), plain (with outputxml) or a 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 file and initializes 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, will return an object tree instead of a 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

node at the current XPath location.

Class resolvers are typically generated by using the generate_typemap method of a SOAP::WSDL::Generator subclass.

Example:

structure ( 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 instead of dispatching the call to the service. Handy for testing/debugging.

ACCESS TO SOAP::WSDL's internals

get_client / set_client

Returns the 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 standard allows operation overloading - that is, you may specify operations with more than one message. The client/server than can choose which message to send. This 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

Schema.

readable

Readable has no effect any more. If you need readable debug output, copy the message to your favorite editor and run the source format command. Outputting readable 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 on_action is a no-op, and is just here for compatibility issues.

Differences to SOAP::Lite

readable

readable is a no-op in Actually, the output from SOAP::Lite is hardly readable, either with readable switched on.

If you need readable

messages, I suggest using your favorite editor for displaying and formatting.

Message style/encoding

While SOAP::Lite supports rpc/encoded style/encoding only, currently supports document/literal style/encoding.

autotype / type information

SOAP::Lite defaults to transmitting type information by default, where defaults to leaving it out.

autotype(1) might even be broken in

it's not well-tested, yet.

Output formats

In contrast to SOAP::Lite, 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 body when outputxml is set to true. returns the complete response.

Auto-Dispatching

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, allows one to switch tracing on/of on a per-object base.

This has to be done in the

client used by see get_client for an example and SOAP::WSDL::Client for details.

BUGS AND LIMITATIONS

The bug tracker is at <rt.cpan.org/Dist/Display.html?Queue=SOAP-WSDL>.

This module is in legacy maintenance mode. Only show stopper bugs are being fixed, until/unless someone wishes to resume active development on it. Scott Walters, "scott@slowass.net" has obtained co-mainter from the

admins for the purpose of applying existing fixes people have submit to the tracker, and to apply other fixes as needed to get the module to install and run on newer Perls. Non show-stopper bugs reports without fixes will be added to this list of limitations. Of course, fixes for these and other bugs are welcome. Scott does not get email from rt.cpan.org, so please drop an email to him at "scott@slowass.net" if you open a ticket there.

*

Breaks the idiom "$package->can("SUPER::method")" in your code

If you redefine "UNIVERSAL::can()", and someone tries to do "$package->can("SUPER::method")", it'll look at your packages @ISA, not theirs. This module does precicely that, by way of its dependency on "Class::Std::Fast".

*

$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 aspn.activestate.com/ASPN/Mail/Message/perl5-porters/929746 for details.

*

Apache

SOAP

datatypes are not supported

You can't use

SOAP::WSDL

with Apache

SOAP

datatypes like map.

*

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 occurrences 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

Related projects

*

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

<soap-wsdl.sourceforge.net>

*

SOAP::WSDL

forum at CPAN::Forum

<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

'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

(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.

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.''

Testers provided most valuable (automated) feedback. Thanks a lot.

Numerous people sent me their real-world

files and error reports for testing. Thank you.

Noah Robin contributed lots of documentation fixes, and the mod_perl server, and eventually joined

'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

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

    github.com/scrottie/SOAP-WSDL