Martin Heller
Contributing Writer

Here be Dragons

analysis
Jul 25, 20072 mins

When I wrote about my Web Service Blues on July 11th, I had no idea that I'd still be singing them two weeks later. But I was. The short summary of the issue is that my unmanaged Microsoft Visual C++ Web service client couldn't parse the response from a Microsoft ASP.NET 2.0 Web service. Every day or two, I'd think of something that could be wrong, come up with a way to test my hypothesis, do the experiment

Every day or two, I’d think of something that could be wrong, come up with a way to test my hypothesis, do the experiment, and see yet another idea go down in flames. Maybe I was formatting the GUIDs incorrectly? We created another Web service call that took strings: ffft.

Maybe the response was malformed? SoapScope didn’t think so. And nothing we did to the Web service output changed a thing.

I combed the MSDN news groups. Were people writing C++ clients for Web services? As far as I could tell, yes. I searched the documentation: was there a known problem with C++ WSDL import or parsing? Not that I could tell. I tried porting the project from Visual Studio .NET 2003 to Visual Studio 2005, the same generation of tool used for the service: surely the situation would improve. Nope.

Finally, a query to the Microsoft C++ team, sent through an old friend, got me an answer. It wasn’t what I wanted to hear, but it freed us to pursue a RESTful API rather than an XML Web service API.

What you’re encountering is very likely by design. We stopped evolving the native Web services stack shortly after we released VS 2002 and now it is a deprecated part of the product (and removed for the 2008 release). Lots of functionality was added to SOAP, WSDL and the entire range of WS* standards after that time (in fact more than 10x the original feature set counting by pages of specs). However we have moved this code to CodePlex at https://www.codeplex.com/AtlServer.

If you have specific problems, the VC++ team has offered to be as helpful as they can, but they encouraged me to encourage you to try working with the sources of ATL Server first.

So there it is: if you want to write a Web service client using Microsoft technology, do it in managed code. Use the .NET Framework. Better yet, use the Windows Communication Foundation.

C++ programmers who insist on trying to make Web services work in native code, write this in your documentation: Here be Dragons.

Martin Heller

Martin Heller is a contributing writer at InfoWorld. Formerly a web and Windows programming consultant, he developed databases, software, and websites from his office in Andover, Massachusetts, from 1986 to 2010. From 2010 to August of 2012, Martin was vice president of technology and education at Alpha Software. From March 2013 to January 2014, he was chairman of Tubifi, maker of a cloud-based video editor, having previously served as CEO.

Martin is the author or co-author of nearly a dozen PC software packages and half a dozen Web applications. He is also the author of several books on Windows programming. As a consultant, Martin has worked with companies of all sizes to design, develop, improve, and/or debug Windows, web, and database applications, and has performed strategic business consulting for high-tech corporations ranging from tiny to Fortune 100 and from local to multinational.

Martin’s specialties include programming languages C++, Python, C#, JavaScript, and SQL, and databases PostgreSQL, MySQL, Microsoft SQL Server, Oracle Database, Google Cloud Spanner, CockroachDB, MongoDB, Cassandra, and Couchbase. He writes about software development, data management, analytics, AI, and machine learning, contributing technology analyses, explainers, how-to articles, and hands-on reviews of software development tools, data platforms, AI models, machine learning libraries, and much more.

More from this author