Transcript Embedded Java in POS-terminals

Embedded Java in POS-terminals
Agenda:
1. Evolution of the POS-terminals
2. HW architecture's
3. SW architecture's
4. Making the first POS-terminal
5. Moving to other platforms
6. Using Java on a GSM based POSterminal
7. Using Java on both client and server
8. Challenges and gains
By Mads Doré - DoréDevelopment ApS
Evolution of the POS-terminals
HW architecture's
Before
Java
ECR
Early
Java
ECR
POS
(Off-line)
(Simpel)
POS _____
(Java)
POS
(Secure)
Inter
net
Current
ECR
POS ______
(Java) _____
A large number of variations in the physical setup
POS
(Secure)
SW architecture's
SW architecture's
Making the first POS-terminal
DoréDevelopment
entered late in the
process
A lot of brute force
and the “Nike
method” (Just do It!)
It was new territory
A part of the terminal
framework was
delivered in Java from
PBS
The nature of
payment systems is a
lot of customization
Moving to other platforms
Esmertec Jbed was to
dedicated
Esmertec Jbed was
not open-source and
support on error took
to long
Requirement of being
able to correct errors
ourselves
The Telium platform
Sadly bound to OEMC
and Nucleus
JamVM best choice,
but still hard to port to
a small platform
OEMC and Nucleus
threads => Starvation
Not upgraded since
2006
Java on a GSM based POS-term.
Not dead-slow, but
still slower than
competitors
Very flexible and
configurable
Long way from
application to HW
Application easy to
move to e.g. Linux or
Windows
JamVM not fully
focused on
embedded systems
Easy to change
communication
channels
Java on both client and server
POS-terminals often
connect to intelligent
equipment, a split of
the application is
often preferable
Eases tests and
enable parallel
development of
platform and
application
Need for JVM
compatibility between
client and server
Need for well
designed HW
abstraction in
GlueLogic
Timing issues might
be hard to predict
Challenges and gains
Very limited platforms
Parallel development
HW integration
PC application tests
Timing of threads
Extended product
range
JamVM performance
Configuration
handling
Enhanced flexibility
ClassPath size
Easier developer
recruiting
Memory consumption
Code reuse