The London Perl and Raku Workshop takes place on 26th Oct 2024. If your company depends on Perl, please consider sponsoring and/or attending.
 / 
SOAP-WSDL-1.17
River stage one • 7 direct dependents • 7 total dependents
1 ++
/ SOAP::WSDL

NAME

SOAP::WSDL

SYNOPSIS

 use SOAP::WSDL;
 
 my $soap=SOAP::WSDL->new( wsdl => 'http://server.com/ws.wsdl' )
    ->proxy( 'http://myurl.com');
    
 $soap->wsdlinit;
   
 my $som=$soap->call( 'method' => [ 
                  { name => value },
                  { name => 'value' } ]);

DESCRIPTION

SOAP::WSDL provides decent WSDL support for SOAP::Lite. It is built as a add-on to SOAP::Lite, and will sit on top of it, forwarding all the actual request-response to SOAP::Lite - somewhat like a pre-processor.

WSDL support means that you don't have to deal with those bitchy namespaces some web services set on each and every method call parameter.

It also means an end to that nasty

 SOAP::Data->name( 'Name' )->value(
    SOAP::Data->name( 'Sub-Name')->value( 'Subvalue' )
 );

encoding of complex data. (Another solution for this problem is just iterating recursively over your data. But that doesn't work if you need more information [e.g. namespaces etc] than just your data to encode your parameters).

And it means that you can use ordinary hashes for your parameters - the encording order will be derived from the WSDL and not from your (unordered) data, thus the problem of unordered perl-hashes and WSDL >sequence< definitions is solved, too. (Another solution for the ordering problem is tying your hash to a class that provides ordered hashes - Tie::IxHash is one of them).

Why should I use this ?

SOAP::WSDL eases life for webservice developers who have to communicate with lots of different web services using a reasonable big number of method calls.

If you just want to call a hand full of methods of one web service, take SOAP::Lite's stubmaker and modify the stuff by hand if it doesn't work right from the start. The overhead SOAP::WSDL imposes on your calls is not worth the time saving.

If you need to access many web services offering zillions of methods to you, this module should be your choice. It automatically encodes your perl data structures correctly, based on the service's WSDL description, handling even those complex types SOAP::Lite can't cope with.

SOAP::WSDL also eliminates most perl <-> .NET interoperability problems by qualifying method and parameters as they are specified in the WSDL definition.

USAGE

 my $soap=SOAP::WSDL->new( wsdl => 'http://server.com/ws.wsdl' );

 # or
 my $soap=SOAP::WSDL->new()
 $soap->wsdl('http://server.com/ws.wsdl');

 # or 
 # without dispatching calls to the WebService
 #
 # useful for testing
 my $soap=SOAP::WSDL->new( wsdl => 'http://server.com/ws.wsdl',
                no_dispatch => 1 );
 
 # you must call proxy before you call wsdlinit
 $soap->proxy( 'http://myurl.com')

 # optional (only necessary if the service you use is not the first one 
 # in document order in the WSDL file).
 # If used, it must be called before wsdlinit.
 $soap->servicename('Service1');
 
 # optional, set to a false value if you don't want your 
 # soap message elements to be typed
 $soap->autotype(0);
 
 # never forget to call this !
 $soap->wsdlinit;
 
 # with caching enabled:
 $soap->wsdlinit( caching => 1);
   
 my $som=$soap->call( 'method' ,  
                   name => 'value' ,
                   name => 'value'  );

How it works

SOAP::WSDL takes the wsdl file specified and looks up the port for the service. On calling a SOAP method, it looks up the message encoding and wraps all the stuff around your data accordingly.

Most pre-processing is done in wsdlinit, the rest is done in call, which overrides the same method from SOAP::Lite.

wsdlinit

SOAP::WSDL loads the wsdl file specified by the wsdl parameter / call using SOAP::Lite's schema method. It sets up a XPath object of that wsdl file, and subsequently queries it for namespaces, service, and port elements.

The port you are using is deduced from the URL you're going to connect to. SOAP::WSDL uses the first service (in document order) specified in the wsdl file. If you want to chose a different one, you can specify the service by calling

 $soap->servicename('ServiceToUse');

If you want to specify a service name, do it before calling wsdlinit - it has no effect afterwards.

call

The call method examines the wsdl file to find out how to encode the SOAP message for your method. Lookups are done in real-time using XPath, so this incorporates a small delay to your calls (see "Memory consumption and performance" below.

The SOAP message will include the types for each element, unless you have set autotype to a false value by calling

 $soap->autotype(0);

After wrapping your call into what is appropriate, SOAP::WSDL uses the call() method from SOAP::Lite to dispatch your call.

call takes the method name as first argument, and the parameters passed to that method as following arguments.

Example:

 $som=$soap->call( "SomeMethod" => "test" => "testvalue" );
   
 $som=$soap->call( "SomeMethod" => %args );

Caching

SOAP::WSDL uses a two-stage caching mechanism to achieve best performance.

First, there's a pretty simple caching mechanisms for storing XPath query results. They are just stored in a hash with the XPath path as key (until recently, only results of "find" or "findnodes" are cached). I did not use the obvious Cache or Cache::Cache module here, because these use Storable to store complex objects and thus incorporate a performance loss heavier than using no cache at all. Second, the XPath object and the XPath results cache are be stored on disk using the Cache::FileCache implementation.

A filesystem cache is only used if you

 1) enable caching
 2) set wsdl_cache_directory

