Brewing Java at the Point of Sale

Many of us don't think about it, but the point of sale (POS) is a remotely managed application and has been for years. Next time you visit a restaurant chain or an enterprise grocer, think about the technology behind the cash register and what must be involved in updating prices and software. In practice, the state of these enterprise systems ranges from off-the-shelf, standalone registers backed by an army of key-entry personnel to highly customized (proprietary) systems using various high-speed technologies to form vast private, wide-area networks. Few standards exist, and the implementation of those standards is ad hoc at best. One common theme is all of the software is proprietary and expensive, putting enterprise functionality out of reach for smaller operations and single shop owners.

This article examines an open-source POS application written in Java and its use of certain Java functionalities to reduce complexity in order to implement a broadly applicable POS transaction engine. To many Java-literate readers, the features described may be old news, but it may be of interest to see some of the more arcane Java features used in a non-web application. Also, since this article describes an open-source project for enterprise retailers, it goes into considerable architectural detail regarding POS functionality as it applies to enterprise retail environments.

Java has emerged in recent years as a common platform for retailers to use in order to reduce software complexity and management requirements. Specifically, Java supplies many of the tools required to build applications with a smaller footprint (examine the Java SDK at 50MB compared to the Windows SDK footprint). Java includes unique functionality not widely available in linked architectures, such as dynamic class loading and serialization. As a footnote, it is possible to perform dynamic class loading in C++ under Linux, but it is not widely used and is not regarded as a fundamental language feature as it is in Java.

The resounding argument against the use of Java is its large memory footprint and slow performance. In practice, however, this argument is losing its punch. Today, it is no longer possible to buy a new computer too slow to use Java, and smaller devices are beginning to be well-supported by the Java ME (micro edition) platform. To be honest, I can't say that Java is poised to take the retail world overwhelmingly by storm. Many retailers already have a large installed base of older hardware that they are not ready to throw away. Furthermore, universal Java support for retail peripherals by the major hardware vendors does not currently exist. The industry is changing, though, and quickly. Most hardware vendors have recognized the advantages of the Java platform.

POS architecture provides a classic exercise in object orientation. First, you have something called an electronic journal, which is basically the memory version of your receipt. The journal contains lines for the various subcomponents of a sale, such as an item, a tax record or a tender (cash, check) record. They all have an amount, a quantity, etc. Are you starting to visualize the abstract interface? You also have devices, receipt printers, customer displays, scanners and scales. Look at these statements if you still need convincing:

receipt().print (ejItem);
receipt().print (ejTax);

and

operatorPrompt().print (ejItem);
operatorPrompt().print (ejTax);

If you want a POS that can be applied across retail disciplines (grocery, hard goods, restaurant) and across international borders, then what you want to create is an event engine. This is an application capable of processing generic events and realizing the results of these events in the context of arbitrary hardware devices. The event concept is pretty easy; many modern development tools revolve around the event model, and Java is no different. What is important about a generalized POS application is the events need to be user-programmable and preferably not statically linked. You also need a way of stacking them to create dialogs.