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

SOLUTION: [soaplite] SOAP::Lite server with .NET client - SOAPAction woes

Expand Messages
  • Issac Goldstand
    MessageThanks for all the suggestions. I will attempt to include lots of details in this response for the sake of the archives. My original suspicion was that
    Message 1 of 8 , Jul 17, 2004
    • 0 Attachment
      Message
      Thanks for all the suggestions.  I will attempt to include lots of details in this response for the sake of the archives.
       
      My original suspicion was that the MS type namespaces (eg / instead of #, or "s or lack thereof, or urn: or http:, etc) were not the issue, as the *server* is the part that cares about the namespace, and to properly create a proxy from WSDL, any toolkit regardless of the underlying framwork, need to take the WSDL and just *do what it says* 
       
      Futher, using "urn:MyApp" tends to be important when talking to SOAP::Lite, using the format of "urn:Foo/Bar#baz" may be important, simply because when dispatching (I think both dynamicly and staticly) the SOAP calls to the actually methods, SOAP::Lite translates everything between "urn:" and "#" to the class, substituting "/" for "::", and everything after "#" as the method name.  For example:
      soapAction="urn:Foo/Bar#Baz" becomes Foo::Bar::baz (or baz in package Foo::Bar if that wasn't clear)
      soapAction="urn:MyApp#Method" becomes MyApp::Method
      etc
       
      Also, there are lots of mentions in the archives and in the SOAP::Lite docs seemingly saying that MS doesn't play nicely with RPC type operations, but I've encoutnered no problems with it; quite the opposite.
       
      As it turns out, my problem was that MS requires the namespace to be explicitly defined wherever possible.  In my final (working) WSDL, the namespace of wsdl had to be set to "urn:MyApp" (I also set targetNamespace to "urn:MyApp"), and each "main" section needed to be fully qualified (see below for snippet).  Additionally, in the bindings section, each operation's input/output/etc "body" needs to have the namespace fully qualified (eg < soap:body "urn:MyApp:Method" ... />)
       
      Also, make sure to use UTF-8, as I sometimes had crashes when talking utf-16 to SOAP::Lite from MS...
       
      the WSDL structure should thus be as follows:
       
      <?xml version="1.0" encoding="UTF-8"?>
      <wsdl:definitions name="MyApp" targetNamespace="urn:MyApp" xmlns="urn:MyApp" xmlns:tns="urn:MyApp" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" ... >
      <wsdl:message name="MethodRequest">
        <wsdl:part name="somePart" type="xsd:string"/>
      ...
      </wsdl:message>
      <wsdl:portType name="MyAppPortType">
              <wsdl:operation name="Method">
                      <wsdl:input message="tns:MethodRequest"/>
                  <wsdl:output message="tns:MethodResponse"/>
              </wsdl:operation>
      ...
      </wsdl:portType>
      <wsdl:binding name="MyAppBinding" type="tns:MyAppPortType">
              <soap:binding style="rpc" transport="http://schemas.xmlsoap.org/soap/http"/>
              <wsdl:operation name="Method">
                  <soap:operation soapAction="urn:MyApp#Method" style="rpc"/>
                  <wsdl:input>
                      <soap:body namespace="urn:MyApp" use="literal"/>
                  </wsdl:input>
                  <wsdl:output>
                      <soap:body namespace="urn:MyApp" use="literal"/>
                  </wsdl:output>
              </wsdl:operation>
      ...
      </wsdl:binding>
          <wsdl:service name="MyApp">
              <wsdl:port binding="tns:MyAppBinding" name="MyAppPort">
                  <soap:address location="http://localhost:8082"/>
              </wsdl:port>
          </wsdl:service>
      </wsdl:definitions>
       
      One everything was all nice and fully-qualified, it seemed to work fine in .NET 1.x
      I'm currently playing with it on the new beta of 2.0, but I think it's all good there too
       
        Issac
       
      ----- Original Message -----
      Sent: Friday, July 16, 2004 9:44 PM
      Subject: RE: [soaplite] SOAP::Lite server with .NET client - SOAPAction woes

      I have created a .NET client that talks to a SOAP::Lite server (using simple and complex types in either direction)
       
      > SOAP::Serializer::envelope: Client SOAPAction shall match 'uri#method' if
      > present (got 'urn:MyApp#Method)

      -----Original Message-----
      From: jgr@... [mailto:jgr@...] On Behalf Of Klaus Guenter
      Sent: Friday, July 16, 2004 4:43 AM
      To: soaplite@yahoogroups.com
      Subject: Re: [soaplite] SOAP::Lite server with .NET client - SOAPAction woes

      Hi!

      On Tuesday 13 July 2004 15:44, Issac Goldstand wrote:
      > If I explicitly declare the SOAPAction in the WSDL, I get:
      > SOAP::Serializer::envelope: Client SOAPAction shall match 'uri#method' if
      > present (got 'urn:MyApp#Method)
      The syntax for urn: is different in .NET. AFAIR s/#/\//;

      But there is more to check when connecting to .NET, namely the encoding style,
      IIRC.  The MS Knowledge Base has an article  that describes connecting
      SOAP::Lite Clients to .NET Servers and vice versa.

      HTH,
      Klaus
      --
      People often find it easier to be a result of the past than a cause of
      the future.
      -


    • Issac Goldstand
      [Posting on-list so that others can try to give a better answer] Unfortunately, the company I did it for is being *very* touchy about the source code, but I
      Message 2 of 8 , Jul 30, 2004
      • 0 Attachment
        [Posting on-list so that others can try to give a better answer]

        Unfortunately, the company I did it for is being *very* touchy about the
        source code, but I posted a pretty complete server/wsdl/client with the last
        post I put up...

        The message that you get, though, would seem to imply that your server is
        correctly dispatching the method, or more accurately: correctly routing the
        call correctly, but not dispatching it. Make sure that MyApp.pm exists,
        make sure that it's references in the SOAP server's dispatch() call, and
        make sure that MyMethod is under the MyApp package namespace...

        Issac

        ----- Original Message -----
        From: "rprasad64" <rprasad64@...>
        To: <margol@...>
        Sent: Friday, July 30, 2004 3:14 AM
        Subject: SOLUTION: [soaplite] SOAP::Lite server with .NET client -
        SOAPAction woes


        > Hello Isaac,
        >
        > I have spent lot of time figuring out bcos I have
        > the same problem between .NET and SOAP::Lite.
        > Even with the summary you have provided,
        > my server does not get through. I get
        > "Denied access to method (MyMethod) in class MyApp at
        > /usr/lib/perl5/site_perl/5.8.0/SOAP/Lite.pm line 2267"
        >
        > Now would it be possible for you to provide me with a
        > WSDL and you sample server application, so that I can
        > test it myself and see where I have problems.
        >
        > Thanks for your help and best regards,
        >
        > - Prasad
        >
        >
      • Issac Goldstand
        [CC-ing to soaplite list so that others can answer] ... This is straight from the mini-documentation bundled with Cape Clear s wonderful free SOA WSDL editor:
        Message 3 of 8 , Jul 30, 2004
        • 0 Attachment
          [CC-ing to soaplite list so that others can answer]

          ----- Original Message -----
          > > the WSDL structure should thus be as follows:
          >
          > Thanks for posting that. I've been fooling around with a "helloWorld"
          > WSDL and couldn't figure out how to specify the URN. Even though I'm
          > going SOAP::Lite client to SOAP::Lite server (not using .Net), your
          > example explained everything.
          >
          > Tell me, the WSDL sample I found in another posting to the group
          > contained
          >
          > ====================
          > <input>
          > <soap:body
          > encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
          > namespace="http://www.helloWSDL" use="encoded"/>
          > </input>
          > <output>
          > <soap:body
          > encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
          > namespace="http://www.helloWSDL" use="encoded"/>
          > </output>
          > ====================
          >
          > The difference is "use=encoded" and the presence of "encodingStyle".
          > Other than that, the WSDL was pretty close to your example (other
          > than the namespace values). What is the difference between encoded
          > and literal?

          This is straight from the mini-documentation bundled with Cape Clear's
          wonderful free SOA WSDL editor:

          "The use attribute, which is required, indicates whether the message parts
          are encoded using some encoding rules, or if the parts define the physical
          schema of the message. If use is set to encoded , each message part
          references an abstract type using the type attribute. If use is set to
          literal , each part references a physical schema definition using either the
          element or type attribute.
          The encodingStyle attribute is set to a list of URIs, each separated by a
          single space. These URIs represent encodings used with the message, in order
          from the most restrictive to the least restrictive. "

          encodingStyle is only needed when use is set to encoded


          >
          > Also, the style is "rpc" for both of them. Is that customary? Is it
          > possible to return complex structures this way?


          As to rpc/document, the SOAP application's I've developed up till now are
          really remote procedures, so RPC seemed the obvious choice :-) However, if
          you made a SOAP application that, say, modifies an image and returns it, you
          might use document. I'm really not sure of any "side-effects" that choosing
          one over the other entails - perhaps someone can enlighten me?

          >
          > Sorry, I know I should go read the WSDL primer. I just thought you
          > might be able to answer those two for me.


          Read it anyway.

          Issac
        • Mark Fuller
          ... In case anyone wants the WSDL editor, the link is http://www.capescience.com/downloads/index.shtml I haven t installed it yet, but it looks like a
          Message 4 of 8 , Jul 30, 2004
          • 0 Attachment
            --- Issac Goldstand <margol@...> wrote:
            > This is straight from the mini-documentation bundled
            > with Cape Clear's
            > wonderful free SOA WSDL editor:

            In case anyone wants the WSDL editor, the link is

            http://www.capescience.com/downloads/index.shtml

            I haven't installed it yet, but it looks like a
            tremendous to good to be true.

            Mark




            __________________________________
            Do you Yahoo!?
            New and Improved Yahoo! Mail - 100MB free storage!
            http://promotions.yahoo.com/new_mail
          • wxyc
            Issac - I am having a similar problem on making a client(in Axis/Java 1.1) call a SOAP::Lite server, and your post is helpful. However, by following your
            Message 5 of 8 , Aug 12, 2004
            • 0 Attachment
              Issac -

              I am having a similar problem on making a client(in Axis/Java 1.1)
              call a SOAP::Lite server, and your post is helpful.

              However, by following your advices, the problem is not gone.

              My WS server is deployed in the static mode and is not a WSDL-type
              server . Here is the code:

              --------------------8<-----------------------
              #! /usr/local/bin/perl -w
              use SOAP::Transport::HTTP;
              use lib ("/nas/dev/test/testSoap/");
              use EchoYa qw(echoYa);

              $SIG{PIPE} = $SIG{INT} = 'IGNORE';

              $daemon = SOAP::Transport::HTTP::Daemon
              -> new (LocalPort => 8003)
              -> dispatch_to('EchoYa');
              $daemon->handle;
              --------------------8<-----------------------

              The EchoYa.pm is like this:
              --------------------8<-----------------------
              package EchoYa;

              require Exporter;
              @ISA = qw(Exporter);
              @EXPORT = qw( echoYa );

              sub echoYa {
              print "enter echoYa\n";
              my $self = shift;
              my $ya = shift;
              return "I got $ya!";
              }
              1;
              --------------------8<-----------------------

              I changed the relevent line of the client to set the SOAPAction as
              "urn:EchoYa#echoYa", I still got an error:

              SOAPAction shall match 'uri#method' if present (got
              'urn:EchoYa#echoYa', expected '#echoYa'

              You post sounds like you have a WSDL serveice written in SOAP::Lite.
              How did you do that? because SOAP::Lite does not really provide bolts
              and nuts for writing a WSDL server?

              Thanks,

              Donald

              --- In soaplite@yahoogroups.com, "Issac Goldstand" <margol@b...>
              wrote:
              > MessageThanks for all the suggestions. I will attempt to include
              lots of details in this response for the sake of the archives.
              >
              > My original suspicion was that the MS type namespaces (eg / instead
              of #, or "s or lack thereof, or urn: or http:, etc) were not the
              issue, as the *server* is the part that cares about the namespace, and
              to properly create a proxy from WSDL, any toolkit regardless of the
              underlying framwork, need to take the WSDL and just *do what it says*

              >
              > Futher, using "urn:MyApp" tends to be important when talking to
              SOAP::Lite, using the format of "urn:Foo/Bar#baz" may be important,
              simply because when dispatching (I think both dynamicly and staticly)
              the SOAP calls to the actually methods, SOAP::Lite translates
              everything between "urn:" and "#" to the class, substituting "/" for
              "::", and everything after "#" as the method name. For example:
              > soapAction="urn:Foo/Bar#Baz" becomes Foo::Bar::baz (or baz in
              package Foo::Bar if that wasn't clear)
              > soapAction="urn:MyApp#Method" becomes MyApp::Method
              > etc
              >
              > Also, there are lots of mentions in the archives and in the
              SOAP::Lite docs seemingly saying that MS doesn't play nicely with RPC
              type operations, but I've encoutnered no problems with it; quite the
              opposite.
              >
              > As it turns out, my problem was that MS requires the namespace to be
              explicitly defined wherever possible. In my final (working) WSDL, the
              namespace of wsdl had to be set to "urn:MyApp" (I also set
              targetNamespace to "urn:MyApp"), and each "main" section needed to be
              fully qualified (see below for snippet). Additionally, in the
              bindings section, each operation's input/output/etc "body" needs to
              have the namespace fully qualified (eg < soap:body "urn:MyApp:Method"
              ... />)
              >
              > Also, make sure to use UTF-8, as I sometimes had crashes when
              talking utf-16 to SOAP::Lite from MS...
              >
              > the WSDL structure should thus be as follows:
              >
              > <?xml version="1.0" encoding="UTF-8"?>
              > <wsdl:definitions name="MyApp" targetNamespace="urn:MyApp"
              xmlns="urn:MyApp" xmlns:tns="urn:MyApp"
              xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
              xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
              xmlns:xsd="http://www.w3.org/2001/XMLSchema" ... >
              > <wsdl:message name="MethodRequest">
              > <wsdl:part name="somePart" type="xsd:string"/>
              > ...
              > </wsdl:message>
              > <wsdl:portType name="MyAppPortType">
              > <wsdl:operation name="Method">
              > <wsdl:input message="tns:MethodRequest"/>
              > <wsdl:output message="tns:MethodResponse"/>
              > </wsdl:operation>
              > ...
              > </wsdl:portType>
              > <wsdl:binding name="MyAppBinding" type="tns:MyAppPortType">
              > <soap:binding style="rpc"
              transport="http://schemas.xmlsoap.org/soap/http"/>
              > <wsdl:operation name="Method">
              > <soap:operation soapAction="urn:MyApp#Method"
              style="rpc"/>
              > <wsdl:input>
              > <soap:body namespace="urn:MyApp" use="literal"/>
              > </wsdl:input>
              > <wsdl:output>
              > <soap:body namespace="urn:MyApp" use="literal"/>
              > </wsdl:output>
              > </wsdl:operation>
              > ...
              > </wsdl:binding>
              > <wsdl:service name="MyApp">
              > <wsdl:port binding="tns:MyAppBinding" name="MyAppPort">
              > <soap:address location="http://localhost:8082"/>
              > </wsdl:port>
              > </wsdl:service>
              > </wsdl:definitions>
              >
              > One everything was all nice and fully-qualified, it seemed to work
              fine in .NET 1.x
              > I'm currently playing with it on the new beta of 2.0, but I think
              it's all good there too
              >
              > Issac
              >
              > ----- Original Message -----
              > From: Maurice McCabe
              > To: soaplite@yahoogroups.com
              > Sent: Friday, July 16, 2004 9:44 PM
              > Subject: RE: [soaplite] SOAP::Lite server with .NET client -
              SOAPAction woes
              >
              >
              > I have created a .NET client that talks to a SOAP::Lite server
              (using simple and complex types in either direction)
              >
              > > SOAP::Serializer::envelope: Client SOAPAction shall match
              'uri#method' if
              > > present (got 'urn:MyApp#Method)
              >
              > -----Original Message-----
              > From: jgr@p... [mailto:jgr@p...] On Behalf Of Klaus Guenter
              > Sent: Friday, July 16, 2004 4:43 AM
              > To: soaplite@yahoogroups.com
              > Subject: Re: [soaplite] SOAP::Lite server with .NET client -
              SOAPAction woes
              >
              >
              > Hi!
              >
              > On Tuesday 13 July 2004 15:44, Issac Goldstand wrote:
              > > If I explicitly declare the SOAPAction in the WSDL, I get:
              > > SOAP::Serializer::envelope: Client SOAPAction shall match
              'uri#method' if
              > > present (got 'urn:MyApp#Method)
              > The syntax for urn: is different in .NET. AFAIR s/#/\//;
              >
              > But there is more to check when connecting to .NET, namely the
              encoding style,
              > IIRC. The MS Knowledge Base has an article that describes
              connecting
              > SOAP::Lite Clients to .NET Servers and vice versa.
              >
              > HTH,
              > Klaus
              > --
              > People often find it easier to be a result of the past than a
              cause of
              > the future.
              > -
              >
              >
              > Yahoo! Groups Sponsor
              > ADVERTISEMENT
              >
              >
              >
              >
              >
              >
              --------------------------------------------------
              --------------------------
              > Yahoo! Groups Links
              >
              > a.. To visit your group on the web, go to:
              > http://groups.yahoo.com/group/soaplite/
              >
              > b.. To unsubscribe from this group, send an email to:
              > soaplite-unsubscribe@yahoogroups.com
              >
              > c.. Your use of Yahoo! Groups is subject to the Yahoo! Terms
              of Service.
            • Mark Fuller
              ... I m hardly qualified to speak on this, but I don t think you write a WSDL server. You write a web service using SOAP::Lite s server capabilities. You write
              Message 6 of 8 , Aug 12, 2004
              • 0 Attachment
                > How did you do that? because SOAP::Lite does not
                > really provide bolts
                > and nuts for writing a WSDL server?

                I'm hardly qualified to speak on this, but I don't
                think you write a WSDL server. You write a web service
                using SOAP::Lite's server capabilities. You write a
                WSDL defining that service. The WSDL is provided to
                the client.

                I have a working example of this if you would like it.
                I got it to work using Isaac's posted information.

                Email me at amigo_boy2000 y,a,h,o,o, d,o...t c...o,m
                if you want it.

                __________________________________________________
                Do You Yahoo!?
                Tired of spam? Yahoo! Mail has the best spam protection around
                http://mail.yahoo.com
              • Issac Goldstand
                First of all, as Mark already mentioned, you don t write a WSDL server . WSDL is a document which describes the web service, much like DTDs were used for XML
                Message 7 of 8 , Aug 12, 2004
                • 0 Attachment
                  First of all, as Mark already mentioned, you don't write a WSDL "server".
                  WSDL is a document which describes the web service, much like DTDs were used
                  for XML (I think XML Schema's are too complex to make an accurate
                  comparison). Many WS server toolkits help out by generating WSDL for you.
                  SOAP::Lite is, unfortunately, not one of those. WSDL needs to be written
                  the old fashined way - using your favorite text editor.

                  As o the error message, I'm no expert on the SOAP::Lite dispatcher, but it
                  seems to me that the fact that you're exporting the function into the "main"
                  namespace may be confusing it. The dispatcher may come across the "echoYa"
                  method in the "main" namespace first, and send that to the HTTP::Server
                  object to test against the SOAPAction header. Thus, it wouldn't see
                  EchoYa::echoYa as being correct, and spitting that error. Try not
                  exporting/importing symbols to see if that works. (It would also be
                  interesting if you tried calling main::echoYa and seeing if that worked
                  better).

                  Hope that helps a bit,
                  Issac



                  ----- Original Message -----
                  From: "wxyc" <wxyc@...>
                  To: <soaplite@yahoogroups.com>
                  Sent: Thursday, August 12, 2004 6:16 PM
                  Subject: Re: SOLUTION: [soaplite] SOAP::Lite server with .NET client -
                  SOAPAction woes


                  > Issac -
                  >
                  > I am having a similar problem on making a client(in Axis/Java 1.1)
                  > call a SOAP::Lite server, and your post is helpful.
                  >
                  > However, by following your advices, the problem is not gone.
                  >
                  > My WS server is deployed in the static mode and is not a WSDL-type
                  > server . Here is the code:
                  >
                  > --------------------8<-----------------------
                  > #! /usr/local/bin/perl -w
                  > use SOAP::Transport::HTTP;
                  > use lib ("/nas/dev/test/testSoap/");
                  > use EchoYa qw(echoYa);
                  >
                  > $SIG{PIPE} = $SIG{INT} = 'IGNORE';
                  >
                  > $daemon = SOAP::Transport::HTTP::Daemon
                  > -> new (LocalPort => 8003)
                  > -> dispatch_to('EchoYa');
                  > $daemon->handle;
                  > --------------------8<-----------------------
                  >
                  > The EchoYa.pm is like this:
                  > --------------------8<-----------------------
                  > package EchoYa;
                  >
                  > require Exporter;
                  > @ISA = qw(Exporter);
                  > @EXPORT = qw( echoYa );
                  >
                  > sub echoYa {
                  > print "enter echoYa\n";
                  > my $self = shift;
                  > my $ya = shift;
                  > return "I got $ya!";
                  > }
                  > 1;
                  > --------------------8<-----------------------
                  >
                  > I changed the relevent line of the client to set the SOAPAction as
                  > "urn:EchoYa#echoYa", I still got an error:
                  >
                  > SOAPAction shall match 'uri#method' if present (got
                  > 'urn:EchoYa#echoYa', expected '#echoYa'
                  >
                  > You post sounds like you have a WSDL serveice written in SOAP::Lite.
                  > How did you do that? because SOAP::Lite does not really provide bolts
                  > and nuts for writing a WSDL server?
                  >
                  > Thanks,
                  >
                  > Donald
                  >
                  > --- In soaplite@yahoogroups.com, "Issac Goldstand" <margol@b...>
                  > wrote:
                  > > MessageThanks for all the suggestions. I will attempt to include
                  > lots of details in this response for the sake of the archives.
                  > >
                  > > My original suspicion was that the MS type namespaces (eg / instead
                  > of #, or "s or lack thereof, or urn: or http:, etc) were not the
                  > issue, as the *server* is the part that cares about the namespace, and
                  > to properly create a proxy from WSDL, any toolkit regardless of the
                  > underlying framwork, need to take the WSDL and just *do what it says*
                  >
                  > >
                  > > Futher, using "urn:MyApp" tends to be important when talking to
                  > SOAP::Lite, using the format of "urn:Foo/Bar#baz" may be important,
                  > simply because when dispatching (I think both dynamicly and staticly)
                  > the SOAP calls to the actually methods, SOAP::Lite translates
                  > everything between "urn:" and "#" to the class, substituting "/" for
                  > "::", and everything after "#" as the method name. For example:
                  > > soapAction="urn:Foo/Bar#Baz" becomes Foo::Bar::baz (or baz in
                  > package Foo::Bar if that wasn't clear)
                  > > soapAction="urn:MyApp#Method" becomes MyApp::Method
                  > > etc
                  > >
                  > > Also, there are lots of mentions in the archives and in the
                  > SOAP::Lite docs seemingly saying that MS doesn't play nicely with RPC
                  > type operations, but I've encoutnered no problems with it; quite the
                  > opposite.
                  > >
                  > > As it turns out, my problem was that MS requires the namespace to be
                  > explicitly defined wherever possible. In my final (working) WSDL, the
                  > namespace of wsdl had to be set to "urn:MyApp" (I also set
                  > targetNamespace to "urn:MyApp"), and each "main" section needed to be
                  > fully qualified (see below for snippet). Additionally, in the
                  > bindings section, each operation's input/output/etc "body" needs to
                  > have the namespace fully qualified (eg < soap:body "urn:MyApp:Method"
                  > ... />)
                  > >
                  > > Also, make sure to use UTF-8, as I sometimes had crashes when
                  > talking utf-16 to SOAP::Lite from MS...
                  > >
                  > > the WSDL structure should thus be as follows:
                  > >
                  > > <?xml version="1.0" encoding="UTF-8"?>
                  > > <wsdl:definitions name="MyApp" targetNamespace="urn:MyApp"
                  > xmlns="urn:MyApp" xmlns:tns="urn:MyApp"
                  > xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
                  > xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
                  > xmlns:xsd="http://www.w3.org/2001/XMLSchema" ... >
                  > > <wsdl:message name="MethodRequest">
                  > > <wsdl:part name="somePart" type="xsd:string"/>
                  > > ...
                  > > </wsdl:message>
                  > > <wsdl:portType name="MyAppPortType">
                  > > <wsdl:operation name="Method">
                  > > <wsdl:input message="tns:MethodRequest"/>
                  > > <wsdl:output message="tns:MethodResponse"/>
                  > > </wsdl:operation>
                  > > ...
                  > > </wsdl:portType>
                  > > <wsdl:binding name="MyAppBinding" type="tns:MyAppPortType">
                  > > <soap:binding style="rpc"
                  > transport="http://schemas.xmlsoap.org/soap/http"/>
                  > > <wsdl:operation name="Method">
                  > > <soap:operation soapAction="urn:MyApp#Method"
                  > style="rpc"/>
                  > > <wsdl:input>
                  > > <soap:body namespace="urn:MyApp" use="literal"/>
                  > > </wsdl:input>
                  > > <wsdl:output>
                  > > <soap:body namespace="urn:MyApp" use="literal"/>
                  > > </wsdl:output>
                  > > </wsdl:operation>
                  > > ...
                  > > </wsdl:binding>
                  > > <wsdl:service name="MyApp">
                  > > <wsdl:port binding="tns:MyAppBinding" name="MyAppPort">
                  > > <soap:address location="http://localhost:8082"/>
                  > > </wsdl:port>
                  > > </wsdl:service>
                  > > </wsdl:definitions>
                  > >
                  > > One everything was all nice and fully-qualified, it seemed to work
                  > fine in .NET 1.x
                  > > I'm currently playing with it on the new beta of 2.0, but I think
                  > it's all good there too
                  > >
                  > > Issac
                  > >
                  > > ----- Original Message -----
                  > > From: Maurice McCabe
                  > > To: soaplite@yahoogroups.com
                  > > Sent: Friday, July 16, 2004 9:44 PM
                  > > Subject: RE: [soaplite] SOAP::Lite server with .NET client -
                  > SOAPAction woes
                  > >
                  > >
                  > > I have created a .NET client that talks to a SOAP::Lite server
                  > (using simple and complex types in either direction)
                  > >
                  > > > SOAP::Serializer::envelope: Client SOAPAction shall match
                  > 'uri#method' if
                  > > > present (got 'urn:MyApp#Method)
                  > >
                  > > -----Original Message-----
                  > > From: jgr@p... [mailto:jgr@p...] On Behalf Of Klaus Guenter
                  > > Sent: Friday, July 16, 2004 4:43 AM
                  > > To: soaplite@yahoogroups.com
                  > > Subject: Re: [soaplite] SOAP::Lite server with .NET client -
                  > SOAPAction woes
                  > >
                  > >
                  > > Hi!
                  > >
                  > > On Tuesday 13 July 2004 15:44, Issac Goldstand wrote:
                  > > > If I explicitly declare the SOAPAction in the WSDL, I get:
                  > > > SOAP::Serializer::envelope: Client SOAPAction shall match
                  > 'uri#method' if
                  > > > present (got 'urn:MyApp#Method)
                  > > The syntax for urn: is different in .NET. AFAIR s/#/\//;
                  > >
                  > > But there is more to check when connecting to .NET, namely the
                  > encoding style,
                  > > IIRC. The MS Knowledge Base has an article that describes
                  > connecting
                  > > SOAP::Lite Clients to .NET Servers and vice versa.
                  > >
                  > > HTH,
                  > > Klaus
                  > > --
                  > > People often find it easier to be a result of the past than a
                  > cause of
                  > > the future.
                  > > -
                  > >
                  > >
                  > > Yahoo! Groups Sponsor
                  > > ADVERTISEMENT
                  > >
                  > >
                  > >
                  > >
                  > >
                  > >
                  > --------------------------------------------------
                  > --------------------------
                  > > Yahoo! Groups Links
                  > >
                  > > a.. To visit your group on the web, go to:
                  > > http://groups.yahoo.com/group/soaplite/
                  > >
                  > > b.. To unsubscribe from this group, send an email to:
                  > > soaplite-unsubscribe@yahoogroups.com
                  > >
                  > > c.. Your use of Yahoo! Groups is subject to the Yahoo! Terms
                  > of Service.
                  >
                  >
                  >
                  >
                  >
                  > Yahoo! Groups Links
                  >
                  >
                  >
                  >
                  >
                • Donald Chen
                  Issac, Thanks for the WSDL explanation. I was not quite clear about WSDL stuff. It turns out that after a bit tweaks on the way to invoke the service on the
                  Message 8 of 8 , Aug 13, 2004
                  • 0 Attachment
                    Issac,

                    Thanks for the WSDL explanation. I was not quite clear about WSDL stuff.

                    It turns out that after a bit tweaks on the way to invoke the service on the client, it works.
                    (Frankly, I am still do not know why it works). Here are the version which works:

                    -------------------------------------8<-----------------------------
                    1. package samples.userguide.example1;

                    2. import org.apache.axis.client.Call;
                    3. import org.apache.axis.client.Service;
                    4. import javax.xml.namespace.QName;

                    5. public class TestClient {
                    6. public static void main(String [] args) {
                    7. String ret = "1";
                    8. try {
                    9. String endpoint = "http://locahost:8003/echoYaDaemon";
                    10.
                    11. Service service = new Service();
                    12. Call call = (Call) service.createCall();
                    13.
                    14. call.setTargetEndpointAddress( new java.net.URL(endpoint) );
                    15. call.setOperationName(new QName("urn:EchoYa", "echoYa"));
                    16. call.setUseSOAPAction(true);
                    17. call.setSOAPActionURI("urn:EchoYa#echoYa");
                    18.
                    19. ret = (String) call.invoke( new Object[] { args[0] } );
                    20.
                    21. System.out.println("Sent " + args[0] + ", got '" + ret + "'");
                    22. } catch (Exception e) {
                    23. System.err.println(e.toString());
                    24. }
                    25. }
                    26. }
                    -------------------------------------8<-----------------------------
                    As you can see, line 15 and 16 are the ones been altered.

                    As for the exporting/importing the method on the service dispatcher, I tried both with
                    exporting/importing and the without them. They do not make difference.

                    Thanks again,

                    Donald
                    --- Issac Goldstand <margol@...> wrote:

                    > First of all, as Mark already mentioned, you don't write a WSDL "server".
                    > WSDL is a document which describes the web service, much like DTDs were used
                    > for XML (I think XML Schema's are too complex to make an accurate
                    > comparison). Many WS server toolkits help out by generating WSDL for you.
                    > SOAP::Lite is, unfortunately, not one of those. WSDL needs to be written
                    > the old fashined way - using your favorite text editor.
                    >
                    > As o the error message, I'm no expert on the SOAP::Lite dispatcher, but it
                    > seems to me that the fact that you're exporting the function into the "main"
                    > namespace may be confusing it. The dispatcher may come across the "echoYa"
                    > method in the "main" namespace first, and send that to the HTTP::Server
                    > object to test against the SOAPAction header. Thus, it wouldn't see
                    > EchoYa::echoYa as being correct, and spitting that error. Try not
                    > exporting/importing symbols to see if that works. (It would also be
                    > interesting if you tried calling main::echoYa and seeing if that worked
                    > better).
                    >
                    > Hope that helps a bit,
                    > Issac
                    >
                    >
                    >
                    > ----- Original Message -----
                    > From: "wxyc" <wxyc@...>
                    > To: <soaplite@yahoogroups.com>
                    > Sent: Thursday, August 12, 2004 6:16 PM
                    > Subject: Re: SOLUTION: [soaplite] SOAP::Lite server with .NET client -
                    > SOAPAction woes
                    >
                    >
                    > > Issac -
                    > >
                    > > I am having a similar problem on making a client(in Axis/Java 1.1)
                    > > call a SOAP::Lite server, and your post is helpful.
                    > >
                    > > However, by following your advices, the problem is not gone.
                    > >
                    > > My WS server is deployed in the static mode and is not a WSDL-type
                    > > server . Here is the code:
                    > >
                    > > --------------------8<-----------------------
                    > > #! /usr/local/bin/perl -w
                    > > use SOAP::Transport::HTTP;
                    > > use lib ("/nas/dev/test/testSoap/");
                    > > use EchoYa qw(echoYa);
                    > >
                    > > $SIG{PIPE} = $SIG{INT} = 'IGNORE';
                    > >
                    > > $daemon = SOAP::Transport::HTTP::Daemon
                    > > -> new (LocalPort => 8003)
                    > > -> dispatch_to('EchoYa');
                    > > $daemon->handle;
                    > > --------------------8<-----------------------
                    > >
                    > > The EchoYa.pm is like this:
                    > > --------------------8<-----------------------
                    > > package EchoYa;
                    > >
                    > > require Exporter;
                    > > @ISA = qw(Exporter);
                    > > @EXPORT = qw( echoYa );
                    > >
                    > > sub echoYa {
                    > > print "enter echoYa\n";
                    > > my $self = shift;
                    > > my $ya = shift;
                    > > return "I got $ya!";
                    > > }
                    > > 1;
                    > > --------------------8<-----------------------
                    > >
                    > > I changed the relevent line of the client to set the SOAPAction as
                    > > "urn:EchoYa#echoYa", I still got an error:
                    > >
                    > > SOAPAction shall match 'uri#method' if present (got
                    > > 'urn:EchoYa#echoYa', expected '#echoYa'
                    > >
                    > > You post sounds like you have a WSDL serveice written in SOAP::Lite.
                    > > How did you do that? because SOAP::Lite does not really provide bolts
                    > > and nuts for writing a WSDL server?
                    > >
                    > > Thanks,
                    > >
                    > > Donald
                    > >
                    > > --- In soaplite@yahoogroups.com, "Issac Goldstand" <margol@b...>
                    > > wrote:
                    > > > MessageThanks for all the suggestions. I will attempt to include
                    > > lots of details in this response for the sake of the archives.
                    > > >
                    > > > My original suspicion was that the MS type namespaces (eg / instead
                    > > of #, or "s or lack thereof, or urn: or http:, etc) were not the
                    > > issue, as the *server* is the part that cares about the namespace, and
                    > > to properly create a proxy from WSDL, any toolkit regardless of the
                    > > underlying framwork, need to take the WSDL and just *do what it says*
                    > >
                    > > >
                    > > > Futher, using "urn:MyApp" tends to be important when talking to
                    > > SOAP::Lite, using the format of "urn:Foo/Bar#baz" may be important,
                    > > simply because when dispatching (I think both dynamicly and staticly)
                    > > the SOAP calls to the actually methods, SOAP::Lite translates
                    > > everything between "urn:" and "#" to the class, substituting "/" for
                    > > "::", and everything after "#" as the method name. For example:
                    > > > soapAction="urn:Foo/Bar#Baz" becomes Foo::Bar::baz (or baz in
                    > > package Foo::Bar if that wasn't clear)
                    > > > soapAction="urn:MyApp#Method" becomes MyApp::Method
                    > > > etc
                    > > >
                    > > > Also, there are lots of mentions in the archives and in the
                    > > SOAP::Lite docs seemingly saying that MS doesn't play nicely with RPC
                    > > type operations, but I've encoutnered no problems with it; quite the
                    > > opposite.
                    > > >
                    > > > As it turns out, my problem was that MS requires the namespace to be
                    > > explicitly defined wherever possible. In my final (working) WSDL, the
                    > > namespace of wsdl had to be set to "urn:MyApp" (I also set
                    > > targetNamespace to "urn:MyApp"), and each "main" section needed to be
                    > > fully qualified (see below for snippet). Additionally, in the
                    > > bindings section, each operation's input/output/etc "body" needs to
                    > > have the namespace fully qualified (eg < soap:body "urn:MyApp:Method"
                    > > ... />)
                    > > >
                    > > > Also, make sure to use UTF-8, as I sometimes had crashes when
                    > > talking utf-16 to SOAP::Lite from MS...
                    > > >
                    > > > the WSDL structure should thus be as follows:
                    > > >
                    > > > <?xml version="1.0" encoding="UTF-8"?>
                    > > > <wsdl:definitions name="MyApp" targetNamespace="urn:MyApp"
                    > > xmlns="urn:MyApp" xmlns:tns="urn:MyApp"
                    > > xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
                    > > xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
                    > > xmlns:xsd="http://www.w3.org/2001/XMLSchema" ... >
                    > > > <wsdl:message name="MethodRequest">
                    > > > <wsdl:part name="somePart" type="xsd:string"/>
                    > > > ...
                    > > > </wsdl:message>
                    > > > <wsdl:portType name="MyAppPortType">
                    > > > <wsdl:operation name="Method">
                    > > > <wsdl:input message="tns:MethodRequest"/>
                    > > > <wsdl:output message="tns:MethodResponse"/>
                    > > > </wsdl:operation>
                    > > > ...
                    > > > </wsdl:portType>
                    > > > <wsdl:binding name="MyAppBinding" type="tns:MyAppPortType">
                    > > > <soap:binding style="rpc"
                    > > transport="http://schemas.xmlsoap.org/soap/http"/>
                    > > > <wsdl:operation name="Method">
                    > > > <soap:operation soapAction="urn:MyApp#Method"
                    > > style="rpc"/>
                    > > > <wsdl:input>
                    > > > <soap:body namespace="urn:MyApp" use="literal"/>
                    > > > </wsdl:input>
                    > > > <wsdl:output>
                    > > > <soap:body namespace="urn:MyApp" use="literal"/>
                    > > > </wsdl:output>
                    > > > </wsdl:operation>
                    > > > ...
                    > > > </wsdl:binding>
                    > > > <wsdl:service name="MyApp">
                    > > > <wsdl:port binding="tns:MyAppBinding" name="MyAppPort">
                    > > > <soap:address location="http://localhost:8082"/>
                    > > > </wsdl:port>
                    > > > </wsdl:service>
                    > > > </wsdl:definitions>
                    > > >
                    > > > One everything was all nice and fully-qualified, it seemed to work
                    > > fine in .NET 1.x
                    > > > I'm currently playing with it on the new beta of 2.0, but I think
                    > > it's all good there too
                    > > >
                    > > > Issac
                    > > >
                    > > > ----- Original Message -----
                    > > > From: Maurice McCabe
                    > > > To: soaplite@yahoogroups.com
                    > > > Sent: Friday, July 16, 2004 9:44 PM
                    > > > Subject: RE: [soaplite] SOAP::Lite server with .NET client -
                    > > SOAPAction woes
                    > > >
                    > > >
                    > > > I have created a .NET client that talks to a SOAP::Lite server
                    > > (using simple and complex types in either direction)
                    > > >
                    > > > > SOAP::Serializer::envelope: Client SOAPAction shall match
                    > > 'uri#method' if
                    > > > > present (got 'urn:MyApp#Method)
                    > > >
                    > > > -----Original Message-----
                    > > > From: jgr@p... [mailto:jgr@p...] On Behalf Of Klaus Guenter
                    > > > Sent: Friday, July 16, 2004 4:43 AM
                    > > > To: soaplite@yahoogroups.com
                    > > > Subject: Re: [soaplite] SOAP::Lite server with .NET client -
                    > > SOAPAction woes
                    > > >
                    > > >
                    > > > Hi!
                    > > >
                    > > > On Tuesday 13 July 2004 15:44, Issac Goldstand wrote:
                    > > > > If I explicitly declare the SOAPAction in the WSDL, I get:
                    > > > > SOAP::Serializer::envelope: Client SOAPAction shall match
                    >
                    === message truncated ===




                    __________________________________
                    Do you Yahoo!?
                    New and Improved Yahoo! Mail - Send 10MB messages!
                    http://promotions.yahoo.com/new_mail
                  Your message has been successfully submitted and would be delivered to recipients shortly.