The cache directory must be, of course, read- and writeable.

XPath result caching doubles performance, but increases memory consumption - if you lack of memory, you should not enable caching (disabled by default).

Filesystem caching triples performance for wsdlinit and doubles performance for the first method call.

The file system cache is written to disk when the SOAP::WSDL object is destroyed. It may be written to disk any time by calling the "wsdl_cache_store" method

Using both filesystem and in-memory caching is recommended for best performance and smallest startup costs.

Sharing cache between applications

Sharing a file system cache among applications accessing the same web service is generally possible, but may under some circumstances reduce performance, and under some special circumstances even lead to errors. This is due to the cache key algorithm used.

SOAP::WSDL uses the SOAP endpoint URL to store the XML::XPath object of the wsdl file. In the rare case of a web service listening on one particular endpoint (URL) but using more than one WSDL definition, this may lead to errors when applications using SOAP::WSDL share a file system cache.

SOAP::WSDL stores the XPath results in-memory-cache in the filesystem cache, using the key of the wsdl file with _cache appended. Two applications sharing the file system cache and accessing different methods of one web service could overwrite each others in-memory-caches when dumping the XPath results to disk, resulting in a slight performance drawback (even though this only happens in the rare case of one app being started before the other one has had a chance to write its cache to disk).

Controlling the file system cache

If you want full controll over the file system cache, you can use wsdl_init_cash to initialize it. wsdl_init_cash will take the same parameters as Cache::FileCache->new(). See Cache::Cache and Cache::FileCache for details.

Notes

If you plan to write your own caching implementation, you should consider the following:

The XPath results cache must not survive the XPath object SOAP::WSDL uses to store the WSDL file in (this could cause memory holes - see XPath for details). This never happens during normal usage - but note that you have been warned before trying to store and re-read SOAP::WSDL's internal cache.

Methods

call
 $soap->call($method, %data);

See above.

call will die if it can't find required elements in the WSDL file or if your data doesn't meet the WSDL definition's requirements, so you might want to eval{} it. On death, $@ will (hopefully) contain some error message like

 Error processing WSDL: no <definitions> element found

to give you a hint about what went wrong.

no_dispatch

Gets/Sets the no_dispatch flag. If no_dispatch is set to true value, SOAP::WSDL will not dispatch your calls to a remote server but return the SOAP::SOM object containing the call instead.

Useful for testing / debugging

encode
        # this is how call uses encode
        # $xpath contains a XPath object of the wsdl document
         
        my $def=$xpath->find("/definitions")->shift;
        my $parts=$def->find("//message[\@name='$messageName']/part");
  
        my @param=();
  
        while (my $part=$parts->shift) {
                my $enc=$self->encode($part, \%data); 
                push @param, $enc if defined $enc;
        }

