Simon Fell > Its just code > October 2004

Continuing to make slow but steady progress on the new WSDL Wizard which will generate C++ code in addition to VB. Just working on the last details of generating the deserializers for complex types and I think it'll be ready for an alpha release. The code is all in CVS if anyone is interested in checking it out, or even helping out.

Brad Evans has an IBlogExtension implementation for PWAIN .

dreamforce is rapidly approaching, I'll actually be speaking in 2 of the developer track sessions, in the Tips and Tricks of the sforce Masters session I'll be talking about our new Single Sign On infrastructure. I'll also be in the Meet the Developers where you'll get to barrage myself and the other sforce folks with questions.

The whirlwind trip to the devcon is over, as always Chris & Co put on an excellent gig, The location & services were great (with the exception of the complete lack of meal choices for the veggies). I thoroughly enjoyed it, the mix of vendor dev talks, end user dev talks and the extremely smart attendees makes for an interesting time, was great to hear from all the people that came and told me how tcpTrace or YATT or PocketSOAP had made their lives easier, always good to hear. DougP gave a very entertaining talk on web services versioning, one the major reasons i was at the conference, which turned out to be a bitter sweet result for me, I was happy that they'd come to the same conclusion i already had, but disappointed that it really is going to be that much of a hack to get it to work. Perhaps hack isn't the right word, more messy, whatever you call it, its a solution i don't like, but looks like the best that can be done. I also got to have a great chat with ChrisAn about extensibility differences between the class libraries in Java and .NET. (amongst other things)

Trying to get organized for the xml devcon trip, just making sure the blogging config on the laptop is working.

Its been a long time coming but the final release of PocketSOAP v1.5 is now available, new features and improvements include

• SOAP 1.2 support.
• Reduced memory footprint during serialization & messaging sending/receiving.
• Streaming parsing of the response soap envelope.
• Support for gzip in addition to deflate compression.
• Improved performance of base64 handling.
• upgraded to zlib 1.2.1 for improved compression performance.
• zlib & expat dependencies are now statically linked for easier deployment and less dll hell.
• A bunch of bug fixes.

WoooHooo, the best news i got all day, Tags Trance Trip is back, at a new home on SomaFM :)

I'm in the final process of wrapping up the docs for the 1.5 release of PocketSOAP, so if you've seen bugs in the 1.5 beta 2 now would be a really good time to point them out.

Glen has a write up on the WS-Beers get together last night, was a lot of fun, some very interesting discussions. One issue that Glen raised, and I totally agree with is when you decide to dump a toolkit and just generate/parse the xml yourself, you must remember to perform the soap processing model rules, Scott Hanselman conveniently posted an example today that skips that step, remember to check for those mustUnderstand headers kids.

One more can't possibly hurt, right ?

Matt Powell has a big hullabaloo about DIME and SwA only being a w3c note and people should stop moaning about the poor support etc for them. Errr, hello, earth to Matt, SOAP 1.1 and WSDL 1.1 are also only W3C notes. Microsoft are largely responsible for the current mess in soap attachments, first they backed SwA, no wait, use DIME instead that's much better, no wait, we were just kidding, MTOM is the king really. As I see it, Matt and Co are the last folks should be complaining about the treatment they're getting, I think they're getting off way too light.

Given the large number of previous incidents in IIS and related technologies for URL / path canonicalization issues, I'm surprised to see that one creeped into ASP.NET

MSDN has a new section on WS interop, the primary content of which seems to be documents on getting .NET to interop with X, whilst this is great info to have, to me it also signals what is wrong with WS-* today, despite the WS-I and other efforts, interop today is no better than it was 2 years ago, we're still at the N x N-1 efforts for interop, but when we have 10, 50, 100 soap toolkits, that just doesn't scale. I spend a whole bunch of time checking interop between various toolkits and service, and even the simple stuff runs into trouble.

As Tim points out, everyone is out writing specs and building new plumbing for WS-* but the basic tools are still not that great, .NET is great example of this, WSE adds all sorts of additional functionality for WS-Security, WS-Policy, WS-KitchenSink, yet the core XmlSerializer has broken support for simple things like minOccurs='0', its 'clever' ability to roll up elements that contain only a repeating element in an array (and removing one of the nesting levels that's in the doc), is not quite smart enough in some cases, and I've seen it trip itself up, generating proxy code which just doesn't work. (I'm waiting for a new .NET 2.0 beta to see if this is fixed). Other environments fair no better, Java has a multiple of toolkit offers, yet on more than one occasion I've seriously considering writing my own doc/lit SOAP engine for Java.

If you're doing any development work with the SForce API's, a lot of people experienced with the API's and popular tools hang out on the SForce Community Forums, both Salesforce.com folks and end users. See you there.

This one has come up on the axis-users mailing list a few times recently, and as my views seem to differ from other views there, I thought I'd throw mine out here to a wider audience. A SOAP Fault consists of a fault code QName, a faultstring and a detail element which can contain arbitrary namespaced xml. JAX-RPC likes to have you map java exceptions to structures in the detail element, whilst I'm not entirely against that, I am against using it while ignore the standard stuff, its not uncommon to see soap faults like this (envelope stuff ignored for clarity).

<faultCode>soap:Server</faultCode>
<faultString />
<detail>
 <j:someException>
  <j:exeception>invalidDate</j:exception>
  <j:message>i don't like mondays</j:message>
 </j:someException>
</detail>

uggghhh, it works, but to me its pretty hideous, if your toolkit of choice doesn't support the fault elements in WSDL and/or map the faults back to exceptions (say .NET for example), as a client programmer your left with the job of grunging around in the detail element XmlNode to get the error info, now compare it to this one.

<faultCode>j:invalidDate</faultCode>
<faultString>i don't like mondays</faultString>

Contains exactly the same amount of useful information but with the added bonus that every toolkit I've looked at will make it easy to access this info.