|By Peter Allenbach, March 2009|
|-||Java Card Basics|
|-||What's New in Java Card 3.0|
|-||Java Card Compared with Java Editions|
|-||Reference Implementation (RI)|
The smart cards that were introduced in the 1980s had a single chip in every card, with very limited resources (especially RAM). The dominant smart card technology today runs on 4 to 8 Kb of RAM and 32 to 64 Kb of EEPROM, using slow 8-bit processors, and uses a very limited subset of Java that provides
Java Card 3 extends the Java Card 2 support for classic applets into improved connected features targeting less resource-constrained devices and including new network-oriented features.
So let's start by going over the basics about Java cards.
There are two main basic features: security and communication.
Security Is Foremost
The most important thing is security, always. Java Card 3.0 will maintain the security specifications of the current release.
VM Never Exits The Virtual Machine (VM) never exits. Card initialization happens once, and all required static data structures are created at this time. The card starts listening for incoming requests. Card reset happens every time the card "loses power"; that is, when the card is taken out (also called a card tear). After removal, when the card is reinserted into the reader, the RAM heap is lost and the system ensures that data is consistent between tears. Then the card starts listening for incoming requests again.
Two Heaps Unlike standard Java, Java Card has two heaps. All session objects are created in Volatile Memory. Persistent objects are created in Non-Volatile Memory.
Firewall between Applications All applications run in the same VM and exist in the same heap. But objects created by one application cannot be accessed by another application. Every object access is checked by the firewall. A
SecurityException is thrown if access is attempted that is not permitted.
Inter-Application Communication Applications can communicate with each other using Shared Interface Objects (SIO). Say the first application, App1, defines and implements a Shareable Interface. App1 allows App2 to access this SIO. The firewall allows App2 to access the SIO object.
Atomicity and Transactions A card can be pulled out of the card reader at any time, so Card Tear may happen at any time. Java Card must guarantee the integrity of user data by ensuring that:
It's a Web Server
A Java card is your embedded web server on the street, so to speak. It processes incoming requests and send a response back to the client. The traditional communication protocol is APDU (serial).
The most exciting change is that Java Card is now web-enabled — sort of a Mini-Me to, say, the Java EE web server. This opens it up to the wonderful world of servlet applications and to communication that uses the standard protocols. Java Card 3 supports APDU, but also HTTP(S) for high-speed interfaces, such as USB. There are two possible types of communication: contactless (card is held close to the reader) and contacted (card is inserted into the reader).
It supports the following application models:
The following figure shows the high-level architecture for Java Card 3.
When deploying web applications, Java Card deployment is the same as the standard web application format, with no
Java Card 3 runs on the recent high-end smart cards, which have more memory (approximately 24K of Volatile and 128K of Non-Volatile) and a fast 32-bit processor.
Java Card 3 also offers full Java language support, including support for
java.util, GCF, and so on)
enums, generics, enhanced
forloops, auto boxing/unboxing, and so on
The new connectivity layers and protocol stack features promise support for the emerging technology in the coming years, as shown in Figure 3.
You may be a Java developer who is familiar with Java SE, ME, or EE, but not with the Java Card Platform. If so, the following comparisons will be very useful.
Java Card 3.0 Compared with Java SE
There are three main differences between Java Card 3.0 and Java SE.
main()method, so the application start does not use
Java Card 3.0 Compared with Java EE
There are several similarities in functionality, since Java Card 3 supports a web server application model much like Java EE. For example,
As part of the Java Card Development Kit, a Reference Implementation (RI) will be available, with support for both classic and connected functionality. It will contain the following:
A NetBeans IDE plugin will also be available at the time of the release — more about that in the following sections.
Creating the "Hello" App Using the RI
The reference implementation will include the usual "hello, world" application, as shown in the following code.
Compiling and Packaging the Code
The easiest way to compile the Java source code and build the app is to use the NetBeans IDE. The manual steps from source code to putting the application on the card — the tool chain — are shown in the following figure. The NetBeans IDE automates many of these steps.
As shown Figure 5, to compile the source code, you can use the javac compiler to compile the source code, and so on. If you use the NetBeans IDE plugin, it will handle the compilation and the packaging. The NetBeans IDE Packager tool can be used to create the final module file from a folder. It also can be used to validate pre-shipped application modules or WAR files.
Loading and Creating the Application Module
Deployment is a two-step process. First you load the module onto a card. Then you create a persistent instance of the loaded module. You can use the off-card installer to load the Application module and to create the instance. You can then use your browser to view the page.
Deleting and Unloading the Application Module
If the application is no longer needed on the card, it can be removed completely in a two-step process. Use Delete to remove any given persistent instance of the application. Then use Unload to completely remove all class files and related resource files from the card.
You can use the off-card installer to delete the application instance and to unload the application.
Java Card 3.0 enhances classic functionality with connected features that target less resource-constrained devices and include new network-oriented features, such as support for web applications — including the Java Servlet APIs — as well as support for applets with extended and advanced capabilities. For more information, please check out the Java Card 3.0 specification.
Peter Allenbach has been a developer at Sun Microsystems for over 10 years, most recently as part of the Java Card 3 engineering team. Before this latest assignment, he worked primarily on Java SE technology.