Does the actual encoding. Expects a XPath::NodeSet as first, a hashref containing your data as second parameter. The XPath nodeset must be a node specifying a WSDL message part.

You won't need to call encode unless you plan to override call or want to write a new SOAP server implementation.

servicename
 $soap->servicename('Service1');

Use this to specify a service by name (if none specified, the first one in document order from the WSDL file is used). You must call this before calling "wsdlinit".

wsdl
 $soap->wsdl('http://my.web.service.com/wsdl');

Use this to specify the WSDL file to use. Must be a valid (and accessible !) url. You must call this before calling "wsdlinit".

For time saving's sake, this should be a local file - you never know how much time your WebService needs for delivering a wsdl file.

wsdlinit
 $soap->wsdlinit( caching => 1, 
        cache_directory => '/tmp/cache' );

Initializes the WSDL document for usage and looks up the web service and port to use (the port is derived by the URL specified via SOAP::Lite's proxy method).

wsdlinit will die if it can't set up the WSDL file properly, so you might want to eval{} it.

On death, $@ will (hopefully) contain some error message like

 Error processing WSDL: no <definitions> element found

to give you a hint about what went wrong.

wsdlinit will accept a hash of parameters with the following keys:

  • caching

    enables caching is set to a true value

  • cache_directory

    enables filesystem caching (in the directory specified). The directory given must be existant, read- and writeable.

wsdl_cache_directory
 $soap->wsdl_cache_directory( '/tmp/cache' );

Sets the directory used for filesystem caching and enables filesystem caching. Passing the cache_directory parameter to wsdlinit has the same effect.

wsdl_cache_store
 $soap->wsdl_cache_store();

Stores the content of the in-memory-cache (and the XML::XPath representation of the WSDL file) to disk. This will not have any effect if cache_directory is not set.

Notes

Why another SOAP module ?

SOAP::Lite provides only some rudimentary WSDL support. This lack is not just something unimplemented, but an offspring of the SOAP::Schema class design. SOAP::Schema uses some complicated format to store XML Schema information (mostly a big hashref, containing arrays of SOAP::Data and a SOAP::Parser-derived object). This data structure makes it pretty hard to improve SOAP::Lite's WSDL support.

SOAP::WSDL uses XPath for processing WSDL. XPath is a query language standard for XML, and usually a good choice for XML transformations or XML template processing (and what else is WSDL-based en-/decoding ?). Besides, there's an excellent XPath module (XML::XPath) available from CPAN, and as SOAP::Lite uses XPath to access elements in SOAP::SOM objects, this seems like a natural choice.

Fiddling the kind of WSDL support implemented here into SOAP::Lite would mean a larger set of changes, so I decided to build something to use as add-on.

Memory consumption and performance

SOAP::WSDL uses around twice the memory (or even more) SOAP::Lite uses for the same task (but remember: SOAP::WSDL does things for you SOAP::Lite can't). It imposes a slight delay for initialization, and for every SOAP method call, too.

On my 1.4 GHz Pentium mobile notebook, the init delay with a simple WSDL file (containing just one operation and some complex types and elements) was around 50 ms, the delay for the first call around 25 ms and for subsequent calls to the same method around 7 ms without and around 6 ms with XPath result caching (on caching, see above). XML::XPath must do some caching, too - don't know where else the speedup should come from.

Calling a method of a more complex WSDL file (defining around 10 methods and numerous complex types on around 500 lines of XML), the delay for the first call was around 100 ms for the first and 70 ms for subsequent method calls. wsdlinit took around 150 ms to process the stuff. With XPath result caching enabled, all but the first call take around 35 ms.

Using SOAP::WSDL on an idiotically complex WSDL file with just one method, but around 100 parameters for that method, mostly made up by extensions of complex types (the heaviest XPath operation) takes around 1.2 s for the first call (0.9 with caching) and around 830 ms for subsequent calls (arount 570 ms with caching).

The actual performance loss compared to SOAP::Lite should be around 10 % less than the values above - SOAP::Lite encodes the data for you, too (or you do it yourself) - and encoding in SOAP::WSDL is already covered by the pre-call delay time mentioned above.

If you have lots of WebService methods and call each of them from time to time, this delay should not affect your perfomance too much. If you have just one method and keep calling it ever & ever again, you should cosider hardcoding your data encoding (maybe even with hardcoded XML templates - yes, this may be a BIG speedup).

LIMITATIONS

  • <restriction>

    SOAP::WSDL doesn't handle restriction WSDL elements yet.

  • bindings

    SOAP::WSDL does not care about port bindings yet.

  • overloading

    WSDL overloading is not supported yet.

CAVEATS

API change between 1.13 and 1.14

The SOAP::WSDL API changed significantly between versions 1.13 and 1.14. From 1.14 on, call expects the following arguments: method name as scalar first, method parameters as hash following.

The call no longer recognizes the dispatch option - to get the same behaviour, pass no_dispatch = 1> to new or call

 $soap->no_dispatch(1);

Unstable interface

This is alpha software - everything may (and most things will) change. But you don't have to be afraid too much - at least the call synopsis should be stable from 1.14 on, and that is the part you'll use most frequently.

BUGS

  • Arrays of complex types are not checked for the correct number of elements

    Arrays of complex types are just encoded and not checked for correctness etc. I don't know if I do this right yet, but output looks good. However, they are not checked for the correct number of element (does the SOAP spec say how to specify this ?).

  • +trace (and other SOAP::Lite flags) don't work

    This may be an issue with older versions of the base module (before 2.?), or with activestate's activeperl, which do not call the base modules import method with the flags supplied to the parent.

    There's a simple workaround:

     use SOAP::WSDL;
 import SOAP::Lite +trace;

  • nothing else known

    But I'm sure there are some serious bugs lurking around somewhere.

TODO

Implement bindings support

WSDL bindings are required for SOAP authentication. This is not too hard to implement - just look up bindings and decide for each (top level) element whether to put it into header or body.

Allow use of alternative XPath implementations

XML::XPath is a great module, but it's not a race-winning one. XML::LibXML offers a promising-looking XPath interface. SOAP::WSDL should support both, defaulting to the faster one, and leaving the final choice to the user.

CHANGES

$Log: WSDL.pm,v $ Revision 1.17 2004/07/05 08:19:49 lsc - added wsdl_checkoccurs

Revision 1.16 2004/07/04 09:01:14 lsc - change <definitions> element lookup from find('/definitions') and find('wsdl:definitions') to find('/*[1]') to process arbitrary default (wsdl) namespaces correctly - fixed test output in test 06

Revision 1.15 2004/07/02 12:28:31 lsc - documentation update - cosmetics

Revision 1.14 2004/07/02 10:53:36 lsc - API change: - call now behaves (almost) like SOAP::Lite::call - call() takes a list (hash) as second argument - call does no longer support the "dispatch" option - dispatching calls can be suppressed by passing "no_dispatch => 1" to new() - dispatching calls can be suppressed by calling $soap->no_dispatch(1); and re-enabled by calling $soap->no_dispatch(0); - Updated test skripts to reflect API change.

Revision 1.13 2004/06/30 12:08:40 lsc - added IServiceInstance (ecmed) to acceptance tests - refined documentation

Revision 1.12 2004/06/26 14:13:29 lsc - refined file caching - added descriptive output to test scripts

Revision 1.11 2004/06/26 07:55:40 lsc - fixed "freeze" caching bug - improved test scripts to test file system caching (and show the difference)

Revision 1.10 2004/06/26 06:30:33 lsc - added filesystem caching using Cache::FileCache

Revision 1.9 2004/06/24 12:27:23 lsc Cleanup

Revision 1.8 2004/06/11 19:49:15 lsc - moved .t files to more self-describing names - changed WSDL.pm to accept AXIS wsdl files - implemented XPath query result caching on all absolute queries

Revision 1.7 2004/06/07 13:01:16 lsc added changelog to pod

COPYRIGHT

(c) 2004 Martin Kutter

This library is free software, you can use it under the same terms as perl itself.

AUTHOR

Martin Kutter <martin.kutter@fen-net.de>