Simon Fell > Its just code > May 2004
I've been spending some time recently working more with the .NET 1.1 SOAP stack and with Axis 1.1, it was a brutal reminder of how big a difference there is between (a) the current tools, (b) current best practice (e.g. WS-I BP) and (c) the WS-* stack of specs. Both tools (and the rest I imagine, PocketSOAP certainly not excluded) have their pain points, .NET's use of public fields in classes rather than properties is a PIA when it comes to data binding and an even bigger PIA with the additional XXXXspecified properties, which you need to remember to set when sending them out of the client, otherwise your XXX value is going nowhere. [tell me this is fixed in Whidbey, right ? (still fighting to get a working Whidbey install)]. Axis, which does a much better job at that part, has some real strange header handling, the WSDL documents which headers are valid for which operation, but once you've set a header, Axis will just blindly send it on every subsequent request. So you're left to remove the header yourself on the operations that shouldn't send it, but dang!, there's no direct way to remove a header, you have to grab all the current headers, call clearheaders, then add them all back in, minus the one you wanted to remove. urrrgghhh. And to top it off, when faced with the task of generating a server side stub from WSDL, they both end up generating code that doesn't work. (how exactly did wsdl.exe /server make it out unfixed in 2 releases of .NET ?)
Brad is looking to go dual DVI, a move I made earlier this year, the trick (if you're using the FP2001's), is not to find a dual DVI card, but a dual DVI card that will drive both outputs at 1600x1200, a number of the gaming centric cards I looked at wouldn't do dual DVI at that res, and I settled on the Matrox P750 card, which I've been happy with, but judging by the reviews, its not a card for gamers (can't remember the last time I played a PC game).
Anyone have a list of toolkits offering WSI BP conformance ?, I'm surprised there isn't a list on the WS-I site. As the BP seems to largely be a rubber stamp of what the MS tools do, I'm assuming that you can use .NET to build BP compatible tools, what about other toolsets, any of the Java tools there yet ?
One re-occuring theme I see various WSDL's is that they are designed so that the generated proxy in tool X is easy to use, and not what makes the most sense on the wire. This is such a broken way of doing things that I don't know where to start, but lets start with this.
- For doc/literal SOAP services there is no standard for what the programming model for the generated client is, therefore what works well in tool X may be completely different in tool Y.
- Programming models are going to evolve, what looks good today maybe a complete lemon with next years tools
- The whole point of doc/literal web services is that the wire format is king, and how they map to environment Z is irrelivant.
SOAP Headers are a good example of where tools differ, Axis and .NET are similar in concept, but (with v1.1 Axis at least) are way more manual and complicated and non-obivous in Axis. In either case I personally don't like the "set the headers at the proxy class instance level" that both these tools use, and if you use the PocketSOAP WSDL Wizard, it will generate parameters in the operation method call to pass the headers in, making it way more obvious which headers are valid for which operations.
I just wrapped up a tutorial that shows how to use PocketSOAP and the WSDL Wizard to access SForce. It contains a short explanation of the programming model that the WSDL wizard generates for doc/literal services, which as its different to the typically programming model that other tools expose, is worth a look at if you're doing doc/literal with the WSDL wizard generated code.
I just released an updated WSDL Wizard which has a couple of bug fixes and improvements to the generated code for doc/literal services.
If you use PocketSOAP, then I'm interested in which platforms & features you use, head over to the mailing list and do the survey, thanks !
If any of the MSDN folks are reading, The Integrating Web Services and COM Components article listed in the RSS feed and here, just drops you back at the WS dev center home page.