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

RE: [soapbuilders] Re: .Net Web Service with Java Client

Expand Messages
  • Scott Seely
    Sometimes, you won t be able to change the .NET endpoint. At this point in time, your workarounds would fail to help the end-user. Instead, you might want to
    Message 1 of 4 , Aug 28 12:50 PM
      Sometimes, you won't be able to change the .NET endpoint. At this point
      in time, your workarounds would fail to help the end-user. Instead, you
      might want to concentrate on decoding things properly on the Java side.
      Let's take the super-naïve implementation where, for echoString, you
      take the default setup given by the .NET wizards and have the simple
      echoString as shown in earlier postings:

      [WebMethod]
      public string echoString(string inputString)
      {
      return inputString;
      }

      So, you want to use this from Apache. One of your easiest methods is to
      get the WSDL, edit the WSDL so that the IBM Web Services Toolkit can
      process it, and the use proxygen.bat (or proxygen.sh if on Unix). One of
      the problems is that even if you do this, the proxy generated for you
      will want to stick in information about encoding styles and other
      elements that will allow the right function to be called, but for
      various and sundry reasons, it won't match what the .NET side is
      expecting. Don't worry, you can still get things to work.

      To make everything happen, you will wind up building 4 classes:
      1. The proxy for the .NET endpoint
      2. Override of the body generator. You will have to specialize this
      based on how much you need to encode.
      3. Parser for the SOAP response.
      4. Driver to test everything.

      For something simple like echoString, this is all fairly
      straightforward.

      All of the files to accomplish this are attached to the message. If I
      understand things correctly, the problem that we see here is that Apache
      is setup primarily as an RPC-oriented service. Setting up for
      document-oriented interaction is a bit harder.

      Feel free to browse the attached files. I'm sure that the Apache SOAP
      team can tear this apart and show even better ways to accomplish the
      same task (and I hope that they do ;) ).

      _______________________________
      Scott Seely
      http://msdn.microsoft.com/webservices


      -----Original Message-----
      From: Sanjeev Das [mailto:sanjeevdas@...]
      Sent: Monday, August 27, 2001 1:44 PM
      To: soapbuilders@yahoogroups.com
      Subject: [soapbuilders] Re: .Net Web Service with Java Client

      Hi Derrick
      Had the same problem.
      Turns out that by default .NET uses "Document" style with
      Use="literal"

      To make it work with Apache do either of the following

      a) use RPC style
      b) use Document style with Use=Encoded

      The code would look as follows:

      for a)
      [WebMethod]
      [SoapRpcMethod]
      public string echoString(string inputString)
      {
      return inputString;
      }

      for b)

      [WebMethod]
      [SoapDocumentMethod(Use=SoapBindingUse.Encoded)]
      public string echoString(string inputString)
      {
      return inputString;
      }

      I prefer the first one. Note that if you use Document style with
      encoded parameters the Namespace URI in the generated wsdl becomes
      the namespaceURI + "/encodedTypes"

      Hope this helps

      Sanjeev
    Your message has been successfully submitted and would be delivered to recipients shortly.