Re: [soapbuilders] whatever happened to interop testing
- On 2/18/06, Steve Loughran <steve.loughran.soapbuilders@...> wrote:
> At the same time, F2Fs can be good. I note that ApacheCon Europe 2006I am now at the point in my soap stack works, and where I have some
> 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
> -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.
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?)
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