J.M.'s company landed a contract to fix up a mid-sized university's student ID card scanning system that had just finished being rolled out. It was a few-year deployment process, first starting with the dormitories, then moving on to the copy machines, cafeteria, local businesses, and, finally, student events. Unfortunately, it hadn't been a very smooth ride, with the final straw being the original vendor giving the IT Director the choice of "2-3 card scans" or "nightly batch scan processing." The director chose to bring in another company.

At first, the system didn't seem too bad: the software was all Java and the hardware consisted of a centralized server, a handful of node servers, and serial card scanners everywhere. Well, it wasn't all Java -- the programmers couldn't seem to figure out how to use the Java serial library (according the the comments in their code) and instead decided to develop a library in C that opened the serial ports as files.

But really, writing your own serial routines in C is overlookable. I mean, who hasn't done that? The biggest problem was with the scans database. For being all computerized, it worked slowly, taking about a second or two per scan. When used at student events, it would take 3-5 seconds per scan, if it worked at all. This was a bit of an issue.

I should note that, when I said "database" earlier, I actually meant a directory structure on the file system. It was divided into three areas: security, balances, and transactions ... 

  /text_files
    /security
      /doors
        /0001
          ...
          3040557
          3040558
          ...
        /0002
          ...
          3040559
          ...
        ...
    /accounts
      /balances
        ...
        3040557
        3040558
        3040559
        ...
      /transactions
        ...
        3040557.200501081004
        3040557.200501081100
        ...

Since a file named 3040557 is in the security/doors/0001 folder, student #3040557 was allowed to unlock the door with his card. As you might also guess, her debit account balance was stored in /accounts/balances/ and transactions would add a file to the appropriate directory for later processing.

To make the system work faster, the files weren't stored on the central server. They were copied down nightly to each node server at locations around campus. This added a lot of fun for the accountants, who had the pleasure of dealing with students who figured out that the system doesn't debit until the next day.

But the real kicker was with the implementation of the copy machine scanners: they had the ability to communicate with XML. The programmers really liked this, but their core software didn't talk in XML. So, they decided to add some "middleware" between their software and the copier scanners. This middleware, however, worked only one way ...

When a scan was received, the scanner would send XML to the middleware server. This server, in turn, would send normal text data to the node server. The node server would check the balance on disk and send a combination of bytes back to the scanner to activate it. The scanner would then send an acknowledgement, in XML, back to the middle server, which would, in turn, send text data to the node server. Communication continued in this manner throughout the transaction.

But thankfully, this story does have a good ending. Although J.M's company only charged a fraction of the original software development costs, they completely rewrote the system using a fancy new thing called a "relational database".

[Advertisement] BuildMaster allows you to create a self-service release management platform that allows different teams to manage their applications. Explore how!