Many companies want remote access to legacy applications, but don’t want to perform extensive surgery on the code. Scripting languages, and one called Tcl in particular, offer one solution.
Many applications still exist on Unix servers that are character based and executed remotely, possibly by users dialing into a modem pool and communicating through a terminal emulator like telnet. Often, much would be gained if the application could be modified to allow execution via a client/server graphical interface over the Internet. However, it can be challenging to make this transition with a development effort that is short of rewriting the entire application. This article will suggest one strategy for doing so. It will also introduce and point out the benefits of Tcl as a scripting language.
Integration of a mature character-based application into a client/server GUI will necessitate three areas of development:
1. creating a client side interface and application protocol
2. creating a server front end
3. creating an interface between the existing code and the server front end.
The client side code will consist of the graphical interface and a custom protocol for exchanging requests and data from the server (at the level of the application).The server front end consists of the networking software and code to interpret the requests from the client, and call hooks to the legacy code. The only change to the existing code, hopefully, is to modify its current input/output to be sent in a manageable fashion back to the front end.
As an example, a C program using sockets could be implemented as the system’s interface to the Internet. This server program would accept and validate requests to start a session. I recommend the book Unix Network Programming by W. Richard Stevens, Prentice Hall, as a reference for anything you will need to know about sockets programming and server development.
If the server allows the session to begin, it spawns a child process which inherits the unique socket and returns to listen for more requests. The spawned process is now the server front end for the current session, and is responsible only for reading from the socket, writing to the socket, and directing the requests from the client to the appropriate hooks that interface with the legacy application. If you cannot modify your legacy code at all, you may want to look into using the Tcl extension Expect as a layer between the server and your legacy code. See http://expect.nist.gov.
Once the session is established, a typical exchange between the client, front end and legacy code would be as follows:
1. User invokes a GUI event (button, menu, etc.)
2. Client sends request to server front end
3. Server front end interprets request, calls the appropriate hook to the legacy code
4. Legacy code returns an acknowledgement, message or file name to the front end. This is then sent to the client.
As stated above, the client side code is limited to the graphical user interface and the exchange of requests and data to and from the server. This is a surprisingly simple task with Tcl.
Tcl is a free scripting language (binaries and source code) that has a toolkit for GUI development (Tk), easily supports reading/writing of sockets, and runs on Windows, Unix and Mac OS. It’s name is an acronym for Tool Command Language which refers to its usefulness as a tool to embed an interpreter alongside another program so users can add their own commands. The language itself is also easily extensible and is often used as a local front end to tie together different compiled binaries.
For a project like this one, the advantages of Tcl are that it is an interpretive scripting language and is easy to learn, allowing for rapid development. It excels at creating cross-platform GUI interfaces and both client and server network connections can be established with very few lines of code.
In fact, you can write the network interface I described above using Tcl instead of C.
Historically, the language was supported by Sun Microsystems until the development group recently formed an independent company called Scriptics, under the guidance of Tcl’s creator Dr. John Ousterhout. Scriptics sells a set of tools called TclPro, and manages the source code for the language. (As I said earlier, the language and source code are free.) A good starting point for resources is their Web site, www.scriptics.com , where you can download the binaries and source code for Tcl and follow links to information about the language and many of its extensions.
There are a number of books on Tcl. I recommend Practical Programming in Tcland Tk Second Edition, by Brent B. Welch, Prentice Hall, as a good first book. Available book about tools and some of the available extensions is Tcl/Tk Tools, by Mark Harrison, O’Reilly. There is also a Usenet group comp.lang.tcl and e-mail lists that cater exclusively to windows and Macintosh users. There is very strong support for the language by Scriptics and these groups.
The Web page claims that a half million developers use Tcl. My impression is that the strongest user base is on Unix systems, but there is a strong following using it on Windows, with the smallest group using it on Mac OS.
In future articles, I’ll discuss Tcl and its use as a client in greater detail.
Karen is a software consultant and a member of Toronto Internet Developers Association (www.tida.com). He can be reached at robert@namsi.com.
