33.5. Accessing External Physical Devices with Adapters; Buy vs. Build

Another requirement in this iteration is to interact with physical devices that comprise a POS terminal, such as opening a cash drawer, dispensing change from the coin dispenser, and capturing a signature from the digital signature device.

The NextGen POS must work with a variety of POS equipment, including that sold by IBM, Epson, NCR, Fujitsu, and so forth.

Fortunately, the software architect has done some investigation, and has discovered that there is now an industry standard, UnifiedPOS (www.nrf-arts.org), that defines standard object-oriented interfaces (in the UML sense) for all common POS devices. Furthermore, there is the JavaPOS (www.javapos.com)—a Java mapping of the UnifiedPOS.

Therefore, in the Software Architecture Document, the architect adds a technical memo to communicate this significant architectural choice:

Technical Memo
Issue: POS Hardware Device Control

Solution Summary: Use Java software from the device manufacturers that conforms to the JavaPOS standard interfaces.

Factors

  • Correctly controls the devices

  • Cost to buy vs. build and maintain

Solution

The UnifiedPOS (www.nrf-arts.org) defines an industry standard UML model of interfaces for POS devices. The JavaPOS (www.javapos.com) is an industry standard mapping of UnifiedPOS to Java. POS device manufactures (e.g., IBM, NCR) sell Java implementations of these interfaces that control their devices.

Buy these, rather than build them.

Use a Factory that reads from a system property to load IBM or NCR (etc.) set of classes, and return instances based on their interface.

Motivation

Based on an informal survey, we believe they work well, and the manufacturers have a regular update process for their improvement. It is difficult to get the expertise and other resources to write these ourselves.

Alternatives Considered

Writing them ourselves--difficult and risky.


Figure 33.14 shows some of the interfaces, which have been added as another package of the domain layer in our Design Model.

Figure 33.14. Standard JavaPOS interfaces.


Assume that the major manufacturers of POS equipment now provide JavaPOS implementations. For example, if we buy an IBM POS terminal with a cash drawer, coin dispenser, and so forth, we can also get Java classes from IBM that implement the JavaPOS interfaces, and that control the physical devices.

Consequently, this part of the architecture is resolved by buying software components, rather than building them. Encouraging the use of existing components is one of the UP best practices.


How do they work? At a low level, a physical device has a device driver for the underlying operating system. A Java class (for example, one that implements jpos.CashDrawer) uses JNI (Java Native Interface) to make calls out to these device drivers.

These Java classes adapt the low-level device driver to the JavaPOS interfaces, and thus can be characterized as Adapter objects in the GoF pattern sense. They can also be called Proxy objects—local proxies that control or enhance access to the physical devices.

It is not uncommon to be able to classify a design in terms of multiple patterns.


..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.138.60.166