Loading ...
Sorry, an error occurred while loading the content.

Re: [soaplite] SOAP::Lite issue with WS-I Basic Profile

Expand Messages
  • Mark Fuller
    If you don t (can t) specify the namespace in the WSDL, then SOAP::Lite will expect to find it in Perl s main namespace. Will it work if you put the subroutine
    Message 1 of 3 , Sep 14, 2004
    View Source
    • 0 Attachment
      If you don't (can't) specify the namespace in the
      WSDL, then SOAP::Lite will expect to find it in Perl's
      main namespace. Will it work if you put the subroutine
      in main (not packaged under another name) and tell
      SOAP::Lite:

      ->dispatch_to('main')

      or

      ->dispatch_to('main::my_method_name')

      I know this works with Transport::HTTP::Daemon. I'm
      not sure how your use of Apache::SOAP would change
      this.(?)

      Mark

      --- supertux1 <supertux1@...> wrote:

      > Background:
      >
      > I've got a Document-Literal Wrapped web service
      > which runs on
      > SOAP::Lite and is dispatched with a modified
      > Apache::SOAP.
      > It uses WSDL files which must be WS-I Basic Profile
      > compliant.
      >
      > In the WSDL bindings, operation element, the
      > SOAP::Lite server fails
      > to find a class name if you configure the body
      > message as such:
      >
      > <soap:body use="literal"/>
      >
      > The request envelope looks something like this:
      > <SOAP-ENV:Body><Test xmlns="">.....
      > and the error is:
      > <faultstring>Denied access to method (Test) in class
      > (main) at ....
      >
      > However if you do it like this:
      >
      > <soap:body
      > namespace="http://wherever/My/Perl/Module"
      > use="literal"/>
      >
      > The SOAP::Lite server can find the class, the call
      > works, the
      > request envelope looks like this:
      > <SOAP-ENV:Body><Test
      > xmlns="http://wherever/My/Perl/Module">.....
      >
      > So what's the problem if it works? The way that
      > works requires you
      > to format the WSDL in a way which fails the WS-I
      > Basic Profile Tests,
      > that is to combine use="literal" with a
      > namespace="..." which is
      > illegal.
      >
      > Sure, you could override the client serializer and
      > shove the
      > namespace in there
      > (http://ads.harvard.edu/~alberto/SOAP/literal-
      > howto-client.pl) but doesn't that defeat the purpose
      > of the WSDL
      > telling the client what the namespaces should be?
      >
      > How should this be fixed? Well, SOAPAction in the
      > header contains
      > something like: SOAPAction:
      > "http://wherever/My/Perl/Module#Test"
      >
      > Can the SOAP::Lite server be made to look at THAT
      > instead
      > of <SOAP-ENV:Body><Test xmlns="">..... when deciding
      > which
      > class/module and method to invoke? I tried writing
      > an overriding
      > Deserializer on the server side, but it is not being
      > invoked before
      > the soap lite server returns with a fault.




      _______________________________
      Do you Yahoo!?
      Declare Yourself - Register online to vote today!
      http://vote.yahoo.com
    • supertux1
      I found a workaround for this. This forces the dispatch to go whatever was put in the SOAPAction header. It appears to work but needs more testing. (This is in
      Message 2 of 3 , Sep 14, 2004
      View Source
      • 0 Attachment
        I found a workaround for this.

        This forces the dispatch to go whatever was put
        in the SOAPAction header. It appears to work
        but needs more testing.

        (This is in the handler() block of a mod_perl
        PerlHandler Apache module, $r is the request object.)

        my ($r) = @_;
        my ($action,$class,$method);
        $server->on_dispatch(sub {
        $action = $r->header_in("SOAPAction");
        $action =~ s#\"##g;
        ($class,$method) = split('\#',$action);
        return ($class,$method);
        });


        --- In soaplite@yahoogroups.com, "supertux1" <supertux1@y...> wrote:
        > Background:
        >
        > I've got a Document-Literal Wrapped web service which runs on
        > SOAP::Lite and is dispatched with a modified Apache::SOAP.
        > It uses WSDL files which must be WS-I Basic Profile compliant.
        >
        > In the WSDL bindings, operation element, the SOAP::Lite server
        fails
        > to find a class name if you configure the body message as such:
        >
        > <soap:body use="literal"/>
        >
        > The request envelope looks something like this:
        > <SOAP-ENV:Body><Test xmlns="">.....
        > and the error is:
        > <faultstring>Denied access to method (Test) in class (main) at ....
        >
        > However if you do it like this:
        >
        > <soap:body namespace="http://wherever/My/Perl/Module"
        > use="literal"/>
        >
        > The SOAP::Lite server can find the class, the call works, the
        > request envelope looks like this:
        > <SOAP-ENV:Body><Test xmlns="http://wherever/My/Perl/Module">.....
        >
        > So what's the problem if it works? The way that works requires you
        > to format the WSDL in a way which fails the WS-I Basic Profile
        Tests,
        > that is to combine use="literal" with a namespace="..." which is
        > illegal.
        >
        > Sure, you could override the client serializer and shove the
        > namespace in there (http://ads.harvard.edu/~alberto/SOAP/literal-
        > howto-client.pl) but doesn't that defeat the purpose of the WSDL
        > telling the client what the namespaces should be?
        >
        > How should this be fixed? Well, SOAPAction in the header contains
        > something like: SOAPAction: "http://wherever/My/Perl/Module#Test"
        >
        > Can the SOAP::Lite server be made to look at THAT instead
        > of <SOAP-ENV:Body><Test xmlns="">..... when deciding which
        > class/module and method to invoke? I tried writing an overriding
        > Deserializer on the server side, but it is not being invoked before
        > the soap lite server returns with a fault.
      Your message has been successfully submitted and would be delivered to recipients shortly.