Provided by: libsoap-wsdl-perl_3.003-1_all bug

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

       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.

   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::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 one 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

       The bug tracker is at <https://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 CPAN admins for the purpose of
       applying existing fixes people have submit to the RT 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
           http://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 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

   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

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

       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