This is to say that an application that uses these technologies doesn’t have to worry about the peculiarities of any specific piece of hardware, that responsibility is moved to the developer of the service object. Hopefully that developer is also the hardware vendor, so they full understand the capabilities and requirements of their device and they provide a single known service object rather than having many different third parties create their own, leaving application developers with the decision of which one to use.
In order for us to achieve device independence there is one golden rule;
The same (application) code must produce the same result and output with all devices and service objects.
Anything short of that, and you are back to worrying about whether a particular device will work with your application and hard coding exceptions to the known rules. For example, if one service object throws an exception that isn’t thrown by another under the same circumstances the device independence is now broken.
In the above case, if you tested your solution with the service object that didn’t throw an exception then you’d never know you needed to handle it until one of your customers happened to use the second service object… at which point they get an unhandled exception, your software crashes and despite it not really being your fault you’re the one that looked bad because you said any UPOS/Pos .Net device would work. At best you handle the exception anyway, which prevents the error, but still leaves the device unusable, you fail to receive input from the device or you fail to output to the device properly. None of the scenario’s is really much better because, in short and from your customers perspective, your software didn’t work.
The same applies to input and output differences when exceptions aren’t thrown. If you have a service object for each of two different"I won’t tell a customer a particular device will work until I’ve tested it, even if I'm told it’s compliant." printers, and both report they have the capability to print bitmaps (or anything else) then both must implement ALL of the bitmap printing methods, since there is no CapRecMemoryBitmap or CapRecSetBitmap. It’s no good for a service object to say it supports printing bitmaps but then only implement one of the mechanisms available for printing them.
The problem is that UPOS and Pos .Net only seem to get us half way to true device independence. UPOS provides a common set of interfaces and architecture for using devices. Pos .Net provides implementations of these interfaces and ways of discovering installed devices, Plug and Play support etc.
These specifications and implementations allow us to find and use devices in a common way that seems device independent, until you start testing with different hardware and service objects. Both systems are (necessarily) dependent on service objects for a lot of implementation detail and it would appear the UPOS specification doesn’t go far enough in describing expected behaviour. Either that, or service object developers aren’t good at following it.
In my next post I’ll discuss some of the differences in behaviour that I’ve discovered with just the very limited set of hardware I have available for testing, and why I won’t tell a customer a particular device will work until I’ve tested it, even if it says it’s UPOS/OPOS/Pos .Net compliant.