A collection of foxpro tutorials

Building and using a SOAP Web Service with Visual FoxPro and Web Connection

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 are and then delves into creating a sample Web Service and calling and integrating it into an application.

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 a contender in the field for remoting technologies like DCOM and CORBA. Unlike those technologies SOAP has the advantage of easily running over HTTP and avoiding the complex configuration and security administration issues that surround DCOM for example. Because SOAP uses HTTP it can take advantage of the HTTP features like encryption and authentication as well as having the benefit of going through the Enterprise firewall.

 t's important to understand though that SOAP is not meant to replace DCOM or CORBA in high performance environments. SOAP has a lot of overhead associated with it  compared to these lower level binary formats. HTTP is slower than native TCP/IP for example and the XML encoding required by the SOAP messages cause SOAP to be up to a 1000 times slower than a similar implemtation using DCOM (it depends on what type of SOAP server you use of course – if you build an ISAPI all C++ listener you probably get better numbers.

 t's important to remember that you should not think of SOAP as a Remote COM implementation. Although the MS SOAP implementation focuses on exposing COM objects as Web Services, that is just one way you can create a Web Service. SOAP is open and does not specify how a Web Service must be implemented, so you can implement a SOAP Web Service with a function in script code in ASP, a visual FoxPro class, JSP class or a COM object run through the SDL Wizard.

 What makes SOAP so nice is that it's relatively simple protocol that's easy to implement and work with and building a custom SOAP server that can handle requests is trivial

Read More

Building distributed Web Applications with Visual FoxPro

The Web has opened a whole new area of development for building truly distributed applications that can run over widely distributed networks and has made it possible to build public access applications at relatively minor cost compared to the infrastructure that was previously required to build this type of distributed application.

Unfortunately, this new medium requires an entirely new approach to application development that focuses heavily on a very limited user interface that is presented in HTML. HTML is a text based markup language that is essentially line based producing output much in the way that ancient word processors like WordStar and WordPerfect of the DOS days produced. Compared to typical rich Windows UI applications even the new 4.0 versions of browsers have a lot of catching up to do in ease of use and usability of the form user interface used for data entry, which is typical for database applications. A lot of things can be done with HTML if you're imaginative, but the end result still leaves a lot to be desired in usability.

But what if you could build an application using Visual FoxPro on the client side talking to a Web server on the other end of the connection that is also a Visual FoxPro application? Rather than using clumsy HTML you could take advantage of the power of VFP's User Interface and ease of data access to build a truly user friendly application and still get the distributability that HTML based Web applications promise.

In this document I'll discuss how to do just by demonstrating some free tools that are available on this site and outlining an example application that uses this technology. You can take a look at the results on the message board of this site - the message board also features an offline reader, which uses a Visual FoxPro client application to communicate with the Web server to retrieve and post messages to and from the server.

HTTP -  More than a protocol for transmitting HTML

The good news is that you don't have to build distributed Web applications with HTML. It is absolutely possible to build an application using a rich UI and use the Web simply as a database interface to communicate. The key to make this work is HTTP - the HyperText Transfer Protocol.

The HyperText Transfer protocol is the underlying messaging protocol that is used for all transactions on the World Wide Web. Although the primary use of the protocol is to power the World Wide Web and HTML based applications, it really can do a lot more than plain HTML. Essentially, you can use HTTP to transport any kind of data over the Web including binary data and even database files!

HTTP is based on a client/server model. Typically, the Web browser is the client that requests data from the Web server. The browser is the display mechanism that shows the content that was served up by the Web server. The server is nothing more than a way station that figures out what type of content to provide to the client. To think of a Web server and HTTP as only providing HTML is a mistake – any kind of data, including files can be passed back and forth over this protocol as long as you follow the rules of the protocol. I’ll show an example of this shortly.

In the latest versions of Windows (Windows 95, Windows NT 4.0), Microsoft has provided high-level support for various Internet protocols in a system library called WinInet. This library supports relatively simple API interfaces for accessing FTP, HTTP and WinSock. Microsoft endowed it with a familiar file based architecture where you can open a connection and then read and write to it directly. This wrapper on top of the WinSock API makes it possible for high level languages such as Visual FoxPro to access the functionality in this system interface directly.

Before I jump in and show you how to create a class that can access the HTTP functionality in WinInet, let’s take a look at the implications of direct access to HTTP. The ability to send and receive data in any format you choose gives you the capability to implement your own client/server architecture that can communicate over any Internet connection.

Here are some useful applications that jump out:

Any real time data connection that updates a form from data found on the Web – stock charts or weather information for example – can simply access an HTTP link and download the data. If you provide timely data to your clients (whether it's financial data or an image captured from your backyard), you can make the data available directly from within a VFP application. The data can either be HTML (which you’d have to parse or display via the Web browser control) or data that was formatted a specific way so that it’s easy to get into a VFP table (a comma delimited string for example) and then into a listbox or grid or so forth.
Software or data updates lend themselves immediately to this technology. Subscription based services might provide dataupdates over the Internet using HTTP to download files. The same mechanism can be used to update your actual application files, downloading the update and then running an update program.
Another good example is an offline reader for an online message board. You might have seen various versions of HTML based newsgroup type applications, such as the Visual FoxPro Universal Thread (www.universalthread.com) or my own message board at www.west-wind.com/wwthreads/. With the ability to read and write data to and from an HTTP link you can use the same existing Web server interface to send down all the data since your last visit, update an existing FoxPro table with the data, then use the Visual FoxPro GUI application to browse the messages. When you need to post a message, all messages are stored in a temporary table, which can then be posted to the Web site the next time you are online or you decide to click upload messages.
One thing to keep in mind, though: Although you are not using HTML to display the output, you still need a backend Web application as discussed in previous Web articles. You still need to run a Web server and some backend software such as Web Connection, Active Server Pages, FoxISAPI or FoxWeb to provide the server portion of your application. The difference is that I won't send back HTML in any of the examples here, but rather data that is shared by the client and server.

Read More