Building and using SOAP Web Services with Visual FoxPro

Session Overview

Imagine that you need some specific information in your application such as a shipping rate calculator. You now go to a service search engine and look up availability for the type of service you need in a standard manner over the Web. Now imagine that you can get at this information easily and simply plug the info directly into your application. Sound too good to be true? Believe it or not the technological pieces to make this type of functionality possible are available today. Web Services promise to make this type of functionality a reality by bringing the same interlinked mechanisms that have made the Web so popular for Web browsing to application development by sharing data over the Web using standard formats. Web Services have become the new industry buzzword. Microsoft is talking about Web Services as the second life of the Internet that will tie together applications the same way that the Web Browser and URL based links have tied together HTML based Web pages. The Web at your Service is a new mantra rising. In this article Rick discusses what SOAP and Web Services and demonstrates the MS SOAP Toolkit and a more flexible VFP based implementation called wwSOAP. He then delves into creating a sample Web Service and calling and integrating it into an application. 

 

Web Services promise to bring the same kind of interlinked functionality that hyperlinks brought to the browser experience to application development.

The move to distributed application development is a natural evolution for the Web. It gets back to the roots of how data is used in applications in general. With HTML the focus has always been on presentation with data bound directly into the presentation. On the other hand the focus in distributed applications is on totally separating the display and the data delivery. XML has become the preferred way to provide the data to client applications. To date XML has rapidly gained ground as a messaging format that serves as an intermediary between the data and the consuming client application – XML is typically converted from some native data format like a database table or an object and then used as the transfer mechanism. The client then has the choice of consuming that data directly through the XMLDOM or by converting it back into a native format such as a table or object that maps the XML. In the latter scenario XML is primarily used as a persistence format to transfer a state from the server to client or vice versa. In order to do this, all you need is an XML parser and a mechanism for pushing the XML over the wire via HTTP.

SOAP and Web Services don't change this model in any way. Instead SOAP standardizes it for the purpose of making remote calls on object methods or functions (such as script page calls) more natural. In custom XML applications the application – both client and server – have to know what the message format is beforehand which results in some amount of coupling between the client and the server. By providing a standard mechanism for representing the procedure call interface and a mechanism for querying what functionality is available and what the signature of each call is, SOAP can abstract away the explicit XML conversions that occur in custom XML implementations. To make this process truly seamless some services or tools must be in place that can provide the SOAP XML packaging and unpackaging and perform the wire transfer operations. The current flock of tools is not there yet, although as we'll see in a minute it only takes a few lines of code to make a remote procedure call in this fashion.

SOAP is not a replacement for DCOM or CORBA

It's important to understand that SOAP is not to be considered as COM over the Web. For one, the server handling a SOAP request does not need to use COM to return a result. In fact results can be generated through simple ASP script code that never calls a COM object providing a sort of remote scripting. You can also use VFP code which may or may not sit in a COM object. It can be Java code or an ASP+ Web service in Visual Studio 7. The implementation and the tool of implementation is up to the developer and independent of the SOAP spec.

There is a significant difference between what COM provides and what SOAP does. SOAP is only a protocol that mandates how a method call transfers over the wire. More importantly, SOAP caters only to single function or method invocations, which means you can't maintain state to an object between calls. With SOAP, the client makes single method or function calls, one per HTTP request. The SOAP model follows standard Web and distributed application fare: Stateless transactions with disconnected data used to provide the client with the data needed to do its work. Get the data from the Web server in a method call, use the data offline locally, the send the updated data back to the server in another stateless remote call.

This is very different from DCOM or CORBA where a client creates a persistent connection to the object to perform multiple property accesses and method calls. DCOM and CORBA both support stateful remote connections – SOAP typically does not (although it's conceivable this could be implemented with server side state management of an application, something that's usually to be avoided in distributed applications).

The SOAP concept is simple: If a single wire format is used to call a function or object method on the server, the server doesn't care what type of client the call is being made from. So you could be calling with the Microsoft SOAP Toolkit from a Windows 2000 machine, or you could be calling from an IBM Java SOAP implementation running on a Linux box. The server can run ASP script code, a COM object, or run a Java Servlet on Linux – as long as the data traveling over the wire matches the SOAP spec they all can talk to each other. The server doesn't care and services the request as needed and simply returns a SOAP compliant result package.

Implementations vary however, with Microsoft's implementation using an intermediary SDL file that acts as a sort of remote type library for the Web service. This concept is not supported by other implementations such as the one from IBM. But because the Microsoft packager still outputs a plain SOAP package in the end it can call an IBM implementation on the server or talk to an IBM client.

What all this means is that SOAP is vendor independent and the spec has been submitted for standard status. Several large players besides Microsoft have added support including IBM, but some big players like Sun, Oracle and Netscape (surprise, surprise, eh?) are not on board as of yet. Third party and free tools are available for those platforms however.

