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

RE: [soapbuilders] .NET, SOAP encoded types and arrays

Expand Messages
  • Kirill Gavrylyuk
    ... +1. We use SOAP Encoding for encoding and XSD schema for types description. We do not use the SOAP Encoding types to describe the actual data type in WSDL
    Message 1 of 17 , Dec 17, 2004
    • 0 Attachment
      >Don't use soapenc types. It all works fine if you use soapenc:Array as
      >the array mechanism, but
      >use xsd types underneath the covers.

      +1.

      We use SOAP Encoding for encoding and XSD schema for types description.
      We do not use the SOAP Encoding types to describe the actual data type
      in WSDL and in xsi:type. I think this is also the intent of the WSDL
      1.1, and that's what we tested interop on couple years ago.
      From WSDL 1.1: http://www.w3.org/TR/wsdl#_types

      ....Don't include attributes or elements that are peculiar to the wire
      encoding (e.g. have nothing to do with the abstract content of the
      message)...

      Therefore we map Array declaration in WSDL to the programming model
      independently of the encoding.

      Now, when we see soapenc:string our proxy generation tool wsdl.exe makes
      certain optimization and also maps it to the array of strings.

      From there on we expect to xsd:string to be the type of the array
      elements.

      You can change the .Net proxy to use the following type instead of
      string, but then you have all the SOAP Encoding attributes in your
      programming model, which was hardly your intent.

      [System.Xml.Serialization.XmlTypeAttribute(Namespace="http://schemas.xml
      soap.org/soap/encoding/")]
      [System.Xml.Serialization.XmlRootAttribute(Namespace="http://schemas.xml
      soap.org/soap/encoding/", IsNullable=false)]
      public class @string
      {
      public @string(string a) { Value = a;}

      /// <remarks/>
      [System.Xml.Serialization.XmlAttributeAttribute(DataType="ID")]
      public string id;

      /// <remarks/>

      [System.Xml.Serialization.XmlAttributeAttribute(DataType="anyURI")]
      public string href;

      /// <remarks/>
      [System.Xml.Serialization.XmlAnyAttributeAttribute()]
      public System.Xml.XmlAttribute[] AnyAttr;

      /// <remarks/>
      [System.Xml.Serialization.XmlTextAttribute()]
      public string Value;
      }


      >-----Original Message-----
      >From: Wes Moulder [mailto:wes@...]
      >Sent: Friday, December 17, 2004 2:33 PM
      >To: soapbuilders@yahoogroups.com
      >Subject: Re: [soapbuilders] .NET, SOAP encoded types and arrays
      >
      >
      >Tom,
      >Don't use soapenc types. It all works fine if you use soapenc:Array as
      >the array mechanism, but
      >use xsd types underneath the covers. This is what we did back in the
      >day with all the interop testing
      >we were doing.
      >Not all toolkits support those types, but all will behave for the xsd
      >types. The soapenc types were
      >created to allow for the common attributes to appear on the xsd types
      >when attempting to schema
      >validate a soap encoded message. The root of the problem here, though,
      >is attempting to schema
      >validate a soap encoded message.
      >
      >--Wes
      >Still waiting for his autographed Bible from the Come-to-Jesus XML
      >sessions...
      >
      >Tom Jordahl wrote:
      >
      >>Chris,
      >>
      >>This isn't the forum for this.
      >>
      >>I was taking the WS-I axe grinding in good humor up until now.
      >>
      >><rant>
      >>The line that rpc/encoded is the bane of interop is just bullsh*t.
      >>Something I get real tired of hearing from people with an agenda to
      push
      >>(WS-I for instance). This group *in particular* was created to insure
      the
      >>implementations could interoperate, and it succeeded in this respect
      >several
      >>years ago. WITH ENCODING. We were getting the job DONE.
      >>
      >>Then WS-I came along and said (surprise!) that the Microsoft way of
      doing
      >>things (literal) was much more interoperable. Wow. Really? It
      seemed to
      >>me, working on a real implementation (Axis 1.0), that *my* problems
      with
      >>interop didn't stem from encoding, but supporting the *broken*
      encoding in
      >>.NET (hey look, no 2D array support!). And having to invent things
      like
      >>'wrapped' mode to reverse engineer what MS had done with their literal
      >>stuff. And having to rework the whole f**king engine because the Axis
      >>architects decided to support the SOAP 1.1 encoding, just like the
      SOAP
      >>specification SAID, and the world changed its mind.
      >>
      >>Look, I am not going to bash MS, because I am asking them for their
      help.
      >>The fact of the matter is, they have customers and I have customers
      that
      >>need to get *real work* done. My tool kit uses rpc/encoded, they need
      to
      >>interoperate with that. Bottom line. If they have bugs consuming my
      >>rpc/encoded services, as are published today, they need to fix them.
      If I
      >>have bugs consuming their doc/lit services, I need to fix them too.
      >>
      >>With reasoned arguments from people like Tim Ewald and others (mostly
      from
      >>MS) I have had my Come-To-Jesus moment and realized that XML Schema is
      >good.
      >>Literal web services are good. Having the rpc/encoded vs. doc/lit
      wars is
      >>BAD. Why were we given a choice in WSDL 1.1? That was bad. I have
      been
      >>working on the WSDL 2.0 working group for years, and you will notice
      that
      >we
      >>learned from the mistakes. XML Schema is the one-true-way.
      >>
      >>But in the mean time, rpc/encoding exists and works and every major
      >toolkit
      >>supports it. Customers need it to work. You can't dismiss my request
      for
      >>help on this forum with "Use WS-I", that goes directly against the
      spirit
      >in
      >>which this group was formed.
      >></rant>
      >>
      >>I apologize for my rant to those implementers out there that might
      >actually
      >>be able to give me some info about .NET and soap encoded arrays.
      >>
      >>Thanks.
      >>
      >>--
      >>Tom Jordahl
      >>Initial Axis implementer and committer
      >>WSDL 2.0 Working Group member
      >>WS-I representative for Macromedia
      >>ColdFusion Architect
      >>
      >>
      >>
      >>
      >>>-----Original Message-----
      >>>From: Christopher B Ferris [mailto:chrisfer@...]
      >>>Sent: Friday, December 17, 2004 4:22 PM
      >>>To: soapbuilders@yahoogroups.com
      >>>Subject: RE: [soapbuilders] .NET, SOAP encoded types and arrays
      >>>
      >>>
      >>>Tom,
      >>>
      >>>Right, WS-I says not to use rpc/encoded for a reason. SOAP encoding
      is
      >the
      >>>bane of interoperability in
      >>>Web services. Note also that neither SOAP1.1, nor SOAP1.2, require
      >support
      >>>for SOAP encoding:
      >>>
      >>> http://www.w3.org/TR/2000/NOTE-SOAP-20000508/#_Toc478383512
      >>>
      >>>"Use of the data model and encoding style described in this section
      is
      >>>encouraged but
      >>>not required; other data models and encodings can be used in
      conjunction
      >>>with
      >>>SOAP (see section 4.1.1). "
      >>>
      >>>Thus, .NET may freely choose not to support its use.
      >>>
      >>>Regardless of the fact that Axis produces rpc-encoded as the default
      (and
      >>>that should be
      >>>changed IMO), if interoperability is a key requirement, then you need
      to
      >>>be using rpc-literal
      >>>or (preferably) doc-literal WSDL to describe the service, and that
      WSDL
      >>>should be
      >>>WS-I BP 1.x conformant to boot.
      >>>
      >>>Note that IIRC, VisualStudio doesn't eat rpc-literal either, you'd
      have
      >to
      >>>code the C# by hand.
      >>>If you want interop with .NET, then doc-literal or doc-literal
      wrappered
      >>>is the way to go unless
      >>>you are a glutton for punishment.
      >>>
      >>>WS-I Profiles have been hammered out with the intent that they set
      the
      >bar
      >>>for
      >>>interoperability of Web services. Most toolkits support the WS-I BP
      at
      >>>this point.
      >>>While the WS-I BP does not constrain a vendor (or open source
      project)
      >>>from supporting
      >>>features disallowed by the Profile, developers who have
      interoperability
      >>>as a
      >>>non-functional requirement for their service should not be using
      those
      >>>features (e.g.
      >>>SOAP encoding). If you color outside the lines defined by the WS-I
      >>>Profiles,
      >>>then YMMV as to whether you can achieve interoperability with another
      >>>platform/tooling.
      >>>
      >>>Cheers,
      >>>
      >>>Christopher Ferris
      >>>STSM, Emerging e-business Industry Architecture
      >>>email: chrisfer@...
      >>>blog: http://webpages.charter.net/chrisfer/blog.html
      >>>phone: +1 508 377 9295
      >>>
      >>>Tom Jordahl <tomj@...> wrote on 12/17/2004 02:12:41 PM:
      >>>
      >>>
      >>>
      >>>>Well, that is cool for document/literal web services, but there are
      >>>>
      >>>>
      >>>still
      >>>
      >>>
      >>>>*many* toolkits (like say, Axis) that default to rpc/encoded.
      >>>>
      >>>>WS-I says nothing about encoding behaviors (other than not to use
      them).
      >>>>
      >>>>
      >>> So
      >>>
      >>>
      >>>>it doesn't apply here. This is a .NET failure to consume what I
      think
      >>>>
      >>>>
      >>>is a
      >>>
      >>>
      >>>>legitimate rpc/encoded web service.
      >>>>
      >>>>But thanks for playing Chris! :-)
      >>>>
      >>>>--
      >>>>Tom Jordahl
      >>>>Macromedia Server Development
      >>>>
      >>>>
      >>>>
      >>>>>-----Original Message-----
      >>>>>From: Christopher B Ferris [mailto:chrisfer@...]
      >>>>>Sent: Friday, December 17, 2004 1:50 PM
      >>>>>To: soapbuilders@yahoogroups.com
      >>>>>Subject: Re: [soapbuilders] .NET, SOAP encoded types and arrays
      >>>>>
      >>>>>
      >>>>>Could be because WS-I BP1.x disallows use of SOAP encoding. It has
      >>>>>
      >>>>>
      >>>always
      >>>
      >>>
      >>>>>been my understanding
      >>>>>that .NET would not support SOAP encoding.
      >>>>>
      >>>>>Bottom line, you want interop, color inside the lines drawn by the
      >>>>>
      >>>>>
      >>>WS-I
      >>>
      >>>
      >>>>>Profiles:-)
      >>>>>
      >>>>>Cheers,
      >>>>>
      >>>>>Christopher Ferris
      >>>>>STSM, Emerging e-business Industry Architecture
      >>>>>email: chrisfer@...
      >>>>>blog: http://webpages.charter.net/chrisfer/blog.html
      >>>>>phone: +1 508 377 9295
      >>>>>
      >>>>>Tom Jordahl <tomj@...> wrote on 12/17/2004 12:20:40 PM:
      >>>>>
      >>>>>
      >>>>>
      >>>>>>Hello,
      >>>>>>
      >>>>>>Axis recently fixed up its type mapping system and our users have
      >>>>>>
      >>>>>>
      >>>>>reported
      >>>>>
      >>>>>
      >>>>>>some interop problems. Specifically, .NET client does not seem to
      >>>>>>understand the soapenc types that Axis is sending it in SOAP
      encoded
      >>>>>>
      >>>>>>
      >>>>>arrays.
      >>>>>
      >>>>>
      >>>>>>Our WSDL is this:
      >>>>>>
      >>>>>>xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
      >>>>>>
      >>>>>><complexType name="ArrayOf_soapenc_string">
      >>>>>> <complexContent>
      >>>>>> <restriction base="soapenc:Array">
      >>>>>> <attribute ref="soapenc:arrayType"
      >>>>>>
      >>>>>>
      >>>>>wsdl:arrayType="soapenc:string[]"/>
      >>>>>
      >>>>>
      >>>>>> </restriction>
      >>>>>> </complexContent>
      >>>>>></complexType>
      >>>>>>
      >>>>>>For an operation that is simply:
      >>>>>> String[] echo(String[] in)
      >>>>>>
      >>>>>>.NET client sends this (note that it doesn't use the soap encoded
      >>>>>>
      >>>>>>
      >>>>>types):
      >>>>>
      >>>>>
      >>>>>><soap:Body
      >>>>>>
      >>>>>>
      >>>>>soap:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
      >>>>>
      >>>>>
      >>>>>> <q1:echo xmlns:q1="http://DefaultNamespace">
      >>>>>> <in href="#id1" />
      >>>>>> </q1:echo>
      >>>>>> <soapenc:Array id="id1" soapenc:arrayType="xsd:string[3]">
      >>>>>> <Item>one</Item>
      >>>>>> <Item>two</Item>
      >>>>>> <Item>three</Item>
      >>>>>> </soapenc:Array>
      >>>>>></soap:Body>
      >>>>>>
      >>>>>>
      >>>>>>Axis 1.2 returns:
      >>>>>>
      >>>>>><soapenv:Body>
      >>>>>> <ns1:echoResponse
      >>>>>>
      soapenv:encodingStyle=http://schemas.xmlsoap.org/soap/encoding/
      >>>>>> xmlns:ns1="http://DefaultNamespace">
      >>>>>> <echoReturn soapenc:arrayType="soapenc:string[3]"
      >>>>>> xsi:type="soapenc:Array"
      >>>>>>xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/">
      >>>>>> <item>one</item>
      >>>>>> <item>two</item>
      >>>>>> <item>three</item>
      >>>>>> </echoReturn>
      >>>>>> </ns1:echoResponse>
      >>>>>></soapenv:Body>
      >>>>>>
      >>>>>>
      >>>>>>.NET reports an error:
      >>>>>>Unhandled Exception: System.InvalidOperationException: There is an
      >>>>>>
      >>>>>>
      >>>error
      >>>
      >>>
      >>>>>in
      >>>>>
      >>>>>
      >>>>>>XML document (1, 308). ---> System.InvalidOperationException: The
      >>>>>>
      >>>>>>
      >>>>>specified
      >>>>>
      >>>>>
      >>>>>>type was not recognized: name='string',
      >>>>>>namespace='http://schemas.xmlsoap.org/soap/encoding/', at
      >>>>>>
      >>>>>>
      >>><whoamiReturn
      >>>
      >>>
      >>>>>>xmlns=''>.
      >>>>>>
      >>>>>>Actually, C# only says "There is an error in XML document (1,
      311)."
      >>>>>>
      >>>>>>
      >>>-
      >>>
      >>>
      >>>>>this
      >>>>>
      >>>>>
      >>>>>>error is from our user who is using VB.
      >>>>>>
      >>>>>>It appears that only by accident did our previous releases not use
      >>>>>>
      >>>>>>
      >>>the
      >>>
      >>>
      >>>>>SOAP
      >>>>>
      >>>>>
      >>>>>>encoded types due to bugs in our code. Now that we fixed them,
      this
      >>>>>>
      >>>>>>
      >>>>>shows
      >>>>>
      >>>>>
      >>>>>>up. :-}
      >>>>>>
      >>>>>>Why is .NET not using the soapenc types? Why is it unable to
      >>>>>>
      >>>>>>
      >>>recognize
      >>>
      >>>
      >>>>>>these types in a rpc/encoded service? What are other
      implementation
      >>>>>>
      >>>>>>
      >>>>>doing
      >>>>>
      >>>>>
      >>>>>>(particularly JAX-RPC implementation) about the SOAP encoded
      types?
      >>>>>>
      >>>>>>Thanks for any help/info.
      >>>>>>
      >>>>>>--
      >>>>>>Tom Jordahl
      >>>>>>Wearing his Apache Axis committer hat
      >>>>>>
      >>>>>>
      >>>>>>
      >>>>>>
      >>>>>>-----------------------------------------------------------------
      >>>>>>This group is a forum for builders of SOAP implementations to
      >>>>>>
      >>>>>>
      >>>discuss
      >>>
      >>>
      >>>>>implementation and
      >>>>>
      >>>>>
      >>>>>>interoperability issues. Please stay on-topic.
      >>>>>>
      >>>>>>
      >>>>>>
      >>>>>>Yahoo! Groups Sponsor
      >>>>>>
      >>>>>>ADVERTISEMENT
      >>>>>>[image removed]
      >>>>>>
      >>>>>>[image removed]
      >>>>>>
      >>>>>>
      >>>>>>Yahoo! Groups Links
      >>>>>>To visit your group on the web, go to:
      >>>>>>http://groups.yahoo.com/group/soapbuilders/
      >>>>>>
      >>>>>>To unsubscribe from this group, send an email to:
      >>>>>>soapbuilders-unsubscribe@yahoogroups.com
      >>>>>>
      >>>>>>Your use of Yahoo! Groups is subject to the Yahoo! Terms of
      Service.
      >>>>>>
      >>>>>>
      >>>>>
      >>>>>-----------------------------------------------------------------
      >>>>>This group is a forum for builders of SOAP implementations to
      discuss
      >>>>>implementation and interoperability issues. Please stay on-topic.
      >>>>>Yahoo! Groups Links
      >>>>>
      >>>>>
      >>>>>
      >>>>>
      >>>>>
      >>>>>
      >>>>>
      >>>>
      >>>>-----------------------------------------------------------------
      >>>>This group is a forum for builders of SOAP implementations to
      discuss
      >>>>
      >>>>
      >>>implementation and
      >>>
      >>>
      >>>>interoperability issues. Please stay on-topic.
      >>>>
      >>>>
      >>>>
      >>>>Yahoo! Groups Sponsor
      >>>>
      >>>>ADVERTISEMENT
      >>>>[image removed]
      >>>>
      >>>>[image removed]
      >>>>
      >>>>
      >>>>Yahoo! Groups Links
      >>>>To visit your group on the web, go to:
      >>>>http://groups.yahoo.com/group/soapbuilders/
      >>>>
      >>>>To unsubscribe from this group, send an email to:
      >>>>soapbuilders-unsubscribe@yahoogroups.com
      >>>>
      >>>>Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
      >>>>
      >>>>
      >>>
      >>>-----------------------------------------------------------------
      >>>This group is a forum for builders of SOAP implementations to discuss
      >>>implementation and interoperability issues. Please stay on-topic.
      >>>Yahoo! Groups Links
      >>>
      >>>
      >>>
      >>>
      >>>
      >>>
      >>>
      >>
      >>
      >>
      >>
      >>-----------------------------------------------------------------
      >>This group is a forum for builders of SOAP implementations to discuss
      >implementation and interoperability issues. Please stay on-topic.
      >>Yahoo! Groups Links
      >>
      >>
      >>
      >>
      >>
      >>
      >>
      >>
      >>
      >
      >
      >
      >
      >-----------------------------------------------------------------
      >This group is a forum for builders of SOAP implementations to discuss
      >implementation and interoperability issues. Please stay on-topic.
      >Yahoo! Groups Links
      >
      >
      >
      >
      >
      >
    • Nelson Minar
      ... As a builder of SOAP services intended for public use, I can confirm how big a problem this is. Trying to use document/literal web services from clients in
      Message 2 of 17 , Dec 18, 2004
      • 0 Attachment
        >If you'll recall, *doc/lit* interop was in fact vastly harder to
        >achieve, and many toolkits for scripting languages like PERL and Python
        >still don't support it very well if at all, although their RPC/enc
        >behavior is impeccable.

        As a builder of SOAP services intended for public use, I can confirm
        how big a problem this is. Trying to use document/literal web services
        from clients in PHP, Python, or Perl is really difficult. And I
        despair of good doc/lit ever being implemented in those languages,
        because of the general anti-SOAP feeling from many folks who would be
        natural developers for scripting languages. They're too busy getting
        things done with ad-hoc solutions to keep up with WS-* documents.

        I like doc/lit better than rpc/encoded too, and I think that WS-I BP
        1.0 is a great piece of work. But as a practical matter the switch to
        doc/lit has set back interop.
      • gddamm
        This is an interesting thread. I am just starting work creating on an Axis 1.2 based service and have discovered this issue while doing interop testing with a
        Message 3 of 17 , Apr 1, 2005
        • 0 Attachment
          This is an interesting thread. I am just starting work creating on an
          Axis 1.2 based service and have discovered this issue while doing
          interop testing with a .net client. Does anyone on this thread know
          of a simple fix to this issue? I get the don't use soapenc point, but
          not sure how to easily implement with Axis. Is it as simple as using
          an earlier version?

          Thanks for any insight.

          --- In soapbuilders@yahoogroups.com, Wes Moulder <wes@w...> wrote:
          > Tom,
          > Don't use soapenc types. It all works fine if you use soapenc:Array as
          > the array mechanism, but
          > use xsd types underneath the covers. This is what we did back in the
          > day with all the interop testing
          > we were doing.
          > Not all toolkits support those types, but all will behave for the xsd
          > types. The soapenc types were
          > created to allow for the common attributes to appear on the xsd types
          > when attempting to schema
          > validate a soap encoded message. The root of the problem here, though,
          > is attempting to schema
          > validate a soap encoded message.
          >
          > --Wes
          > Still waiting for his autographed Bible from the Come-to-Jesus XML
          > sessions...
          >
          > Tom Jordahl wrote:
          >
          > >Chris,
          > >
          > >This isn't the forum for this.
          > >
          > >I was taking the WS-I axe grinding in good humor up until now.
          > >
          > ><rant>
          > >The line that rpc/encoded is the bane of interop is just bullsh*t.
          > >Something I get real tired of hearing from people with an agenda to
          push
          > >(WS-I for instance). This group *in particular* was created to
          insure the
          > >implementations could interoperate, and it succeeded in this
          respect several
          > >years ago. WITH ENCODING. We were getting the job DONE.
          > >
          > >Then WS-I came along and said (surprise!) that the Microsoft way of
          doing
          > >things (literal) was much more interoperable. Wow. Really? It
          seemed to
          > >me, working on a real implementation (Axis 1.0), that *my* problems
          with
          > >interop didn't stem from encoding, but supporting the *broken*
          encoding in
          > >.NET (hey look, no 2D array support!). And having to invent things
          like
          > >'wrapped' mode to reverse engineer what MS had done with their literal
          > >stuff. And having to rework the whole f**king engine because the Axis
          > >architects decided to support the SOAP 1.1 encoding, just like the SOAP
          > >specification SAID, and the world changed its mind.
          > >
          > >Look, I am not going to bash MS, because I am asking them for their
          help.
          > >The fact of the matter is, they have customers and I have customers
          that
          > >need to get *real work* done. My tool kit uses rpc/encoded, they
          need to
          > >interoperate with that. Bottom line. If they have bugs consuming my
          > >rpc/encoded services, as are published today, they need to fix
          them. If I
          > >have bugs consuming their doc/lit services, I need to fix them too.
          > >
          > >With reasoned arguments from people like Tim Ewald and others
          (mostly from
          > >MS) I have had my Come-To-Jesus moment and realized that XML Schema
          is good.
          > >Literal web services are good. Having the rpc/encoded vs. doc/lit
          wars is
          > >BAD. Why were we given a choice in WSDL 1.1? That was bad. I
          have been
          > >working on the WSDL 2.0 working group for years, and you will
          notice that we
          > >learned from the mistakes. XML Schema is the one-true-way.
          > >
          > >But in the mean time, rpc/encoding exists and works and every major
          toolkit
          > >supports it. Customers need it to work. You can't dismiss my
          request for
          > >help on this forum with "Use WS-I", that goes directly against the
          spirit in
          > >which this group was formed.
          > ></rant>
          > >
          > >I apologize for my rant to those implementers out there that might
          actually
          > >be able to give me some info about .NET and soap encoded arrays.
          > >
          > >Thanks.
          > >
          > >--
          > >Tom Jordahl
          > >Initial Axis implementer and committer
          > >WSDL 2.0 Working Group member
          > >WS-I representative for Macromedia
          > >ColdFusion Architect
          > >
          > >
          > >
          > >
          > >>-----Original Message-----
          > >>From: Christopher B Ferris [mailto:chrisfer@u...]
          > >>Sent: Friday, December 17, 2004 4:22 PM
          > >>To: soapbuilders@yahoogroups.com
          > >>Subject: RE: [soapbuilders] .NET, SOAP encoded types and arrays
          > >>
          > >>
          > >>Tom,
          > >>
          > >>Right, WS-I says not to use rpc/encoded for a reason. SOAP
          encoding is the
          > >>bane of interoperability in
          > >>Web services. Note also that neither SOAP1.1, nor SOAP1.2, require
          support
          > >>for SOAP encoding:
          > >>
          > >> http://www.w3.org/TR/2000/NOTE-SOAP-20000508/#_Toc478383512
          > >>
          > >>"Use of the data model and encoding style described in this section is
          > >>encouraged but
          > >>not required; other data models and encodings can be used in
          conjunction
          > >>with
          > >>SOAP (see section 4.1.1). "
          > >>
          > >>Thus, .NET may freely choose not to support its use.
          > >>
          > >>Regardless of the fact that Axis produces rpc-encoded as the
          default (and
          > >>that should be
          > >>changed IMO), if interoperability is a key requirement, then you
          need to
          > >>be using rpc-literal
          > >>or (preferably) doc-literal WSDL to describe the service, and that
          WSDL
          > >>should be
          > >>WS-I BP 1.x conformant to boot.
          > >>
          > >>Note that IIRC, VisualStudio doesn't eat rpc-literal either, you'd
          have to
          > >>code the C# by hand.
          > >>If you want interop with .NET, then doc-literal or doc-literal
          wrappered
          > >>is the way to go unless
          > >>you are a glutton for punishment.
          > >>
          > >>WS-I Profiles have been hammered out with the intent that they set
          the bar
          > >>for
          > >>interoperability of Web services. Most toolkits support the WS-I BP at
          > >>this point.
          > >>While the WS-I BP does not constrain a vendor (or open source project)
          > >>from supporting
          > >>features disallowed by the Profile, developers who have
          interoperability
          > >>as a
          > >>non-functional requirement for their service should not be using those
          > >>features (e.g.
          > >>SOAP encoding). If you color outside the lines defined by the WS-I
          > >>Profiles,
          > >>then YMMV as to whether you can achieve interoperability with another
          > >>platform/tooling.
          > >>
          > >>Cheers,
          > >>
          > >>Christopher Ferris
          > >>STSM, Emerging e-business Industry Architecture
          > >>email: chrisfer@u...
          > >>blog: http://webpages.charter.net/chrisfer/blog.html
          > >>phone: +1 508 377 9295
          > >>
          > >>Tom Jordahl <tomj@m...> wrote on 12/17/2004 02:12:41 PM:
          > >>
          > >>
          > >>
          > >>>Well, that is cool for document/literal web services, but there are
          > >>>
          > >>>
          > >>still
          > >>
          > >>
          > >>>*many* toolkits (like say, Axis) that default to rpc/encoded.
          > >>>
          > >>>WS-I says nothing about encoding behaviors (other than not to use
          them).
          > >>>
          > >>>
          > >> So
          > >>
          > >>
          > >>>it doesn't apply here. This is a .NET failure to consume what I
          think
          > >>>
          > >>>
          > >>is a
          > >>
          > >>
          > >>>legitimate rpc/encoded web service.
          > >>>
          > >>>But thanks for playing Chris! :-)
          > >>>
          > >>>--
          > >>>Tom Jordahl
          > >>>Macromedia Server Development
          > >>>
          > >>>
          > >>>
          > >>>>-----Original Message-----
          > >>>>From: Christopher B Ferris [mailto:chrisfer@u...]
          > >>>>Sent: Friday, December 17, 2004 1:50 PM
          > >>>>To: soapbuilders@yahoogroups.com
          > >>>>Subject: Re: [soapbuilders] .NET, SOAP encoded types and arrays
          > >>>>
          > >>>>
          > >>>>Could be because WS-I BP1.x disallows use of SOAP encoding. It has
          > >>>>
          > >>>>
          > >>always
          > >>
          > >>
          > >>>>been my understanding
          > >>>>that .NET would not support SOAP encoding.
          > >>>>
          > >>>>Bottom line, you want interop, color inside the lines drawn by the
          > >>>>
          > >>>>
          > >>WS-I
          > >>
          > >>
          > >>>>Profiles:-)
          > >>>>
          > >>>>Cheers,
          > >>>>
          > >>>>Christopher Ferris
          > >>>>STSM, Emerging e-business Industry Architecture
          > >>>>email: chrisfer@u...
          > >>>>blog: http://webpages.charter.net/chrisfer/blog.html
          > >>>>phone: +1 508 377 9295
          > >>>>
          > >>>>Tom Jordahl <tomj@m...> wrote on 12/17/2004 12:20:40 PM:
          > >>>>
          > >>>>
          > >>>>
          > >>>>>Hello,
          > >>>>>
          > >>>>>Axis recently fixed up its type mapping system and our users have
          > >>>>>
          > >>>>>
          > >>>>reported
          > >>>>
          > >>>>
          > >>>>>some interop problems. Specifically, .NET client does not seem to
          > >>>>>understand the soapenc types that Axis is sending it in SOAP
          encoded
          > >>>>>
          > >>>>>
          > >>>>arrays.
          > >>>>
          > >>>>
          > >>>>>Our WSDL is this:
          > >>>>>
          > >>>>>xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
          > >>>>>
          > >>>>><complexType name="ArrayOf_soapenc_string">
          > >>>>> <complexContent>
          > >>>>> <restriction base="soapenc:Array">
          > >>>>> <attribute ref="soapenc:arrayType"
          > >>>>>
          > >>>>>
          > >>>>wsdl:arrayType="soapenc:string[]"/>
          > >>>>
          > >>>>
          > >>>>> </restriction>
          > >>>>> </complexContent>
          > >>>>></complexType>
          > >>>>>
          > >>>>>For an operation that is simply:
          > >>>>> String[] echo(String[] in)
          > >>>>>
          > >>>>>.NET client sends this (note that it doesn't use the soap encoded
          > >>>>>
          > >>>>>
          > >>>>types):
          > >>>>
          > >>>>
          > >>>>><soap:Body
          > >>>>>
          > >>>>>
          > >>>>soap:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
          > >>>>
          > >>>>
          > >>>>> <q1:echo xmlns:q1="http://DefaultNamespace">
          > >>>>> <in href="#id1" />
          > >>>>> </q1:echo>
          > >>>>> <soapenc:Array id="id1" soapenc:arrayType="xsd:string[3]">
          > >>>>> <Item>one</Item>
          > >>>>> <Item>two</Item>
          > >>>>> <Item>three</Item>
          > >>>>> </soapenc:Array>
          > >>>>></soap:Body>
          > >>>>>
          > >>>>>
          > >>>>>Axis 1.2 returns:
          > >>>>>
          > >>>>><soapenv:Body>
          > >>>>> <ns1:echoResponse
          > >>>>> soapenv:encodingStyle=http://schemas.xmlsoap.org/soap/encoding/
          > >>>>> xmlns:ns1="http://DefaultNamespace">
          > >>>>> <echoReturn soapenc:arrayType="soapenc:string[3]"
          > >>>>> xsi:type="soapenc:Array"
          > >>>>>xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/">
          > >>>>> <item>one</item>
          > >>>>> <item>two</item>
          > >>>>> <item>three</item>
          > >>>>> </echoReturn>
          > >>>>> </ns1:echoResponse>
          > >>>>></soapenv:Body>
          > >>>>>
          > >>>>>
          > >>>>>.NET reports an error:
          > >>>>>Unhandled Exception: System.InvalidOperationException: There is an
          > >>>>>
          > >>>>>
          > >>error
          > >>
          > >>
          > >>>>in
          > >>>>
          > >>>>
          > >>>>>XML document (1, 308). ---> System.InvalidOperationException: The
          > >>>>>
          > >>>>>
          > >>>>specified
          > >>>>
          > >>>>
          > >>>>>type was not recognized: name='string',
          > >>>>>namespace='http://schemas.xmlsoap.org/soap/encoding/', at
          > >>>>>
          > >>>>>
          > >><whoamiReturn
          > >>
          > >>
          > >>>>>xmlns=''>.
          > >>>>>
          > >>>>>Actually, C# only says "There is an error in XML document (1,
          311)."
          > >>>>>
          > >>>>>
          > >>-
          > >>
          > >>
          > >>>>this
          > >>>>
          > >>>>
          > >>>>>error is from our user who is using VB.
          > >>>>>
          > >>>>>It appears that only by accident did our previous releases not use
          > >>>>>
          > >>>>>
          > >>the
          > >>
          > >>
          > >>>>SOAP
          > >>>>
          > >>>>
          > >>>>>encoded types due to bugs in our code. Now that we fixed them,
          this
          > >>>>>
          > >>>>>
          > >>>>shows
          > >>>>
          > >>>>
          > >>>>>up. :-}
          > >>>>>
          > >>>>>Why is .NET not using the soapenc types? Why is it unable to
          > >>>>>
          > >>>>>
          > >>recognize
          > >>
          > >>
          > >>>>>these types in a rpc/encoded service? What are other
          implementation
          > >>>>>
          > >>>>>
          > >>>>doing
          > >>>>
          > >>>>
          > >>>>>(particularly JAX-RPC implementation) about the SOAP encoded types?
          > >>>>>
          > >>>>>Thanks for any help/info.
          > >>>>>
          > >>>>>--
          > >>>>>Tom Jordahl
          > >>>>>Wearing his Apache Axis committer hat
          > >>>>>
          > >>>>>
          > >>>>>
          > >>>>>
          > >>>>>-----------------------------------------------------------------
          > >>>>>This group is a forum for builders of SOAP implementations to
          > >>>>>
          > >>>>>
          > >>discuss
          > >>
          > >>
          > >>>>implementation and
          > >>>>
          > >>>>
          > >>>>>interoperability issues. Please stay on-topic.
          > >>>>>
          > >>>>>
          > >>>>>
          > >>>>>Yahoo! Groups Sponsor
          > >>>>>
          > >>>>>ADVERTISEMENT
          > >>>>>[image removed]
          > >>>>>
          > >>>>>[image removed]
          > >>>>>
          > >>>>>
          > >>>>>Yahoo! Groups Links
          > >>>>>To visit your group on the web, go to:
          > >>>>>http://groups.yahoo.com/group/soapbuilders/
          > >>>>>
          > >>>>>To unsubscribe from this group, send an email to:
          > >>>>>soapbuilders-unsubscribe@yahoogroups.com
          > >>>>>
          > >>>>>Your use of Yahoo! Groups is subject to the Yahoo! Terms of
          Service.
          > >>>>>
          > >>>>>
          > >>>>
          > >>>>-----------------------------------------------------------------
          > >>>>This group is a forum for builders of SOAP implementations to
          discuss
          > >>>>implementation and interoperability issues. Please stay on-topic.
          > >>>>Yahoo! Groups Links
          > >>>>
          > >>>>
          > >>>>
          > >>>>
          > >>>>
          > >>>>
          > >>>>
          > >>>
          > >>>-----------------------------------------------------------------
          > >>>This group is a forum for builders of SOAP implementations to discuss
          > >>>
          > >>>
          > >>implementation and
          > >>
          > >>
          > >>>interoperability issues. Please stay on-topic.
          > >>>
          > >>>
          > >>>
          > >>>Yahoo! Groups Sponsor
          > >>>
          > >>>ADVERTISEMENT
          > >>>[image removed]
          > >>>
          > >>>[image removed]
          > >>>
          > >>>
          > >>>Yahoo! Groups Links
          > >>>To visit your group on the web, go to:
          > >>>http://groups.yahoo.com/group/soapbuilders/
          > >>>
          > >>>To unsubscribe from this group, send an email to:
          > >>>soapbuilders-unsubscribe@yahoogroups.com
          > >>>
          > >>>Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
          > >>>
          > >>>
          > >>
          > >>-----------------------------------------------------------------
          > >>This group is a forum for builders of SOAP implementations to discuss
          > >>implementation and interoperability issues. Please stay on-topic.
          > >>Yahoo! Groups Links
          > >>
          > >>
          > >>
          > >>
          > >>
          > >>
          > >>
          > >
          > >
          > >
          > >
          > >-----------------------------------------------------------------
          > >This group is a forum for builders of SOAP implementations to
          discuss implementation and interoperability issues. Please stay
          on-topic.
          > >Yahoo! Groups Links
          > >
          > >
          > >
          > >
          > >
          > >
          > >
          > >
          > >
        • Anne Thomas Manes
          This is not the proper forum to ask user questions. Please send Axis related questions to the Axis user list. See http://ws.apache.org/axis/mail.html. Anne
          Message 4 of 17 , Apr 3, 2005
          • 0 Attachment
            This is not the proper forum to ask user questions. Please send Axis
            related questions to the Axis user list. See
            http://ws.apache.org/axis/mail.html.

            Anne

            On Apr 1, 2005 9:14 PM, gddamm <garyd@...> wrote:
            >
            >
            > This is an interesting thread. I am just starting work creating on an
            > Axis 1.2 based service and have discovered this issue while doing
            > interop testing with a .net client. Does anyone on this thread know
            > of a simple fix to this issue? I get the don't use soapenc point, but
            > not sure how to easily implement with Axis. Is it as simple as using
            > an earlier version?
            >
            > Thanks for any insight.
            >
            > --- In soapbuilders@yahoogroups.com, Wes Moulder <wes@w...> wrote:
            > > Tom,
            > > Don't use soapenc types. It all works fine if you use soapenc:Array as
            > > the array mechanism, but
            > > use xsd types underneath the covers. This is what we did back in the
            > > day with all the interop testing
            > > we were doing.
            > > Not all toolkits support those types, but all will behave for the xsd
            > > types. The soapenc types were
            > > created to allow for the common attributes to appear on the xsd types
            > > when attempting to schema
            > > validate a soap encoded message. The root of the problem here, though,
            > > is attempting to schema
            > > validate a soap encoded message.
            > >
            > > --Wes
            > > Still waiting for his autographed Bible from the Come-to-Jesus XML
            > > sessions...
            > >
            > > Tom Jordahl wrote:
            > >
            > > >Chris,
            > > >
            > > >This isn't the forum for this.
            > > >
            > > >I was taking the WS-I axe grinding in good humor up until now.
            > > >
            > > ><rant>
            > > >The line that rpc/encoded is the bane of interop is just bullsh*t.
            > > >Something I get real tired of hearing from people with an agenda to
            > push
            > > >(WS-I for instance). This group *in particular* was created to
            > insure the
            > > >implementations could interoperate, and it succeeded in this
            > respect several
            > > >years ago. WITH ENCODING. We were getting the job DONE.
            > > >
            > > >Then WS-I came along and said (surprise!) that the Microsoft way of
            > doing
            > > >things (literal) was much more interoperable. Wow. Really? It
            > seemed to
            > > >me, working on a real implementation (Axis 1.0), that *my* problems
            > with
            > > >interop didn't stem from encoding, but supporting the *broken*
            > encoding in
            > > >.NET (hey look, no 2D array support!). And having to invent things
            > like
            > > >'wrapped' mode to reverse engineer what MS had done with their literal
            > > >stuff. And having to rework the whole f**king engine because the Axis
            > > >architects decided to support the SOAP 1.1 encoding, just like the SOAP
            > > >specification SAID, and the world changed its mind.
            > > >
            > > >Look, I am not going to bash MS, because I am asking them for their
            > help.
            > > >The fact of the matter is, they have customers and I have customers
            > that
            > > >need to get *real work* done. My tool kit uses rpc/encoded, they
            > need to
            > > >interoperate with that. Bottom line. If they have bugs consuming my
            > > >rpc/encoded services, as are published today, they need to fix
            > them. If I
            > > >have bugs consuming their doc/lit services, I need to fix them too.
            > > >
            > > >With reasoned arguments from people like Tim Ewald and others
            > (mostly from
            > > >MS) I have had my Come-To-Jesus moment and realized that XML Schema
            > is good.
            > > >Literal web services are good. Having the rpc/encoded vs. doc/lit
            > wars is
            > > >BAD. Why were we given a choice in WSDL 1.1? That was bad. I
            > have been
            > > >working on the WSDL 2.0 working group for years, and you will
            > notice that we
            > > >learned from the mistakes. XML Schema is the one-true-way.
            > > >
            > > >But in the mean time, rpc/encoding exists and works and every major
            > toolkit
            > > >supports it. Customers need it to work. You can't dismiss my
            > request for
            > > >help on this forum with "Use WS-I", that goes directly against the
            > spirit in
            > > >which this group was formed.
            > > ></rant>
            > > >
            > > >I apologize for my rant to those implementers out there that might
            > actually
            > > >be able to give me some info about .NET and soap encoded arrays.
            > > >
            > > >Thanks.
            > > >
            > > >--
            > > >Tom Jordahl
            > > >Initial Axis implementer and committer
            > > >WSDL 2.0 Working Group member
            > > >WS-I representative for Macromedia
            > > >ColdFusion Architect
            > > >
            > > >
            > > >
            > > >
            > > >>-----Original Message-----
            > > >>From: Christopher B Ferris [mailto:chrisfer@u...]
            > > >>Sent: Friday, December 17, 2004 4:22 PM
            > > >>To: soapbuilders@yahoogroups.com
            > > >>Subject: RE: [soapbuilders] .NET, SOAP encoded types and arrays
            > > >>
            > > >>
            > > >>Tom,
            > > >>
            > > >>Right, WS-I says not to use rpc/encoded for a reason. SOAP
            > encoding is the
            > > >>bane of interoperability in
            > > >>Web services. Note also that neither SOAP1.1, nor SOAP1.2, require
            > support
            > > >>for SOAP encoding:
            > > >>
            > > >> http://www.w3.org/TR/2000/NOTE-SOAP-20000508/#_Toc478383512
            > > >>
            > > >>"Use of the data model and encoding style described in this section is
            > > >>encouraged but
            > > >>not required; other data models and encodings can be used in
            > conjunction
            > > >>with
            > > >>SOAP (see section 4.1.1). "
            > > >>
            > > >>Thus, .NET may freely choose not to support its use.
            > > >>
            > > >>Regardless of the fact that Axis produces rpc-encoded as the
            > default (and
            > > >>that should be
            > > >>changed IMO), if interoperability is a key requirement, then you
            > need to
            > > >>be using rpc-literal
            > > >>or (preferably) doc-literal WSDL to describe the service, and that
            > WSDL
            > > >>should be
            > > >>WS-I BP 1.x conformant to boot.
            > > >>
            > > >>Note that IIRC, VisualStudio doesn't eat rpc-literal either, you'd
            > have to
            > > >>code the C# by hand.
            > > >>If you want interop with .NET, then doc-literal or doc-literal
            > wrappered
            > > >>is the way to go unless
            > > >>you are a glutton for punishment.
            > > >>
            > > >>WS-I Profiles have been hammered out with the intent that they set
            > the bar
            > > >>for
            > > >>interoperability of Web services. Most toolkits support the WS-I BP at
            > > >>this point.
            > > >>While the WS-I BP does not constrain a vendor (or open source project)
            > > >>from supporting
            > > >>features disallowed by the Profile, developers who have
            > interoperability
            > > >>as a
            > > >>non-functional requirement for their service should not be using those
            > > >>features (e.g.
            > > >>SOAP encoding). If you color outside the lines defined by the WS-I
            > > >>Profiles,
            > > >>then YMMV as to whether you can achieve interoperability with another
            > > >>platform/tooling.
            > > >>
            > > >>Cheers,
            > > >>
            > > >>Christopher Ferris
            > > >>STSM, Emerging e-business Industry Architecture
            > > >>email: chrisfer@u...
            > > >>blog: http://webpages.charter.net/chrisfer/blog.html
            > > >>phone: +1 508 377 9295
            > > >>
            > > >>Tom Jordahl <tomj@m...> wrote on 12/17/2004 02:12:41 PM:
            > > >>
            > > >>
            > > >>
            > > >>>Well, that is cool for document/literal web services, but there are
            > > >>>
            > > >>>
            > > >>still
            > > >>
            > > >>
            > > >>>*many* toolkits (like say, Axis) that default to rpc/encoded.
            > > >>>
            > > >>>WS-I says nothing about encoding behaviors (other than not to use
            > them).
            > > >>>
            > > >>>
            > > >> So
            > > >>
            > > >>
            > > >>>it doesn't apply here. This is a .NET failure to consume what I
            > think
            > > >>>
            > > >>>
            > > >>is a
            > > >>
            > > >>
            > > >>>legitimate rpc/encoded web service.
            > > >>>
            > > >>>But thanks for playing Chris! :-)
            > > >>>
            > > >>>--
            > > >>>Tom Jordahl
            > > >>>Macromedia Server Development
            > > >>>
            > > >>>
            > > >>>
            > > >>>>-----Original Message-----
            > > >>>>From: Christopher B Ferris [mailto:chrisfer@u...]
            > > >>>>Sent: Friday, December 17, 2004 1:50 PM
            > > >>>>To: soapbuilders@yahoogroups.com
            > > >>>>Subject: Re: [soapbuilders] .NET, SOAP encoded types and arrays
            > > >>>>
            > > >>>>
            > > >>>>Could be because WS-I BP1.x disallows use of SOAP encoding. It has
            > > >>>>
            > > >>>>
            > > >>always
            > > >>
            > > >>
            > > >>>>been my understanding
            > > >>>>that .NET would not support SOAP encoding.
            > > >>>>
            > > >>>>Bottom line, you want interop, color inside the lines drawn by the
            > > >>>>
            > > >>>>
            > > >>WS-I
            > > >>
            > > >>
            > > >>>>Profiles:-)
            > > >>>>
            > > >>>>Cheers,
            > > >>>>
            > > >>>>Christopher Ferris
            > > >>>>STSM, Emerging e-business Industry Architecture
            > > >>>>email: chrisfer@u...
            > > >>>>blog: http://webpages.charter.net/chrisfer/blog.html
            > > >>>>phone: +1 508 377 9295
            > > >>>>
            > > >>>>Tom Jordahl <tomj@m...> wrote on 12/17/2004 12:20:40 PM:
            > > >>>>
            > > >>>>
            > > >>>>
            > > >>>>>Hello,
            > > >>>>>
            > > >>>>>Axis recently fixed up its type mapping system and our users have
            > > >>>>>
            > > >>>>>
            > > >>>>reported
            > > >>>>
            > > >>>>
            > > >>>>>some interop problems. Specifically, .NET client does not seem to
            > > >>>>>understand the soapenc types that Axis is sending it in SOAP
            > encoded
            > > >>>>>
            > > >>>>>
            > > >>>>arrays.
            > > >>>>
            > > >>>>
            > > >>>>>Our WSDL is this:
            > > >>>>>
            > > >>>>>xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
            > > >>>>>
            > > >>>>><complexType name="ArrayOf_soapenc_string">
            > > >>>>> <complexContent>
            > > >>>>> <restriction base="soapenc:Array">
            > > >>>>> <attribute ref="soapenc:arrayType"
            > > >>>>>
            > > >>>>>
            > > >>>>wsdl:arrayType="soapenc:string[]"/>
            > > >>>>
            > > >>>>
            > > >>>>> </restriction>
            > > >>>>> </complexContent>
            > > >>>>></complexType>
            > > >>>>>
            > > >>>>>For an operation that is simply:
            > > >>>>> String[] echo(String[] in)
            > > >>>>>
            > > >>>>>.NET client sends this (note that it doesn't use the soap encoded
            > > >>>>>
            > > >>>>>
            > > >>>>types):
            > > >>>>
            > > >>>>
            > > >>>>><soap:Body
            > > >>>>>
            > > >>>>>
            > > >>>>soap:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
            > > >>>>
            > > >>>>
            > > >>>>> <q1:echo xmlns:q1="http://DefaultNamespace">
            > > >>>>> <in href="#id1" />
            > > >>>>> </q1:echo>
            > > >>>>> <soapenc:Array id="id1" soapenc:arrayType="xsd:string[3]">
            > > >>>>> <Item>one</Item>
            > > >>>>> <Item>two</Item>
            > > >>>>> <Item>three</Item>
            > > >>>>> </soapenc:Array>
            > > >>>>></soap:Body>
            > > >>>>>
            > > >>>>>
            > > >>>>>Axis 1.2 returns:
            > > >>>>>
            > > >>>>><soapenv:Body>
            > > >>>>> <ns1:echoResponse
            > > >>>>> soapenv:encodingStyle=http://schemas.xmlsoap.org/soap/encoding/
            > > >>>>> xmlns:ns1="http://DefaultNamespace">
            > > >>>>> <echoReturn soapenc:arrayType="soapenc:string[3]"
            > > >>>>> xsi:type="soapenc:Array"
            > > >>>>>xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/">
            > > >>>>> <item>one</item>
            > > >>>>> <item>two</item>
            > > >>>>> <item>three</item>
            > > >>>>> </echoReturn>
            > > >>>>> </ns1:echoResponse>
            > > >>>>></soapenv:Body>
            > > >>>>>
            > > >>>>>
            > > >>>>>.NET reports an error:
            > > >>>>>Unhandled Exception: System.InvalidOperationException: There is an
            > > >>>>>
            > > >>>>>
            > > >>error
            > > >>
            > > >>
            > > >>>>in
            > > >>>>
            > > >>>>
            > > >>>>>XML document (1, 308). ---> System.InvalidOperationException: The
            > > >>>>>
            > > >>>>>
            > > >>>>specified
            > > >>>>
            > > >>>>
            > > >>>>>type was not recognized: name='string',
            > > >>>>>namespace='http://schemas.xmlsoap.org/soap/encoding/', at
            > > >>>>>
            > > >>>>>
            > > >><whoamiReturn
            > > >>
            > > >>
            > > >>>>>xmlns=''>.
            > > >>>>>
            > > >>>>>Actually, C# only says "There is an error in XML document (1,
            > 311)."
            > > >>>>>
            > > >>>>>
            > > >>-
            > > >>
            > > >>
            > > >>>>this
            > > >>>>
            > > >>>>
            > > >>>>>error is from our user who is using VB.
            > > >>>>>
            > > >>>>>It appears that only by accident did our previous releases not use
            > > >>>>>
            > > >>>>>
            > > >>the
            > > >>
            > > >>
            > > >>>>SOAP
            > > >>>>
            > > >>>>
            > > >>>>>encoded types due to bugs in our code. Now that we fixed them,
            > this
            > > >>>>>
            > > >>>>>
            > > >>>>shows
            > > >>>>
            > > >>>>
            > > >>>>>up. :-}
            > > >>>>>
            > > >>>>>Why is .NET not using the soapenc types? Why is it unable to
            > > >>>>>
            > > >>>>>
            > > >>recognize
            > > >>
            > > >>
            > > >>>>>these types in a rpc/encoded service? What are other
            > implementation
            > > >>>>>
            > > >>>>>
            > > >>>>doing
            > > >>>>
            > > >>>>
            > > >>>>>(particularly JAX-RPC implementation) about the SOAP encoded types?
            > > >>>>>
            > > >>>>>Thanks for any help/info.
            > > >>>>>
            > > >>>>>--
            > > >>>>>Tom Jordahl
            > > >>>>>Wearing his Apache Axis committer hat
            > > >>>>>
            > > >>>>>
            > > >>>>>
            > > >>>>>
            > > >>>>>-----------------------------------------------------------------
            > > >>>>>This group is a forum for builders of SOAP implementations to
            > > >>>>>
            > > >>>>>
            > > >>discuss
            > > >>
            > > >>
            > > >>>>implementation and
            > > >>>>
            > > >>>>
            > > >>>>>interoperability issues. Please stay on-topic.
            > > >>>>>
            > > >>>>>
            > > >>>>>
            > > >>>>>Yahoo! Groups Sponsor
            > > >>>>>
            > > >>>>>ADVERTISEMENT
            > > >>>>>[image removed]
            > > >>>>>
            > > >>>>>[image removed]
            > > >>>>>
            > > >>>>>
            > > >>>>>Yahoo! Groups Links
            > > >>>>>To visit your group on the web, go to:
            > > >>>>>http://groups.yahoo.com/group/soapbuilders/
            > > >>>>>
            > > >>>>>To unsubscribe from this group, send an email to:
            > > >>>>>soapbuilders-unsubscribe@yahoogroups.com
            > > >>>>>
            > > >>>>>Your use of Yahoo! Groups is subject to the Yahoo! Terms of
            > Service.
            > > >>>>>
            > > >>>>>
            > > >>>>
            > > >>>>-----------------------------------------------------------------
            > > >>>>This group is a forum for builders of SOAP implementations to
            > discuss
            > > >>>>implementation and interoperability issues. Please stay on-topic.
            > > >>>>Yahoo! Groups Links
            > > >>>>
            > > >>>>
            > > >>>>
            > > >>>>
            > > >>>>
            > > >>>>
            > > >>>>
            > > >>>
            > > >>>-----------------------------------------------------------------
            > > >>>This group is a forum for builders of SOAP implementations to discuss
            > > >>>
            > > >>>
            > > >>implementation and
            > > >>
            > > >>
            > > >>>interoperability issues. Please stay on-topic.
            > > >>>
            > > >>>
            > > >>>
            > > >>>Yahoo! Groups Sponsor
            > > >>>
            > > >>>ADVERTISEMENT
            > > >>>[image removed]
            > > >>>
            > > >>>[image removed]
            > > >>>
            > > >>>
            > > >>>Yahoo! Groups Links
            > > >>>To visit your group on the web, go to:
            > > >>>http://groups.yahoo.com/group/soapbuilders/
            > > >>>
            > > >>>To unsubscribe from this group, send an email to:
            > > >>>soapbuilders-unsubscribe@yahoogroups.com
            > > >>>
            > > >>>Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
            > > >>>
            > > >>>
            > > >>
            > > >>-----------------------------------------------------------------
            > > >>This group is a forum for builders of SOAP implementations to discuss
            > > >>implementation and interoperability issues. Please stay on-topic.
            > > >>Yahoo! Groups Links
            > > >>
            > > >>
            > > >>
            > > >>
            > > >>
            > > >>
            > > >>
            > > >
            > > >
            > > >
            > > >
            > > >-----------------------------------------------------------------
            > > >This group is a forum for builders of SOAP implementations to
            > discuss implementation and interoperability issues. Please stay
            > on-topic.
            > > >Yahoo! Groups Links
            > > >
            > > >
            > > >
            > > >
            > > >
            > > >
            > > >
            > > >
            > > >
            >
            > -----------------------------------------------------------------
            > This group is a forum for builders of SOAP implementations to discuss implementation and interoperability issues. Please stay on-topic.
            > Yahoo! Groups Links
            >
            >
            >
            >
            >
          Your message has been successfully submitted and would be delivered to recipients shortly.