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

Re: [soapbuilders] whatever happened to interop testing

Expand Messages
  • Steve Loughran
    ... As usual, the thought of long-haul travel to spend a week in a windowless room with a patchy WLAN fills me with enthusiam, an enthusiasm barely dampened by
    Message 1 of 20 , Feb 18, 2006
    • 0 Attachment
      On 2/17/06, Glen Daniels <glen@...> wrote:

      >
      > P.S. Seriously, would any of the other vendors out there be interested
      > in a SOAPBuilders interop get-together if Sonic hosted one sometime this
      > Spring (tests TBD on this list of course)? Do people still see a need
      > for developer-focused interoperability work outside WSI and MS? Discuss.
      >


      As usual, the thought of long-haul travel to spend a week in a
      windowless room with a patchy WLAN fills me with enthusiam, an
      enthusiasm barely dampened by spending last week doing exactly that
      for standards work, where I took time to say nice things about
      SOAPBuilders and bad things about WS-I. (attached)

      The scary thing is that all the non-coding architects in all the
      working groups actually think that WS-I has solved interop; that the
      stacks have implemented it and everything is rosy. The results of the
      WSRF interop were less positive, pointing out that xsd:dateTime is
      still a source of extreme misunderstanding.

      At the same time, F2Fs can be good. I note that ApacheCon Europe 2006
      has just been announced: "ApacheCon Europe 2006 will be held in
      Dublin, Ireland, at the Burlington Hotel, June 26-30." this will no
      doubt be preceeded by a hackathon in which apache projects get worked
      on; there is nothing to stop us doing an interop session in the
      corner. For those who have not attended an apachecon, they have a bit
      of a developer flavour, but as they serve alcohol from the 10am break
      (at least in Germany), its not too dull. There will no doubt be a big
      axis2 presence, but we would extend an open hand to all other dev
      teams, open or closed source. I could also put in for a talk "web
      service interop, where we are now", or a panel "next generation WS
      stacks" to tie everything together during the main conf.

      regardless of where or when, this would effectively constitute
      SOAPBuilders round 6, if I am not mistaken. Let's do longstanding and
      emergent troublespots

      -SOAP1.2

      -doc/lit. All of it. Let's echo xsd:any back; maybe have some
      equals(xsd:any,xsd:any) to see if two different representations of the
      same thing match.

      -WS-A. Addressing, mapping from WS-A address elements ina message to
      stack addresses., equality tests.

      -timezones in xsd:dateTime (echoing it doesnt verify the far end
      actually took it; we need something better like
      boolean equals(xsd:dateTime date, int year,
      int month,int day, int hour, int min, int s, int millis,
      long tzGmtOffsetMinutes)

      -Attachments in the many flavours (SwA, Dime, MTOM). Something to
      checksum the results to verify losslessness and correct understanding.

      -Faulting. All that fancy new SOAP1.2 stuff.

      -statefulness. So we can see that when an mustUnderstand header is
      rejected, a side-effecing far end has not actually been called.

      HTTP things:
      -multiple cookies in a response being repeated next time
      -error code handling
      -no attempt to parse the HTML response coming from an error page
      unless the content-type is correct (yes, we've all seen that one :)

      Oh, we could have so much fun. So many things have gone wrong out
      there since Round 5, things we can test for.

      -Steve
    • Simon Fell
      ok, here s your first bug report I send
      Message 2 of 20 , Feb 18, 2006
      • 0 Attachment
        ok, here's your first bug report

        I send
        <S:Envelope

        xmlns:b="http://schemas.datacontract.org/2004/07/XwsInterop.SoapWsdl.ComplexDataTypes.XmlFormatter.Service.Indigo"
        xmlns:S="http://schemas.xmlsoap.org/soap/envelope/"
        xmlns:a="http://tempuri.org/"
        xmlns:XS="http://www.w3.org/2001/XMLSchema"
        xmlns:XI="http://www.w3.org/2001/XMLSchema-instance">
        <S:Body><a:inStructSN>
        <b:Age XI:type="XS:short">12</b:Age>
        <b:ID XI:type="XS:short">12</b:ID>
        <b:Male XI:type="XS:boolean">true</b:Male>
        </a:inStructSN></S:Body></S:Envelope>

        but i get back

        <s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
        <s:Body><RetStructSNResult xmlns="http://tempuri.org/"
        xmlns:i="http://www.w3.org/2001/XMLSchema-instance">
        <Age
        xmlns="http://schemas.datacontract.org/2004/07/XwsInterop.SoapWsdl.ComplexDataTypes.XmlFormatter.Service.Indigo">12</Age>
        <ID
        xmlns="http://schemas.datacontract.org/2004/07/XwsInterop.SoapWsdl.ComplexDataTypes.XmlFormatter.Service.Indigo">12</ID>
        <Male
        xmlns="http://schemas.datacontract.org/2004/07/XwsInterop.SoapWsdl.ComplexDataTypes.XmlFormatter.Service.Indigo">true</Male>
        <Name i:nil="true"
        xmlns="http://schemas.datacontract.org/2004/07/XwsInterop.SoapWsdl.ComplexDataTypes.XmlFormatter.Service.Indigo"/>
        </RetStructSNResult></s:Body></s:Envelope>

        Notice that I got Name back as i:nil='true' even though I didn't send
        it (it is declared as minOccurs='0'). Would appear that Indigo can't
        distinguish the different between nil and not occur (which is
        important for doc/lit, but not rpc/enc).

        BTW, any plans to fix up the bloat caused by all the re declarations
        of the namespace ?

        Cheers
        Simon
        www.pocketsoap.com

        On Sat, 18 Feb 2006 11:36:35 -0800, in ws you wrote:

        >If you look closer at http://mssoapinterop.org/ilab/
        >
        >I think you will find more of the application level interop test
        >endpoints there
        >http://131.107.72.15/SoapWsdl%5FComplexDataTypes%5FXmlFormatter%5FServic
        >e%5FIndigo/
        >http://131.107.72.15/SoapWsdl%5FBaseDataTypes%5FXmlFormatter%5FService%5
        >FIndigo/
        >
        >We and other attendees care a lot about testing schema interop at the
        >WCF plug-fests.
        >
        >-----Original Message-----
        >From: soapbuilders@yahoogroups.com [mailto:soapbuilders@yahoogroups.com]
        >On Behalf Of Simon Fell
        >Sent: Saturday, February 18, 2006 10:55 AM
        >To: soapbuilders@yahoogroups.com
        >Subject: Re: [soapbuilders] whatever happened to interop testing
        >
        >On Fri, 17 Feb 2006 08:16:27 -0800, in ws you wrote:
        >
        >>Steve,
        >>I think there are plenty of interop endpoints from every vendor that
        >>folks test against.
        >>
        >>Here are those from MSFT (WCF): http://mssoapinterop.org/ilab/ . The
        >>next WCF plug-fest is March 7-9th.
        >
        >What about people that want to test interop at the body level (or
        >data-binding level if you will) ? When the WS-I killed off
        >soapbuilders, that got lost.
        >
        >I'm sure the people that care about WS-Tx are happy there's interop
        >testing for that, but you know that the basics are still flaky (I see
        >this everyday in my day job, don't try to tell me that the basic
        >interop story is all rosey), if the different endpoints can't agree on
        >what minOccurs='0' means in the payload schema, its all for nought.
        >
        >Cheers
        >Simon
        >
        >
        >-----------------------------------------------------------------
        >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
        >
        >
        >
        >
        >
      • Steve Loughran
        ... I am now at the point in my soap stack works, and where I have some intra-operability between Axis1+Muse for WSA/WSRF support, enough to meet my short term
        Message 3 of 20 , Apr 25, 2006
        • 0 Attachment
          On 2/18/06, Steve Loughran <steve.loughran.soapbuilders@...> wrote:

          > At the same time, F2Fs can be good. I note that ApacheCon Europe 2006
          > has just been announced: "ApacheCon Europe 2006 will be held in
          > Dublin, Ireland, at the Burlington Hotel, June 26-30." this will no
          > doubt be preceeded by a hackathon in which apache projects get worked
          > on; there is nothing to stop us doing an interop session in the
          > corner. For those who have not attended an apachecon, they have a bit
          > of a developer flavour, but as they serve alcohol from the 10am break
          > (at least in Germany), its not too dull. There will no doubt be a big
          > axis2 presence, but we would extend an open hand to all other dev
          > teams, open or closed source. I could also put in for a talk "web
          > service interop, where we are now", or a panel "next generation WS
          > stacks" to tie everything together during the main conf.
          >
          > regardless of where or when, this would effectively constitute
          > SOAPBuilders round 6, if I am not mistaken. Let's do longstanding and
          > emergent troublespots
          >
          > -SOAP1.2
          >
          > -doc/lit. All of it. Let's echo xsd:any back; maybe have some
          > equals(xsd:any,xsd:any) to see if two different representations of the
          > same thing match.
          >
          > -WS-A. Addressing, mapping from WS-A address elements ina message to
          > stack addresses., equality tests.
          >
          > -timezones in xsd:dateTime (echoing it doesnt verify the far end
          > actually took it; we need something better like
          > boolean equals(xsd:dateTime date, int year,
          > int month,int day, int hour, int min, int s, int millis,
          > long tzGmtOffsetMinutes)
          >
          > -Attachments in the many flavours (SwA, Dime, MTOM). Something to
          > checksum the results to verify losslessness and correct understanding.
          >
          > -Faulting. All that fancy new SOAP1.2 stuff.
          >
          > -statefulness. So we can see that when an mustUnderstand header is
          > rejected, a side-effecing far end has not actually been called.
          >
          > HTTP things:
          > -multiple cookies in a response being repeated next time
          > -error code handling
          > -no attempt to parse the HTML response coming from an error page
          > unless the content-type is correct (yes, we've all seen that one :)
          >
          > Oh, we could have so much fun. So many things have gone wrong out
          > there since Round 5, things we can test for.
          >
          > -Steve

          I am now at the point in my soap stack works, and where I have some
          intra-operability between Axis1+Muse for WSA/WSRF support, enough to
          meet my short term goals. The WCF endpoints for simple types, faults
          and the many, many versions of WSA out there.

          ApacheCon Europe is coming up (http://www.eu.apachecon.com/), and
          there will presumably be Axis developers as well as myself. If anyone
          else is interested in getting together for some interop testing and
          fixing then we could do it on the monday/tuesday of the week, at the
          invitation-only hackathon part of the conference.

          Question is: what are we going to test? what will SOAPBuilders round
          six consist of?

          I propose the following test areas

          -HTTP: bits and bobs underneath the SOAP layer
          -SOAP12: envelope, MU headers, faults
          -WSA1.0 (how much is optional here?)
          -doc/lit XSD

          In particular, I want endpoints to generate interesting failures.
          endpoints that return text/html to a POST, or return HTML content
          after a text+xml header. soapfaults with big complex datasets coming
          back, endpoints that return stack traces in the Axis1 namespace, etc,
          etc. The kind of thing you get out there, even if you dont want to see
          them.

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