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

Figure 3, A “messaging view” of VFP applications simply accepts requests and provides responses, with no distinction between input and output.

What should the common messaging standard be like? There are several reasons why XML is a good choice for messages between disparate clients and servers. Among them:

· XML is a format easy for multiple types of participants to create and decode, because it is not binary. Yet it makes provision for multiple extended character sets and encodings, and does not require the participants to share these character sets or encodings.

· XML easily handles relational data, because of the way elements nest Lookup elements can be handled with external references to other documents, the use of ID and IDREF attribute types in the DTD, and many other schemes. Yet it is not restricted to a regular format like relational databases. Binary data of any imaginable rich data type can be designated using NOTATION-type attributes or the XLINK standard. Like Lotus Notes and object databases, XML can “stretch” to irregular formats that easily represent real-life needs without following a pre-designed structure.

· Unlike EDI, XML messages can be broken up with separate sections sent in parallel, for better performance. Also unlike EDI, it is not expensive to get started in XML and participate in XML exchanges.

· XML passes easily over HTTP transport, and can pass through firewalls. Yet it doesn’t execute or trigger code directly, even though an XML message may describe code to be executed. This makes it easy to send and receive, but also allows security dangers to be minimized. The receiver is in charge of what code can be described and executed on the receiving system.

With standardized XML requests and responses as your collaboration strategy, you do not plan separately for separate clients. You define the following elements, the same for all clients:

· Define a message, or as many message formats, as you wish, to expose your public interface, your way of working with other applications. (Don’t go it alone – investigate SOAP or Hewlett Packard’s e-speak, or one of several other available standards for defining document formats. But if you choose to invent your own format(s) instead, as you’ll see, you haven’t precluded any opportunities. )

· Define a way or ways in which you will allow the request messages to be passed to your applications (will you use a COM message call accepting an XML string, or a filename, or both? Will a command-line argument indicate a file to be processed? Will your application look for files in a particular physical location representing a task queue?). See “a short but pertinent digression”, listed as Appendix A at the end of this paper.

· Define your application’s method of passing back a response back to its collaborators (usually, responses are provided according to a similar plan as the requests were accepted).

Nobody does it better

When you see your work put in these terms (a series of uniform requests and responses), it almost looks as though anybody could do database development work! Not so.

Remember that while we’re simplifying the act of collaborating, you still have to distinguish between input and output to perform the actual data work that is the real raison d’être of a VFP application. Once you receive input data, you have the same storage and manipulation tasks as before. To send the data, you still need to manipulate complex data relationships and calculate results, as before.

We’re just removing the distractions, getting you back to the work you used to do when you wrote FoxPro applications. If you remember, you had plenty of work to do then, and things haven’t changed. Data is still complex, and proper data storage and analysis takes your professional skills. From what I’ve seen in the last couple of years, businesses and organizations of all types sorely need your skills focused on the work of data management, not siphoned off into understanding how a serial port or some other interface to an input or output device can be coaxed to work with VFP.

You don’t have to change all at once

Suppose your applications currently have a standard Windows GUI interface, do you have to stop using it or change how it works to start providing this common message interface? Suppose your applications currently use REPORT FORMs to provide printed output, do you have to stop? No, of course not.

You define your XML requests and responses based on the kinds of input your applications need, not necessarily to replace them. They can exist in parallel with your current activities, while making room for new clients, without a problem.

For example a database update XML request would include elements currently provided by your data input screen. Your data input screen can continue to function as before, while the other clients used the XML request-processing to handle updates. Whenever you’re ready, you can retrofit the data input “save” button to construct and send the same XML update request to your database procedures as all other clients.

In addition, there may even be some new clients who cannot “speak XML”. For example, the Palm device I mentioned earlier doesn’t yet support WML, the set of XML tags designed as a standard for wireless devices. (The next generation of Palms almost certainly will.) You have two possible resolutions to this problem:

· Create a completely new method of handling Palm input, making your application “Palm-knowledgeable”. In this resolution, your application evaluates where the request came from and, if it were from the Palm, reads the request differently than it would read other requests, constructs different responses tailored for the Palm.

· Accept the Palm input and “translate” it directly behind your public interface to a client-neutral XML version. Create a proxy client, inside your application, which invokes standard XML request processing by the rest of your application. The proxy client receives a standard XML response, which is then translated again – in the same, quarantined space – into a Palm-specific format relayed back to the real client. The proxy client doesn’t do the translation itself, it just provides an intermediary to relay requests and responses. For example, the VFP form “save button” we described above might call it.

The first strategy, needless to say, is not what I would recommend. It is of limited value, since it fits only one client for only a short period of time.

The second strategy gives you room to handle additional collaborations that are of a non-XML type whenever they come up. You would use this translation and proxy strategy if your customer asked you to handle an EDI exchange. The bulk of your application remains “Palm-“ and “EDI- unaware”.

How we use XML in VFP

In our work for Acxiom Corporation, XML has allowed us to be completely “client neutral”. We receive requests, and send out responses to Java clients, Flash clients, VFP clients, VB Script clients, Perl clients, Palm clients… you name it. As described above, we sometimes have to add a thin translation layer when the client doesn’t speak XML natively, but most of the processing continues exactly the same for each request.

Figure 4, Acxiom architecture shows XML and XSLT at work both in internal and external exchanges.

Our XML-handling mid-tier has changed backend data resources, without the client being aware of the difference, more times than you can imagine. These back end data resources are not accessed through the same interfaces or mechanisms -- we have been through ODBC, sockets programming, and CORBA – and they don’t even have the same structures. The client receives the same XML response, all the time, no matter what.

Actually, the client is completely unaware when our mid-tier changes, too. So sometimes the mid-tier includes VFP in the solution and at other times it does not. All I can say is the solutions that include VFP are more robust than the alternatives! Our goal has been to maintain what the client experiences, through each change.

You have probably heard people say that XML doesn’t do much good unless people agree on document formats or DTDs. In fact, this is unnecessary when you add XML’s sister-standard XSLT (eXstensible Stylesheet Language: Transformations) to the processing. As shown in figure 4 above, we have an architecture in which different parts of our own enterprise don’t share the same format, and we use XSLT to move between them. On the client side, our XML-enabled partners have their own requirements for document format, and XSLT comes to the rescue again.

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