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

Interop between MS .NET and Apache SOAP 2.1

Expand Messages
  • kim.schjefstad@accenture.com
    I wonder if anybody else has had this problem with encodingStyle: I have generated an WSDL file for an Apache 2.1 SOAP RPC service deployed to handle calls
    Message 1 of 2 , Apr 2, 2001
    • 0 Attachment
      I wonder if anybody else has had this problem with encodingStyle:

      I have generated an WSDL file for an Apache 2.1 SOAP RPC service deployed
      to handle calls without the XSI:type attribute. This is tested turning this
      attribute off in Apache SOAP and it works just fine. Now I want to be able
      to use the WSDL file to automatically generate a proxy object in Microsoft
      (MS) .NET (Interim Beta 2).

      My problem is that I use complex datatypes. The MS .NET will not generate a
      proxy with complex types when I use an encoded message and RPC style. So I
      try the option to use literal and document style and then a proxy is
      generated with the complex types. But by using the document/literal option
      the encodingStyle attribute is missing from the SOAP message and my service
      connot find the correct deserializer.

      Some options I connot figure out are:

      1. Is it possible the deploy a service in Apache SOAP 2.1 that can
      deserialize without the encodingStyle attribute by adding entries to the
      SOAPMappingRegistry? Where is the best place to do this?
      2. How come the MS .NET will not generate proxy objects for RPC style
      messages with complex types. Am I missing something here?
      3. Any other suggestions?

      Kind regards,

      Kim Schjefstad


      This message is for the designated recipient only and may contain
      privileged or confidential information. If you have received it in error,
      please notify the sender immediately and delete the original. Any other
      use of the email by you is prohibited.
    • keithba@microsoft.com
      Could you send me your code? .NET should be able to send complex datatypes when doing rpc endcoded. ... deployed ... turning this ... be able ... Microsoft ...
      Message 2 of 2 , Apr 2, 2001
      • 0 Attachment
        Could you send me your code? .NET should be able to send complex
        datatypes when doing rpc endcoded.

        --- In soapbuilders@y..., kim.schjefstad@a... wrote:
        > I wonder if anybody else has had this problem with encodingStyle:
        >
        > I have generated an WSDL file for an Apache 2.1 SOAP RPC service
        deployed
        > to handle calls without the XSI:type attribute. This is tested
        turning this
        > attribute off in Apache SOAP and it works just fine. Now I want to
        be able
        > to use the WSDL file to automatically generate a proxy object in
        Microsoft
        > (MS) .NET (Interim Beta 2).
        >
        > My problem is that I use complex datatypes. The MS .NET will not
        generate a
        > proxy with complex types when I use an encoded message and RPC
        style. So I
        > try the option to use literal and document style and then a proxy is
        > generated with the complex types. But by using the document/literal
        option
        > the encodingStyle attribute is missing from the SOAP message and my
        service
        > connot find the correct deserializer.
        >
        > Some options I connot figure out are:
        >
        > 1. Is it possible the deploy a service in Apache SOAP 2.1 that can
        > deserialize without the encodingStyle attribute by adding entries
        to the
        > SOAPMappingRegistry? Where is the best place to do this?
        > 2. How come the MS .NET will not generate proxy objects for RPC
        style
        > messages with complex types. Am I missing something here?
        > 3. Any other suggestions?
        >
        > Kind regards,
        >
        > Kim Schjefstad
        >
        >
        > This message is for the designated recipient only and may contain
        > privileged or confidential information. If you have received it in
        error,
        > please notify the sender immediately and delete the original. Any
        other
        > use of the email by you is prohibited.
      Your message has been successfully submitted and would be delivered to recipients shortly.