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

10163Re: .NET, SOAP encoded types and arrays

Expand Messages
  • gddamm
    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
      > >
      > >
      > >
      > >
      > >
      > >
      > >
      > >
      > >
    • Show all 17 messages in this topic