Recent articles:
Popular archives:
Java: A platform for platforms
Sun's reorg may seem promising to shareholders but it's also a scramble for position. The question now is whether Sun can,
or wants to, maintain its hold on Java technology. Especially with enterprise leaders like SpringSource and RedHat investing
heavily in Java's future as a platform for platforms
Also see:
Discuss: Tim Bray on 'What Sun Should Do'
I am resourceful though, and since Dallas Semiconductor had promised that a fully functional Java Ring was going to be available eventually, all I needed to do was wait. And while I was waiting, what better to do but learn the ins and outs of programming my new piece of "smart" jewelry?
Of course this pursuit of knowledge did raise the question of what, exactly, I should program into my ring.
I pondered this question for a while, until I came up with what was, for me, the ideal solution: I would program my ring to simulate the most important piece of cryptographic equipment used in the second World War -- the German ENIGMA machine. The ENIGMA was used by German commanders to encrypt all of their important plans and orders to the field marshalls. But first I had to figure out what the heck an APDU was!
The Java Ring is in fact a Java smart card, and the ring's virtual machine is based on the Java virtual machine (JVM) that was proposed as the Java Card 2.0 standard. I've seen some wonderful technical discussions on how to program these devices (see the Resources section for pointers), but, to be perfectly honest, the descriptions were quite opaque to me. I was looking for linkages between the JVM on the ring and the JVM on a PC and finding nothing beyond descriptions of a rather peculiar serial interface that connected them. I then realized that what really connected the ring to the "outside" world was not a serial port but a network protocol. Allow me to explain.
The Java Card architecture has taken client/server architectures to a new place -- one where the "server" is a small piece of software on an extremely small system, and the client is a potentially huge piece of software on a potentially much larger system. The network protocol is encapsulated in packets that are called application program data units, or APDUs for short.
Unlike packets in the TCP/IP world, these APDU packets don't carry any sort of addressing information. Instead, they are implicitly addressed to the computer on the other end of the serial link. However, like their big-brother packets in the TCP/IP world, APDUs do carry a few bytes that are common to all packets. These can be used by the smart card infrastructure to decide when to send the APDUs to the server on the smart card, and when to interpret them directly.
This understanding provided an answer to one of my first questions about the Java Ring: How come a broken applet doesn't make the ring unusable? The answer is that the smart card runtime code gets the first crack at decoding the APDUs as they arrive on the serial interface. Further, there are predefined APDUs that tell the runtime to select an applet, delete applets, load applets, and so on. Thus, errant applets are simply deleted by the developer once it's ascertained that they aren't responding correctly to the APDUs they receive.