Java jazzes point of sale systems with new APIs

The cash register in your grocery store may be the next major frontier for Java thin clients, thanks to a consortium of retailers, computer companies, and point-of-sale (POS) manufacturers. They’ve formed the JavaPOS Consortium and developed the JavaPOS standard, which is stretching the boundaries of Java thin clients in ways that will benefit everything from automatic teller machines (ATMs) to factory automation systems.

Last April, about a dozen companies from the computer, retail, and POS industries formed the JavaPOS Committee to develop a Java API for point-of-sale systems. The committee formally unveiled its draft standard on January 19, 1998 at the National Retail Federation Convention in New York City. On March 28, the committee issued the final release of JavaPOS version 1.2 standard.

Participants in the JavaPOS effort include retailers The Home Depot and JCPenney; POS manufacturers such as Telxon; computer companies such as IBM and Sun Microsystems; and NCR Corp., a player in both computer and point-of-sale systems development. Altogether, a dozen companies are participating in the JavaPOS effort.

Although the Java thin-client model is ideal for retail systems, there are aspects of Java that, left alone, aren’t such a good fit. Notably, the lack of APIs for many peripherals.

“Retail has a wide variety of peripherals relative to many desktops,” says Dave Evans, senior vice president and CIO of JCPenney Company Inc., a Dallas-based department store chain. “Beyond the keyboard and CRT and printer, we have bar-code scanners (handheld or laser), magnetic-stripe readers, magnetic encoded readers, and others. We can have a customer display terminal, we can have a signature-capture device such as a pen pad. In all so far we have defined 14 service classes.”

Native Java, on the other hand, doesn’t support a lot of peripherals. “One major problem is that 100 percent Java only controls three devices — the screen, keyboard, and mouse,” says Ron Kleinman, Sun’s software architect on JavaPOS. You can write other interfaces to Java, and a lot of people do. But without an API that is part of the specification, those interfaces could potentially all be different. Which is not what you want when you’re trying to standardize in a write-once, run-anywhere model.

To make JavaPOS work efficiently, the committee had to define some new APIs. But it went beyond that by defining an API mechanism that would be much more broadly applicable.

The basic JavaPOS architecture provides a device control and a device service within each Java point-of-sale device module. The POS application communicates with the device control while the device service deals with the physical device, such as a bar-code reader or electronic cash register. The device service, in turn, relies on the JDK 1.2 Comm Port API. “The Comm Port API basically says ‘give me an enumerated list of ports of the system,'” says Kleinman. “It can be used to declare ownership of a port and say ‘give me the I/O stream.'”

To make this work effectively with a wide variety of devices, the JavaPOS committee added two more APIs to fill in the missing pieces. “The pieces missing were in a large sense NT registry capabilities,” says Kleinman. “There were two APIs developed for this — the JSL and the JSD.” JSL is the Java Service Loader, which Kleinman describes as “a class loader with hair all over its chest.” With the JSL an application can call for the scanner driver and get what it needs without knowing anything about the kind of scanner attached to the system. The information on what is where is stored in the JSD — the Java Service Database. This is a hierarchical database that exists on a thin client and keeps track of the available services and drivers.

Point-of-sale systems were made to order for Java. There are many manufacturers, many kinds of devices, and no standards for interfaces. As a result, POS software tends to be written with embedded hardware calls to specific devices. “If you replaced a bar-code reader the whole application would break,” Kleinman says.

Says JCPenney’s Evans: “I think you can see the advantages [of the write-once, run-anywhere model]. You have one way to say ‘print’ and it doesn’t matter whose printer [it] is or what the underlying operating system is.”

Beyond the write-once, run-anywhere advantage, point-of-sale applications are ideally suited to the thin-client model associated with Java. A POS terminal, even one with a lot of peripherals, doesn’t need to be very bright, but even a moderately sized retail store needs a lot of them. A big department store might have hundreds of terminals, each with several peripherals attached. At those kind of numbers the cost difference between a thin client and a personal computer become significant. Because retail is a margin-driven business, holding down costs is critical. Or, as Kleinman puts it, “thin margins demand thin clients.”

Needless to say, Java’s backers aren’t the only ones who have noticed the state of the point-of-sale market. Microsoft is backing its own POS API called OLE for Point Of Sale, or OPOS. A number of the JavaPOS consortium members are also members of the OPOS effort. But OPOS is tied to Microsoft Windows operating systems, whereas JavaPOS is tied only to Java.

JavaPOS backers have adopted much of the architecture of OPOS, both to cut development time and to improve the potential for interoperability. The JavaPOS APIs are derived from OPOS and the committee has defined the API mapping rules from OPOS to JavaPOS. There will also be bridges which will allow JavaPOS and OPOS to interoperate. “I think it will be extremely easy [to interoperate] because the model[s]…[are] very similar,” says Evans.

Currently the best descriptions of the JavaPOS are probably the JavaPOS Whitepaper and the JavaPOS Programming Guide, both available for downloading in Acrobat/PDF format from the JavaPOS Web site (see Resources below).

It will take a few months to translate the specification into software. “It will probably be a year from now before we have a lot out there,” says Evans. The JSL/JSD mechanism for writing device drivers is scheduled to be released in the JavaOS this summer, Kleinman says. However, he adds that it won’t be part of the Java Development Kit for a while.

The implications of JavaPOS and the new APIs extend far beyond grocery store scanners. The JSL/JSD mechanism used to add APIs to JavaPOS is general enough to be adaptable to any new standardized APIs. Groups from other industries that want write-once, run-anywhere benefits can establish industry-specific APIs for their devices. For example, Kleinman says that the hospitality industry is looking at using Java for its Hospitality Industry Technical Interface Standard (HITIS), which is being defined now.

“[JavaPOS] opens the door for Java to be used in ATM machines [and] on the factory floor…” says Kleinman. “It is the first applied solution of the technology that is applicable to a lot of other applications. This isn’t embedded Java, [these are] full thin-client terminals that do not happen to run on the desktop.”