Visual FoxPro Web Services Revisited

Web services with Visual FoxPro (VFP) have never been easy. The most common Web service tool for FoxPro is the SOAP Toolkit, which has been discontinued and which had a host of problems when dealing with complex types passed over Web Services. In this article I’ll show how you can leverage the powerful Web service features of .NET and the new Windows Communication Foundation in your FoxPro application through COM Interop.

Today more and more applications interact and communicate via Web services either as clients or as publishers. It’s becoming quite common for many application development scenarios to include Web service functionality as an integral part of the development process. The good news is that Web service technology has stabilized and today interoperability is much better. It’s much easier to call a Java Web service from .NET or Visual FoxPro than it was in the early days of constantly moving standards and incompatible Web service platform implementations. Over time Web services have also become more complex, especially in regards to the data that is sent over the wire. It’s very common today to have Web services that send complex messages that contain many nested types of information in single messages.

The State of FoxPro Web Services

For Visual FoxPro developers, dealing with complex Web services has always been problematic because the default tool that is natively available through COM-the SOAP Toolkit-is limited. Whether you’re building or consuming Web services in Visual FoxPro, your first stop likely takes you to the Soap Toolkit. Visual FoxPro ships and installs this COM-based tool. FoxPro’s internal Web service client and server Wizards both rely on it to publish and consume Web services. The SOAP Toolkit is a pretty crude tool by today’s standards-it provides only the bare basics of Web service interoperability and can’t easily deal with Web services that need to consume complex types or need to use extended Web service protocols like the WS-* Web service specifications.

If you’re using the SOAP Toolkit to consume Web services that are returning anything but simple type values you will quickly find that it’s pretty tedious to deal with the data that is returned, as you end up having to parse the XML messages on your own. Alternately you can also resort to implementing convoluted type interfaces using the SOAP Toolkit’s extension interfaces that allow mapping of classes. However, this process is almost more work than parsing the XML data. In my experience this lack of support for complex types is a major stumbling block as almost all Web services that are published by providers commercially are based on complex message types using objects, arrays or collections, and enumerations, none of which are handled natively by the SOAP Toolkit.

For publishing Web services the SOAP Toolkit fares no better-it provides the ability to use either an ASP or ISAPI listener to publish COM objects as Web services. Although Visual FoxPro’s Web service Wizard does a decent job of publishing simple Web services, the services published are limited in that you can’t easily publish anything but simple types from your exposed service methods. Add to that some limitations in Visual FoxPro to expose nested types to COM and it becomes very difficult to publish any content that requires anything but single hierarchy objects. This may be workable in simple scenarios or in FoxPro-to-FoxPro calling scenarios where you can often use raw XML strings to pass data across applications, but for many Web service and Service Oriented Architecture (SOA) scenarios that need to interact with non-FoxPro applications, this limited functionality is not adequate.

The last straw for the SOAP Toolkit, however, is the fact that it is no longer officially updated or supported by Microsoft. All new development on it has stopped so there won’t be any future improvements or bug fixes (other than critical hotfixes for security), so it won’t keep up with the latest standards should they change.

This makes the SOAP Toolkit a somewhat volatile solution, especially if you are interoperating with Web services from the Java and .NET platforms, which are constantly changing and updating to the latest standards. Currently the SOAP Toolkit is still in line with the latest SOAP 1.2 specification, but it doesn’t deal with any of the WS-* specifications or any of the upcoming SOAP 2.0 specifications.

By: Rick Strahl

Rick Strahl is president of West Wind Technologies in Maui, Hawaii. The company specializes in Web and distributed application development and tools, with focus on Windows Server Products, .NET, Visual Studio, and Visual FoxPro. Rick is the author of West Wind Web Connection, West Wind Web Store, and West Wind HTML Help Builder. He’s also a C# MVP, a frequent contributor to magazines and books, a frequent speaker at international developer conferences, and the co-publisher of CoDe Magazine. For more information please visit his Web site at www.west-wind.com or contact Rick at rstrahl@west-wind.com.

rstrahl@west-wind.com