view release on metacpan or  search on metacpan

README  view on Meta::CPAN

        <res2>name2</res2>
        <res3>name3</res3>
      </mehodResponse>

    In that case:

      $result = $r->result; # gives you 'name1'
      $paramout1 = $r->paramsout;      # gives you 'name2', because of scalar context
      $paramout1 = ($r->paramsout)[0]; # gives you 'name2' also
      $paramout2 = ($r->paramsout)[1]; # gives you 'name3'

    or

      @paramsout = $r->paramsout; # gives you ARRAY of out parameters
      $paramout1 = $paramsout[0]; # gives you 'res2', same as ($r->paramsout)[0]
      $paramout2 = $paramsout[1]; # gives you 'res3', same as ($r->paramsout)[1]

    Generally, if server returns "return (1,2,3)" you will get 1 as the
    result and 2 and 3 as out parameters.

    If the server returns "return [1,2,3]" you will get an ARRAY reference
    from "result()" and "undef" from "paramsout()".

    Results can be arbitrary complex: they can be an array references, they
    can be objects, they can be anything and still be returned by "result()"
    . If only one parameter is returned, "paramsout()" will return "undef".

    Furthermore, if you have in your output parameters a parameter with the
    same signature (name+type) as in the input parameters this parameter
    will be mapped into your input automatically. For example:

    Server Code:

      sub mymethod {
        shift; # object/class reference
        my $param1 = shift;
        my $param2 = SOAP::Data->name('myparam' => shift() * 2);
        return $param1, $param2;
      }

    Client Code:

      $a = 10;
      $b = SOAP::Data->name('myparam' => 12);
      $result = $soap->mymethod($a, $b);

    After that, "$result == 10 and $b->value == 24"! Magic? Sort of.

    Autobinding gives it to you. That will work with objects also with one
    difference: you do not need to worry about the name and the type of
    object parameter. Consider the "PingPong" example
    (examples/My/PingPong.pm and examples/pingpong.pl):

    Server Code:

      package My::PingPong;

      sub new {
        my $self = shift;
        my $class = ref($self) || $self;
        bless {_num=>shift} => $class;
      }

      sub next {
        my $self = shift;
        $self->{_num}++;
      }

    Client Code:

      use SOAP::Lite +autodispatch =>
        uri => 'urn:',
        proxy => 'http://localhost/';

      my $p = My::PingPong->new(10); # $p->{_num} is 10 now, real object returned
      print $p->next, "\n";          # $p->{_num} is 11 now!, object autobinded

  STATIC AND DYNAMIC SERVICE DEPLOYMENT
    Let us scrutinize the deployment process. When designing your SOAP
    server you can consider two kind of deployment: static and dynamic. For
    both, static and dynamic, you should specify "MODULE", "MODULE::method",
    "method" or "PATH/" when creating "use"ing the SOAP::Lite module. The
    difference between static and dynamic deployment is that in case of
    'dynamic', any module which is not present will be loaded on demand. See
    the "SECURITY" section for detailed description.

    When statically deploying a SOAP Server, you need to know all modules
    handling SOAP requests before.

    Dynamic deployment allows extending your SOAP Server's interface by just
    installing another module into the dispatch_to path (see below).

   STATIC DEPLOYMENT EXAMPLE
      use SOAP::Transport::HTTP;
      use My::Examples;           # module is preloaded

      SOAP::Transport::HTTP::CGI
         # deployed module should be present here or client will get
         # 'access denied'
        -> dispatch_to('My::Examples')
        -> handle;

    For static deployment you should specify the MODULE name directly.

    You should also use static binding when you have several different
    classes in one file and want to make them available for SOAP calls.

   DYNAMIC DEPLOYMENT EXAMPLE
      use SOAP::Transport::HTTP;
      # name is unknown, module will be loaded on demand

      SOAP::Transport::HTTP::CGI
        # deployed module should be present here or client will get 'access denied'
        -> dispatch_to('/Your/Path/To/Deployed/Modules', 'My::Examples')
        -> handle;

    For dynamic deployment you can specify the name either directly (in that
    case it will be "require"d without any restriction) or indirectly, with
    a PATH. In that case, the ONLY path that will be available will be the
    PATH given to the dispatch_to() method). For information how to handle
    this situation see "SECURITY" section.