Device Standards History

A development team designing and implementing a POS application for a retailer faces a myriad number of decisions. (POS may be Point-of-Sale or Point-of-Service, depending upon a company's marketing team.) One of the more vexing issues is the selection of and programming to the physical POS devices, including a POS printer, a bar-code scanner, and a credit/debit card reader.

Why has this been difficult? Because of the significant disparity in features, functionality, and programmatic interfaces from vendor to vendor, and sometimes even within devices from a vendor. Therefore, the application team has historically chosen and implemented interface logic for some mandatory set of devices for initial deployment, then added to this set as time allows or additional customers require.

OPOS

The first widely-adopted POS device standard is OPOS. OPOS was initiated by Microsoft, NCR, Epson, and Fujitsu-ICL to help integrate POS hardware into applications for the Windows™ family of operating systems. OPOS uses COM technology, and is therefore language independent. The acronym stands for "OLE for POS", which is somewhat dated due to the renaming of "OLE" to "ActiveX" and "COM". But OPOS has been retained for historical and recognition reasons.

The first OPOS technical meeting was convened in January, 1995. The first production release, 1.01, was made in March, 1996. Its seventh release, 1.6, was in July, 2001.

JavaPOS

JavaPOS was initiated by Sun, IBM, and NCR to help integrate POS hardware into applications for the Java language. JavaPOS is operating system independent.

The first JavaPOS technical meeting was convened in April, 1997. The first release, 1.4, was made in March, 1999, and it tracks closely with OPOS 1.4 (released in October, 1998). The 1.6 release was in July, 2001.

UnifiedPOS

UnifiedPOS was initiated by a consortium of retailers, and is led by the National Retail Federation.

Beginning with release 1.5, both OPOS and JavaPOS have approved UnifiedPOS as the owner of language and operating system independent POS device interfaces. OPOS then maps these interfaces for COM within Windows, and JavaPOS maps them for Java.

Beginning with release 1.7, the OPOS and JavaPOS committees no longer release an implementation-specific document. The UnifiedPOS document has added implementation information into appendices.

Caution

Standards are very useful in providing an application with a common interface to devices. However, implementations of the standard are likely to contain:

• Bugs...
• Alternate implementations, when the specification is not sufficiently descriptive.
• More bugs... :)

As is always the case when interfacing with external components, the application developer is advised to:

• Code "defensively", so that when the unexpected occurs, you can at least trap and log the error without aborting the application.
• Test extensively with each new device.
  • If bugs are found, then attempt to work with the vendor to obtain a correction. Some will provide a quick turnaround for you.
  • Otherwise, you may need to try a vendor- or device-specific workaround. Use the properties that give the service's device name and description if needed.

We have progressed from "Write many -- Test many" to "Write once (with exception cases when required) -- Test many".  But this is indeed progress!

Last updated: 2009-12-31

Web Site navigation aids:  Table-of-Contents.  Search.

Send mail to webmaster@monroecs.com with questions or comments about this web site.
Copyright © 2009 Monroe Consulting Services, Inc.