OPOS : Why it fails to live up to the hype

UnifiedPOS, OPOS and JavaPOS

UnifiedPOS is the acronym for Unified Point of Service.  It is a specification for application interfaces to point-of-service and point-of-sale devices (printers, scanners, cash drawers etc) that are used in the retail environment.

UnifiedPOS is currently maintained by the Association for Retail Technology Standards (ARTS) of the National Retail Federation (NRF), and is designed to be operating system independent and language neutral.

OPOS (OLE for POS) is one part of the UnifiedPOS specification, Specifically it is based on Microsoft® Component Object Model (COM), ActiveX, and OLE technologies and targeted on Microsoft Win32®-based operating systems. It was originally formed by a group of retail hardware vendors (Epson, IBM, ICL and NCR) but is now under the control of ARTS. In it's current implementation it uses one COM component per hardware device - an OCX for printers, one for scanners, one for cash drawers etc.

The UnifiedPOS comittee also oversees the JavaPOS specification, which is a UnifiedPOS implementation based on the Java language (thereby making it operating system independent)

JavaPOS was originally just a Java port of the existing OPOS specification - JavaPOS releases prior to 1.3 were simple Java implementations of the equivalent OPOS specification. It was only with the introduction of the 1.4 releases that the UnifiedPOS comittee was created to more tightly control the relationship between OPOS and JavaPOS.

Goals

UnifiedPOS has 5 main goals:

1. Common device architecture that is international and extends across vendors, platforms, and retail format
   
2. Standards for application to device interfaces in an operating system independent and language neutral manner.
   
3. Reduced implementation/development costs for vendors to support multiple (for example, Windows/COM and Java) platforms because they share the same architecture. This should produce speed to market for innovation.
   
4. An environment avoiding competition between standards while encouraging competition among implementations.
   
5. Allows retailers freedom of choice between OPOS and JavaPOS point of service devices.

Unfortunately there are a number of problems with OPOS:

1. OPOS is slow. This is not necessarily because of the implementations of the individual hardware vendors but because of the underlying technology. A POS application now has another layer to go through to accomplish the tasks it needs to - this layer, no matter how well designed and implemented, slows down the application. Although it is this very layer that gives the application developer his hardware abstraction I would argue that most retailers care about the speed of their software, not how easy it is for the developer to write the software in the first place.
   
2. OPOS controls from different hardware vendors vary from the specification, and sometimes even from previous releases of the same vendor. Although the OPOS committee has greatly improved the specification to clarify any problems or vagueness that may exist, each hardware vendor is left to interpret the specification as it sees fit. Obviously a vendor that strays too far from the specification will see few real life implementations, so it is in each vendor's interest to adhere to the 
   specification as closely as possible. 

   However, problems can occur when:
   a) you are developing a POS application that supports different vendors OPOS controls for each device class. (IE Symbol scanner, Epson printer, APG cash drawer)
   b) you are developing a POS application that supports multiple vendors OPOS controls for the same device class. (IE IBM scanner, NCR scanner, Symbol scanner, PSC scanner)
   c) You upgrade the OPOS controls from one version to the next
   d) You integrate an OPOS control from a new hardware vendor into an already working application
   
   Combinations of any of these 4 scenario's can lead to the developer writing custom code for a specific vendors controls, which is exactly the situation that OPOS was designed to solve in the first place!
   

3. In a retail environment the technology upon which OPOS is based - the Component Object Model - is a bad idea.
   COM is (currently) an inherently complicated technology. It has been around for quite a few years in many different forms, and although it is today gaining acceptance and popularity it is still something of a black box to many (the majority of?) developers.
   
   With it's dependence on the Windows registry, and with each hardware vendor having their own installation and configuration implementations, it can often take longer to install the OPOS controls and verify their operation than it can to write the code that uses them!
   
   While the problems with COM may not be a problem for an individual developer or tester who only has to deal with a few registers, think of the implications and the problems involved with
   a) Staging a large store prior to pilot
   b) Updating/upgrading components across a retail chain (especially if using components from multiple hardware vendors)
   c) Diagnosing problems (The printer isn't printing - Is it out of paper? No power? Is the printer control registered with the correct GUID?)
   
4. Backwards compatibility suffered from the implementation technology.  Although OPOS was designed from the outset to be backwards compatible there have had  to be changes made to the specification due to the COM technology that was used for  the implementation. Having to change the specification due to the technology used  for the implementation raises the points that
   a) the specification wasn't thought out properly in the first place, or
   b) there's a problem with technology used to implement it
   c) both of the above
   
5. Problems can occur if you use each vendors control objects (CO's) or the common control objects (CCO's). Due to #4 above, we are in the situation today where source code that works using one vendors COs may not work if you use the CCO's, and/or vice versa.

OPOS and Clarion

As a Clarion programmer you also have to be aware of the fact that Clarion's support for OCXs is nearly non-existent. You can quite easily add an OCX to a window, but problems occur if

1. You try to call an OCX method from another thread. Even if you have a reference variable to the window it (probably) won't work
2. You try to use OCX callbacks.  OPOS relies quite heavily on callbacks, especially when dealing with asynchronous events (MSR swipe, barcode scan etc) but unfortunately Clarion doesn't handle them too well.

My previous attempt to use OPOS involved integrating 8 OCXs (one for each device class I supported) into a multi-threaded (10-15) multi-DLL (100+) application. It didn't work too well. I couldn't call the OCX methods I wanted to across threads and the OCX events frequently came back to the wrong callback and/or on the wrong thread. 

If I had used another development tool (VB, VC++, Delphi etc) then I wouldn't have suffered these problems. However, I'm equally sure that I  would still have had the same problems regarding OPOS controls.  My problems were simply exaggerated by Clarion.

Future

The optimistic side of me believes that eventually OPOS will eventually deliver - it's just not there yet. Given another couple of years, a few more revisions to the specification and better software from the hardware vendors I believe it will actually become useful, notwithstanding that fact that I still don't believe that COM (in it's present form) is a suitable technology for a retail store.

Of course, the pessimistic side of me believes it's going to plummet to the ground in a ball of fire, much like ActiveRetail did.

Reference

National Retail Federation
http://www.nrf.org/

Association for Retail Technology Standards 
http://www.nrf-arts.org/

JavaPOS 
http://209.1.255.16/

OPOS common control objects
http://monroecs.com/

Microsoft OPOS 
http://www.microsoft.com/business/retail/resources/opos/overview.asp

Back to the home page