What's a Web Service?

Over the last few issues I've discussed using XML in a distributed messaging architecture. The basic concept in these scenarios is using the HTTP protocol to communicate between client and server and passing data in XML format over the wire. This mechanism works really well for custom applications that follow a standard format and where both sides know and agree on the message format (the XML structure, the URL to call etc.)

Web Services are based on the same concepts and technologies, but extend this mechanism by providing a standard interface as to how the server side Web Service is called. This interface comes in the form of the Simple Object Access Protocol or SOAP. SOAP's mission in life is to provide a standard, XML based interface to making remote procedure calls. The purpose of SOAP is to standardize the way that data is requested and remote code is executed by providing standard parameter information (input) and return value (output) that returned in an XML document that follow the SOAP protocol specification. A server SOAP implementation is required to handle incoming SOAP requests. This implementation can be implemented with any Web Backend. MS SOAP uses ASP, Web Connection uses a special process class to handle SOAP requests to a specific Web scriptmap. Keep in mind that the server implementation is independent of the SOAP spec. As long as it can read the incoming SOAP Request packet and return a valid SOAP Response packet it's fulfilling the SOAP contract.

In simplistic terms the idea behind a Web Service and SOAP is nothing more than making a remote function call over the Internet. The client passes a parameter, the server returns a result value. It's not quite that easy yet, but we can look forward to full development tool integration of SOAP and Web Services that literally will blur the lines between where code is executed, whether it's in you own compiled application or from a service sitting on the other side of the globe with a 12 hour time difference.

Why bother since XML is already here?

If you're already building XML based applications you may be asking yourself just about now what is so different about using SOAP compared to using standard XML messages? There are many reasons why SOAP has advantages over raw XML as a protocol, but here are the two most important ones:

• Simplicity
  The idea behind SOAP is that tools exist to facilitate the process of creating SOAP messages easily. I'll show examples later in this article, but the basic idea is that client code should resemble the simplicity of making a simple function call – on another server. On the server side it means you can implement a Web Service by simply implementing a function or class method. The SOAP Web Service server manager and the SOAP client handle everything that happens in between – the XML packaging, unpackaging and transferring of the request over the wire via HTTP. In many cases this removes the requirement for needing to create XML manually at all. On the client it means writing only a few lines of code to access that remote Web Service code and not having to know how to package up XML and make an HTTP request.
  
• Standardization
  If you publish functionality via SOAP you open up your architecture to other clients that can call your code easily using any of the above mentioned SOAP clients. SOAP clients exist today for just about all major operating system platforms and development languages including Java, Perl and for Windows developers COM objects and custom implementations in various languages. Furthermore, you can publish an interface definition that describes the service and what functionality it provides which makes it possible to provide the same type of IntelliSense type functionality that is common for Windows development tools.

SOAP is still evolving as we speak, but tools that let you take advantage of it today are available. The most visible tool is Microsoft's SOAP Toolkit and I'll start discussion with this Microsoft offering before going on to demonstrate a VFP based implementation that is more flexible.

The Microsoft's SOAP Toolkit

In May Microosoft introduced the SOAP Toolkit, which has now been updated with a July release that fixes a few bugs and adds slightly improved HTTP support. It should be noted that the Microsoft SOAP toolkit is distributed as a demo application, rather than a fully supported product at this time. The toolkit is meant as a pre-runner to the Web Services that will be provided by the Visual Studio .Net platform and employ a similar although more seamless SOAP implementation for calling remote Web Services. Support is available only through a public newsgroup, which is fairly active and has had some good discussions on the implications on using the toolkit.

When Microsoft released the SOAP toolkit I was pleasantly surprised at what I found: The toolkit comes with heaps of documentation, full source code (yes, full source for the ROPE client DLL, the ISAPI listener and the ASP listener – each of these has a ton of useful pieces of code for developers), a Wizard that generates Service Descriptions (SDL) from COM objects and several useful and easy to follow examples. Getting started involves downloading and installing the SOAP toolkit. I highly suggest you read through the first section of the help file that explains how the toolkit is structured – I'll review the main points here, but the documentation is very useful and easy to follow and has a number of useful tips and insights. The trouble shooting section is also good – it helped me figure out a couple of assumptions I made when I started.

The Microsoft toolkit is a custom SOAP implementation. What this means is that the SOAP messages passing over the wire are SOAP protocol compliant, but that there are additional tools and operations that occur to verify method call signatures. In particular the toolkit uses a Service Description file in XML Schema format that describes what methods the Web Services exposes and how those methods should be called. You can think of the SDL (Service Description Language) file as a server side type library that both the client and the server use to validate the method call parameters and result values.

[ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ]