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

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

Expand Messages
  • 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 1 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.