What a week this has been. Monday I was asked to write a zip code proximity calculator for one of our products we agreed on using an existing web service to do the calculations and store them in our local database then our application would just query the database for that and would never have to call the webservice again neat eh well so since we wanted to do this quick I decided to make the call from perl. Perl has a soap package called SOAP::Lite so after googling a bit I went on to create a client that consumed this webservice and got no results hmm something is wrong here after looking at the SOAP request/response messages I found out that the web service doesnt like the SOAP envelope and complained about soap version mismatch cant do much tried searching on the forums groups nothing thats when I decided ok lets switch to python so wrote a 3 line client :) to test against some other webservice and guess what it worked so theres hope so then I queried the webservice that I wanted to use and it failed damn pythons SOAPpy package failed to create proxies for the webservice and died something is very wrong either its me or the webservice. So let me reveal to you the webservice if you still havent guessed this was a webservice written in ASP.NET so much for interoperability all lies!!!. SOAP an xml based technology that the Redmond folks have been trying to push so hard and I have no problems I like the idea of transporting xml programs talking to each other independent of architecture or language but if two client libraries cant communicate with a webservice then its just bad I had one other option go for PHP and try NuSOAP but all my hopes were down when both Perl and python failed but since I had to show some result to my supervisors I wrote a small client program in what else... C# yes giving the ASP.net webservice a taste of its own medicine this should work otherwise this whole SOAP thing with Microsoft would be laughable. And it worked woo hoo finally I got a response but wait this doesnt end here what the heck is the webservice returning a DataSet according to the wsdl schema it should return rows of data with columns containing the info but what the heck is a DataSet. DataSet is an ADO.NET class that you can use to automatically render it to a grid view neat but what if I wanted plain results just a class containing the properties but the designer of the webservice had other plans since my idea was to just put this data on the database I had no interest in rendering it but now I have a DataSet so I had to live it. Mind you I am not really familiar with C# or the net framework these days the last C# code I wrote was in early 2005 I am sure things must have changed. On further research I found out how to retrieve the values from the DataSet. Heres are the algorithmic steps.
1. Iterate through table objects present in DataSet
2. On each table iterate through all rows
3. For each row determine the column info
4. Pass column name to row to retrieve value
Simple aint it. This is overkill too much object orientation is a dangerous thing and this is precisely what the developer of this webservice had in mind. However, we ended up not using this webservice at all since the server this webservice is hosted is not so good and at times would return null responses something that we really wouldnt want I had to search for 38,000 zip codes and I was only able to get data for 3 zip codes within a span of 1 hour just poor.
Sorry for being too anti .net but this is what I have observed I have used .net webservices before and always had problems with it maybe its luck other webservices from other platform seem to do quite well. You cant have interoperability with this Both perl and python failed.
Oh and btw REST is another emerging framework for web services they are trying to correct the things where SOAP messed up.
finally, after a couple of bad days with SOAP I ended up writing a proximity algorithm on my own.
Labels: .net, ASP.NET, C#, perl, php, python, REST, SOAP, webservices, zip code proximity
