Cargo Tracking System - krahe.org/chris

Built in 1995, the Cargo Tracking System was a software app ahead of its time, designed and built by a group of guys who love software and what they can do with it. It was the result of a group project for their graduate class at Johns Hopkins where the requirements were few and the creative ideas many.

The concept was simple -- provide a way for a worldwide shipping company to keep track of their packages, with these goals:

build with existing components & protocols
distribute across heterogeneous machines
use redundant machines for scalability & reliability
have fun

We started with a prototype. Search for a particular shipment to get a map showing its location. Then click on any vessel in the region to see what it has on board.

Two CTS client gui's were built -- one for Windows and one for Linux/UNIX (yes, this was pre-Java). These clients spoke to the Redirector, which transparently farmed out requests between redundant servers. Shipment and vessel information was stored in a relational database we built called "shqlServer". The Map Server built the maps.

All are covered further below.

shqlServer, pronounced "she-quil server", was the piece I built. It was a relational database server built on top of a freeware relational database, "shql", for "shell sql". shql gave us rudimentary SQL for table creation & data storage & retrieval, but it could only be accessed from the UNIX shell. I wrote a set of Perl scripts that gave access to shql through TCP/IP and HTTP.

Go ahead, download shqlServer now!

shqlServer TCP/IP listened for shql requests on well-known port. To support multiple simultaneous requests, a child process was spawned for each request. The map server spoke with this layer directly.

shqlServer HTTP was built on top of the TCP/IP layer. It existed to serve the client gui's who used a browser to forward shql queries via HTTP. Results were sent back a mime type we called "shqlData".

Craig Fitzpatrick built the map server. It queried shqlServer via TCP/IP for vessel location and built a map on the fly using the Khoros image processor.

The map server supported requests via HTTP. In wrapped the dynamically-generated image with HTML that included hyperlinks on each vessel. Very slick.

Craig also built the redirector in something like one evening. Think about that next time you're paying big bucks for web farm software :)

The Linux and Microsoft Windows clients used different technologies to achieve the same goals. Both used the web browser for all data communication, even when the browser wasn't graphically involved. Smart. Very smart.

Jim Matthews built the Linux client. The style & attention to detail of his presentation slide shown here should give you an idea of the software he built. Impressive.

More of Jim's Linux client. This shows how a click on a vessel in the browser sends an HTTP query to shqlServer, which in turn returns shqlData as a MIME type which is auto-forwarded to the Linux client for display. Whew.

Rami Habal used a similar architecture for the Windows client. This was still during the days when Microsoft used the term "OLE", before it became COM/DCOM, ActiveX, and/or DNA.

The Mosaic Browser could be put in "full page" mode so it actually looked like it was part of Rami's client app. Nice.

Yes, we got an "A" for our project. We also gave away source code to the reusable software that we wrote. Hmmmm, sound like open source?