|
|
soapUI: 2.5 - the REST Release
|
|
SOAP::WSDL::Server(3pm) User Contributed Perl Documentation SOAP::WSDL::Server(3pm) NAME
SOAP::WSDL::Server - WSDL based SOAP server base class SYNOPSIS
Don't use directly, use the SOAP::WSDL::Server::* subclasses instead. DESCRIPTION
SOAP::WSDL::Server basically follows the architecture sketched below (though dispatcher classes are not implemented yet) SOAP Request SOAP Response | ^ V | ------------------------------------------ | SOAP::WSDL::Server | | -------------------------------------- | | | Transport Class | | | |--------------------------------------| | | | Deserializer | Serializer | | | |--------------------------------------| | | | Dispatcher | | | -------------------------------------- | ------------------------------------------ | calls ^ v | returns ------------------------------------- | Handler | ------------------------------------- All of the components (Transport class, deserializer, dispatcher and serializer) are implemented as plugins. The architecture is not implemented as planned yet, but the dispatcher is currently part of SOAP::WSDL::Server, which aggregates serializer and deserializer, and is subclassed by transport classes (of which SOAP::WSDL::Server::CGI is the only implemented one yet). The dispatcher is currently based on the SOAPAction header. This does not comply to the WS-I basic profile, which declares the SOAPAction as optional. The final dispatcher will be based on wire signatures (i.e. the classes of the deserialized messages). A hash-based dispatcher could be implemented by examining the top level hash keys. EXCEPTION HANDLING
Builtin exceptions SOAP::WSDL::Server handles the following errors itself: In case of errors, a SOAP Fault containing an appropriate error message is returned. o XML parsing errors o Configuration errors Throwing exceptions The proper way to throw a exception is just to die - SOAP::WSDL::Server::CGI catches the exception and sends a SOAP Fault back to the client. If you want more control over the SOAP Fault sent to the client, you can die with a SOAP::WSDL::SOAP::Fault11 object - or just let the SOAP::Server's deserializer create one for you: my $soap = MyServer::SomeService->new(); die $soap->get_deserializer()->generate_fault({ code => 'SOAP-ENV:Server', role => 'urn:localhost', message => "The error message to pas back", detail => "Some details on the error", }); You may use any other object as exception, provided it has a serialize() method which returns the object's XML representation. Subclassing To write a transport-specific SOAP Server, you should subclass SOAP::WSDL::Server. See the "SOAP::WSDL::Server::*" modules for examples. A SOAP Server must call the following method to actually handle the request: handle Handles the SOAP request. Returns the response message as XML. Expects a "HTTP::Request" object as only parameter. You may use any other object as parameter, as long as it implements the following methods: o header Called as header('SOAPAction'). Must return the corresponding HTTP header. o content Returns the request message 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> REPOSITORY INFORMATION
$Rev: 391 $ $LastChangedBy: kutterma $ $Id: Client.pm 391 2007-11-17 21:56:13Z kutterma $ $HeadURL: https://soap-wsdl.svn.sourceforge.net/svnroot/soap-wsdl/SOAP-WSDL/trunk/lib/SOAP/WSDL/Client.pm $ perl v5.10.1 2010-12-21 SOAP::WSDL::Server(3pm)
