Simon Fell > Its just code > April 2005

In More on Contract-First Web Service Design Dare responds to a post from Aaron, skipping to the bottom of Dare's post, I hope he remembers that the #1 interop killer is that in .NET 1.1 value types can't be null when he's doing his code first design. Dare goes onto say " With these guidelines our developers can build XML Web Service applications in a 'code first' manner yet have a high degree of confidence that the services we build will be interoperable across various toolkits." Surely someone with deep knowledge of XSD & WSDL put these guidelines together, no? Perhaps that WS-I profile for XSD is good thing after all

MS & Co have submitted WS-RM to OASIS, Is this going to get merged with the existing OASIS work on reliable messaging (which already has a standardized v1.1 spec for WS-Reliability, get handled as something else, I don't really see how this is going to move forward.

Is out now includes the ability to generate a trace file that contains the entire request/response, which is useful for diagnosing SSL issues, and Chris Vigelius added support for making the request body an IStream and the ability to get an IStream for a disk file, makes upload large files easy, thanks Chris!

The connect problem turns out to be a "feature" of the socket proxy in ActiveSync, it will always connect, and some subsequent request to read/write will fail. Calling select before every write to check for writable will detect this condition. This workaround will be in the next release of PocketHTTP, which I'm hoping to get out this weekend.

After seeing Russell rave about Ubuntu I grabbed a copy of the live CD and tried it out on my Sony laptop, I figured that would stretch its legs, but it handled it fine, the display came up at the right rez, the wireless networking worked fine as did the sounds, color me impressed. I see Sam had a similar experience with his T40. Now I'm torn, do I goto Ubuntu, or get that Mac Mini I was thinking about ? Ubuntu is certainly the slickest trouble free Linux distro I've seen yet.

I worked around the previous problem with Indigo and Sforce and continued my exploration, and I now have the distinct impression that everyone who's trying Indigo out is doing Indigo -> Indigo testing, because well frankly for anything else it appears be fairly broken.

• element order in serialized request does not match WSDL
• generated SOAPAction header does not match WSDL
• Get an exception while de-serializing a soap fault
• the generated proxy for operations that are maxOccurs="unbound" don't generate an array in the generated xxx_RequestMessage object
• endpoint URL is in WSDL but doesn't end up in the generated proxy anywhere
• can't create a proxy with a HTTPS url

In addition I see my favorite compliant from ASMX is now in Indigo as well, I really really really hope they do something about this, it seems ridiculous to hobble Indigo with all the AMSX v1.0 decisions. I also hope that Don & Co's work on the programming model just hasn't made it to the client end yet, because it seems pretty yucky so far. (I know this is all early access beta, I just some feedback will make a difference), e.g. here's a call to Login, that dumps the resulting sessionId and serverUrl to the console

SoapProxy proxy = new SoapProxy(new EndpointAddress("http://www.salesforce.com/services/Soap/c/5.0"), new BasicProfileBinding());
login_RequestMessage loginMsg = new login_RequestMessage();
loginMsg.username = "test@test.com";
loginMsg.password = "hahahahaha";
login_ResponseMessage lr = proxy.login(loginMsg);
LoginResult res = lr.result;
Console.WriteLine(res.serverUrl);
Console.WriteLine(res.sessionId);

Compare this with .NET 1.1, note that in this case the programmer doesn't need to manually extract the endpoint URL from the WSDL and put it in his code

sforce.SforceService svc = new sforce.SforceService();
sforce.LoginResult lr = svc.login(username, password);
Console.WriteLine(lr.serverUrl);
Console.WriteLine(lr.sessionId);

All the above bugs meant i couldn't actually test much further than this, but it appears that the client is going to be responsible for hanging onto the header state (such as the SessionHeader) between each call and set it on every RequestMessage instance before calling the proxy. Perhaps I'm just doing something wrong, but I couldn't find much docs on using Indigo to call other non Indigo services. The wsdl was processed with svcutil /uxs /tm enterprise.wsdl which seems to be the only way it'll handle the sforce WSDL.

I finally got some time to get the CTP of Indigo installed, and wanted to try it out with the Sforce API. Unfortunately I didn't get any further than trying to process the WSDL, svcutil.exe incorrectly barfs on it with
Error: Cannot import invalid schemas. Compilation on the XmlSchemaSet failed The Enumeration constraining facet is invalid - The value 'fns:API_CURRENTLY_DISABLED' is invalid according to its datatype 'QName' - 'fns' is an undeclared namespace.
Yet the fns prefix is clearly defined on the root element of the WSDL doc, I logged a bug, i bet the schema parser is taking into account all the inscope namespaces from outside of the schema element. I wonder how much interop testing they've done on Indigo ?, perhaps MS should add Sforce to thier basic test suite, I found some bugs in the earlier Whidbey builds with the Sforce WSDL as well (which is WS-I BP 1.1 compiant).

Just a reminder that PocketSOAP correctly implements the RFC 2376 rules on handling the text/xml content-type (meaning its important to have the right charset attribute on the content-type header). Where as .NET's web services client engine has a bug in that it completly ignores this. If you're using a proxy which re-encodes the body, this becomes important. If you have a buggy server that doesn't include a charset attribute, this is likely why you're getting parser errors from PocketSOAP.

I'm happy to announce that the SForce team blog is now up and running, I'll be doing most of my SForce related blogging there, see you on the other side!

Yesterday was IntegrationForce day, amongst the numerous announcements was the one for support for single sign on, a feature I spent many a hour working on. I really like its open ended design, it can support authentication against LDAP or ActiveDirectory, use SAML or binary tokens (like a Kerberos ticket), you can even support things like RSA's securId. The IT guys should love it, one less thing to provision and de-provision users on.

More details on my problems with the connect winsock API call on pocketPC's

I've noticed that the winsock connect call never seems to fail, even if there's nothing listening on the remote server/port. The exact same code running on winXP gives a failure during the connect call. I have a small re-pro case. All it does is resolve a host name, construct a sockaddr_in and call connect. on WinXP this fails when there's nothing listening at that address. On both PocketPC 2002 and PocketPC 2003 with ActiveSync 3.8 the connect call will always succeed and later calls to send or recv will fail. With the attached code, it always gets down to the "unable to read data" error. On other tests that send much larger quantities of data before they read anything one of the calls to send will eventually block for ever (i think waiting for some buffer to empty, but it never does).

The PocketPC2003 device is a Toshiba e355 running wince 4.20.1081

The PocketPC2002 device is a compaq iPaq 3650 running wince 3.0.11171

both are connected via the cradle USB connection to a WinXP desktop running activeSync 3.8 I've also re-pro'd it with the iPaq to a WinXP machine running activeSync 3.6