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

Re: [soapbuilders] Possible bug with SoapElementAttribute

Expand Messages
  • Jason Brownlee
    Sorry, I though this list was for advanced soap enthusiasts, and though my question was specific I was of the opinion that programmers experienced with looking
    Message 1 of 3 , Feb 27, 2004

      Sorry, I though this list was for advanced soap enthusiasts, and though my question was specific I was of the opinion that programmers experienced with looking at SOAP interoperability problems may have used the .NET platform for some of their interoperability testing may have brushed up against the issue of influencing serialization of object to soap messages.


      Please, let me rephrase my question to one of SOAP interoperability.


      I am attempting to connect a .NET client to a Java webservice. The web service is running on Sun One Application Server 7 (latest patch level) in a production environment. The webservice was created from java objects/interfaces using the webservice tool provided with sun one. All objects used in the service comply with the Sun One documentation for interoperability. The web service works and is currently being used by java clients without problem and has been for the few months.


      The interoperability problem stems from the fact that the Sun One webservice uses what I term SOAP types (http://schemas.xmlsoap.org/soap/encoding) for objects and w3c types (http://www.w3.org/2001/XMLSchema) for primitives in the generated WSDL.


      .NET maps all types onto w3c data types according to the .NET documentation. Messages from Sun One to the .NET  client work fine, messages from the .NET to S1AS fail with de-serialization problems caused by .NET using the wrong types for some data members in the soap messages (S!AS expecting soap type, .NET client always sends w3c types). The types we are talking about are Boolean, Long, Integer, and basically other primitive wrappers.


      The WSDL cannot be changed as it is in a production environment and is being used by live java clients.


      Reading all available documentation pointed to the use of attributes in .NET to influence object serialization to soap messages. It should have been as simple as specifying SoapElementAttribute above each effected data member and specifying the correct namespace to use, if the class had a namespace element as the MSDN class overview indicates.


      A workaround using Web Services Enhancements (WSE 2.0) was implemented which basically intercepted outbound soap messages from the client assembly and override the schema type on specific xml elements. This is a total hack and I believe cannot be used long term due to maintainability issues.


      Another solution may involve writing of a custom serialization class for the web services again, undesirable in the long term for maintained reasons.


      I put this question to domain experts that have more experience than myself in this field to offer any suggestions or alternative workarounds.


      Any help is deeply appreciated.


      ----- Original Message -----
      Sent: Thursday, February 26, 2004 2:33 AM
      Subject: Re: [soapbuilders] Possible bug with SoapElementAttribute

      Hi Jason:

      Jason Brownlee wrote:
      > There may be a bug with the SoapElementAttribute attribute. The
      > overview of this class in MSDN indicates that a namespace property
      > can be set:
      > "If the attribute belongs to a specific XML namespace, set the
      > Namespace property."
      > [...]

      Soapbuilders is a group about SOAP interoperability issues, not about
      specific technology platforms.  We do sometimes get into discussions about
      particular platforms, but only in the context of "FooSoft's package won't
      read the WSDL generated by BarCo" or similar issues.  Otherwise we stick to
      discussing protocols, wire level interop, and the like.

      You should probably ask your question on the Microsoft user groups.


      This group is a forum for builders of SOAP implementations to discuss implementation and interoperability issues.  Please stay on-topic.

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