Portable Web Servers with Java Card 3.0.This technical article describes how Java Card 3.0 technology allows application developers to create and deploy servlet applications on smart card devices.

Deploying Servlets on Smart
Cards: Portable Web Servers
with Java Card 3.0 By Bruce Hopkins, January 2010 No, that's not a typo. No, I'm not
talking about technology that will be
available 10 years from now. Java
Card 3.0 technology is available today
that allows application developers to
create and deploy servlet applications on smart card devices. This article
shows developers how to get started
with developing servlets with the Java Card Connected Development Kit 3.0.2. Contents - Background - Comparing JavaCard 2 to JavaCard 3 - Getting Started the Java Card
Connected Development Kit and the
Persistence Example - Conclusion Background In previous versions of the Java Card
specification, Java developers were
significantly limited in the breadth and
depth of the applications that could be
created for Java Card 2 devices, such
as: A very strict subset of Java APIs, with
only JDK 1.0 features No support for java.lang.String objects No threads No garbage collection No support for networking No native support for . c l a s s files No dynamic class loading 1-D Arrays 8-bit CPUs 8kB of RAM Despite these limitations, Java Card
technology became the most widely
deployed Java platform in the world
with over 3.5 billion deployments.
Java Card 3.0 technology has several
significant enhancements over the Java Card 2 platform, as explained in
the following sections. Comparing JavaCard 2 to JavaCard 3 As you can see from the sequence
diagrams in Figures 1 and 2 located
below, creating a complete application
that involved using Java Card 2
technology could be tedious. Figure 1. A Sequence Diagram
Depicting the Interactions Between a
Desktop Application and a Java Card 2
Application Figure 2. A Sequence Diagram
Depicting the Interactions Between a
Mobile Application and a Java Card 2
Application As you can see from the preceding
figures, both the desktop and mobile
applications need to eventually use
the APDU (application protocol data
unit) protocol to communicate with
applications (also known as applets) located on the Java Card 2 smart card.
In some cases, however, the API
restrictions -- combined with having to
use byte arrays for all interaction with
the smart card -- were major
deterrents to attracting enterprise Java developers to the Java Card platform. However, the Java Card 3 platform
provides significant improvements to
its predecessor, and those changes
should appeal not only to enterprise
and desktop developers, but to mobile
developers as well. The Java Card 3 platform includes support for the
following features: An API based upon a CLDC subset,
with Java 6 features Annotations b y t e , s h o r t , i n t , l o n g , c h a r and j a v a . l a n g . S t r i n g Threads Servlets Garbage collection of objects TCP/IP networking HTTP and HTTPS . c l a s s files . w a r deployment files Dynamic class loading 2-D Arrays 32-bit CPUs 24kB of RAM Figure 3, shown below is a sequence
diagram showing the steps and
actions involved in creating a complete
application using the Java Card 3
platform. Figure 3. A Sequence Diagram
Depicting the Interactions Between a
Mobile or Desktop Application and a
Java Card 3 Application With Java Card 3 technology, smart
card application development has
instantly become a lot easier, and has
now taken a significant leap-ahead in
capability so that the following
scenarios are possible: Developers no longer need to create
individual client applications to access
the data and resources on the smart
card. The only client interface needed
is an ordinary web browser. Smart Card applications are now fully
functioning TCP-based servers. These
server applications are Java servlets,
and they have a full HTTP stack to
allow them to process GET requests,
POST requests, headers, cookies, sessions, and so on. You can secure the data between the
client (the browser) and the server
(the smart card) by using the industry-
standard SSL (secure sockets layer). Getting Started the Java Card
Connected Development Kit and the
Persistence Example Did you know that Java Card
applications have access to two heap
spaces? One of them is volatile, which
means that it acts like RAM, so all
information stored in that heap
location is lost after the system is reset (that is, when the card is removed and
inserted). The other heap area is non-
volatile, so data stored in that location
is truly persistent, even after a system
reset. To get clear understanding of how to
store data on the card in the volatile
heap allocation, let's take a look at the
Persistence example from the Java Card Connected Development Kit 3.0.2.
Table 1, shown below, provides a
detailed breakdown of the files
contained within the % f o l d e r _ r o o t % \ J C D K 3 . 0 . 2 _ C o n n e c t e d E d i t i o n \ s a m p l e s \ w e b \ P e r s i s t e n c e folder. Table 1. Description of Files and
Folders Within the Persistence
Example
Folder/File Name Description / b u i l d . x m l This is the primary ant build xml file.
The project name, base directory, and
import file are specified in this file. / b u i l d / This is the parent folder that contains
the build arifacts that will be
automatically created by ant. These
artifacts include the intermediary / W E B - I N F / c l a s s e s folder, which will be packaged into the final . w a r file / c o n f i g / This is the parent folder that contains
the configuration files. / c o n f i g / b u i l d - i m p l . x m l This is an autogenerated ant build file
that is imported from the primary
build.xml file. It is not recommended
for developers to modify this file. / c o n f i g / g e n f i l e s . p r o p e r t i e s This is an autogenerated file used by
NetBeans. It is not recommended for
developers to modify this file. / c o n f i g / p r o j e c t . p r o p e r t i e s This is the main property file that sets
several configurable properties such
as the main servlet, the main URL, as
well as the web context path. / c o n f i g / p r o j e c t . x m l This the NetBeans project XML file. / d i s t This is the parent folder containing the
redistributable items / artifacts after
the build process is complete. / d i s t / P r e s i s t e n c e . s i g n a t u r e This is a binary file that contains a
digital signature. / d i s t / P r e s i s t e n c e . w a r This is the deployable . w a r file that will be loaded on the Java Card. / h t m l / This is the parent folder containing the
index.html as well as the
accompanying images. / h t m l / i n d e x . h t m l This is a simple placeholder html page
that redirects to the "index" path of
the JavaCard WAR application. / h t m l / i m a g e s / This is the folder that contains the
images referenced by the JavaCard
servlet. / M E T A - I N F / This is the parent folder containing
manifest files. / M E T A - I N F / j a v a c a r d . x m l This is the JavaCard application
descriptor file. / M E T A - I N F / M A N I F E S T . M F This is a simpe manifest file that's
common for JAR and WAR files. / s r c This is the parent folder for all Java
source code. s r c / . . . / P r e s i s t a n c e S e r v l e t . j a v a This is a servlet that shows the
contents of the database, adds new
items to the database, and deletes
existing items. s r c / . . . / I n d e x S e r v l e t . j a v a This is a servlet that has been mapped
to the "index" path of the Java Card
WAR application. This servlet presents
an HTML form, which invokes the
HelloWorldServlet card application. s r c / . . . / D a t a b a s e . j a v a JavaCard 3 applications have two
heap spaces (volatile and non-
volatile). This is a simple class that
store data in volatile heap. / W E B - I N F This is the parent folder that contains
the assests used by the servlets. / W E B - I N F / f o o t e r . i This is a part of an HTML file. / W E B - I N F / h e a d e r . i This is a part of an HTML file. / W E B - I N F / i n d e x . i This is a part of an HTML file. / W E B - I N F / w e b . x m l This is a typical w e b . x m l that defines and maps the servlets with
URLs. Listing 1 is the code for D a t a b a s e . j a v a , a class that allows multiple users in different
browser sessions to store and retrieve
data objects from the volatile heap
space of a Java Card application. Listing 1. D a t a b a s e . j a v a p a c k a g e c o m . s u n . j c h o w t o . p e r s i s t e n c e ; i m p o r t j a v a . u t i l . V e c t o r ; / * * *
* / p u b l i c c l a s s D a t a b a s e { p r i v a t e s t a t i c V e c t o r < S t r i n g > i t e m s = n e w V e c t o r < S t r i n g > ( ) ; / * * * @p a r a m i t e m * / p u b l i c s t a t i c v o i d a d d I t e m ( S t r i n g i t e m ) { i f ( ! i t e m s . c o n t a i n s ( i t e m ) ) { i t e m s . a d d E l e m e n t ( i t e m ) ; } } / * * * @ r e t u r n * / p u b l i c s t a t i c V e c t o r < S t r i n g > g e t I t e m s ( ) { r e t u r n i t e m s ; } / * * * @p a r a m i t e m * @ r e t u r n * / p u b l i c s t a t i c b o o l e a n d e l e t e ( S t r i n g i t e m ) { r e t u r n i t e m s . r e m o v e E l e m e n t ( i t e m ) ; } } As you can see, the code for the
database is pretty simple as it is
primarily a wrapper class that allows
users to store, retrieve, and delete
objects from a String-typed Vector. It
demonstrates the capabilities of the Java Card 3 platform well, since it
shows that you can use generics, first
introduced in the Java SE 5.0. Listing 2 is the code for the Java Card 3
servlet that accesses the database. Listing 2. P e r s i s t e n c e S e r v l e t . j a v a p a c k a g e c o m . s u n . j c h o w t o . p e r s i s t e n c e ; i m p o r t j a v a . i o . I O E x c e p t i o n ; i m p o r t j a v a . i o . P r i n t W r i t e r ; i m p o r t j a v a x . s e r v l e t . R e q u e s t D i s p a t c h e r ; i m p o r t j a v a x . s e r v l e t . S e r v l e t E x c e p t i o n ; i m p o r t j a v a x . s e r v l e t . h t t p . H t t p S e r v l e t ; i m p o r t j a v a x . s e r v l e t . h t t p . H t t p S e r v l e t R e q u e s t ; i m p o r t j a v a x . s e r v l e t . h t t p . H t t p S e r v l e t R e s p o n s e ; / * * * A S i m p l e P e r s i s t e n c e S e r v l e t . * / p u b l i c c l a s s P r e s i s t a n c e S e r v l e t e x t e n d s H t t p S e r v l e t { / * ( n o n - J a v a d o c ) * @ s e e j a v a x . s e r v l e t . h t t p . H t t p S e r v l e t # d o P o s t ( j a v a x . s e r v l e t . h t t p . H t t p S e r v l e t R e q u e s t , j a v a x . s e r v l e t . h t t p . H t t p S e r v l e t R e s p o n s e ) * / @O v e r r i d e p u b l i c v o i d d o G e t ( H t t p S e r v l e t R e q u e s t r e q u e s t , H t t p S e r v l e t R e s p o n s e r e s p o n s e ) t h r o w s I O E x c e p t i o n , S e r v l e t E x c e p t i o n { S t r i n g o p = r e q u e s t . g e t P a r a m e t e r ( " o p " ) ; S t r i n g i t e m = r e q u e s t . g e t P a r a m e t e r ( " i t e m " ) ; i f ( o p ! = n u l l ) { i f ( o p . e q u a l s ( " A d d " ) ) { i f ( i t e m ! = n u l l ) { D a t a b a s e . a d d I t e m ( i t e m ) ; } } e l s e i f ( o p . e q u a l s ( " D e l e t e " ) ) { i f ( i t e m ! = n u l l ) { D a t a b a s e . d e l e t e ( i t e m ) ; } } } r e s p o n s e . s e t C o n t e n t T y p e ( " t e x t / h t m l " ) ; P r i n t W r i t e r o u t = r e s p o n s e . g e t W r i t e r ( ) ; R e q u e s t D i s p a t c h e r d i s p a t c h e r = n u l l ; d i s p a t c h e r = r e q u e s t . g e t R e q u e s t D i s p a t c h e r ( " / W E B - I N F / h e a d e r . i " ) ; d i s p a t c h e r . i n c l u d e ( r e q u e s t , r e s p o n s e ) ; o u t . p r i n t l n ( " < t r > " ) ; o u t . p r i n t l n ( " < t d b g c o l o r = \ " # F F F F F F \ " a l i g n = \ " c e n t e r \ " v a l i g n = \ " m i d d l e \ " > " ) ; o u t . p r i n t l n ( " < t a b l e b g c o l o r = \ " # 0 0 0 0 0 0 \ " b o r d e r = \ " 0 \ " w i d t h = \ " 1 0 0 % \ " c e l l s p a c i n g = \ " 1 \ " c e l l p a d d i n g = \ " 1 5 \ " > " ) ; o u t . p r i n t l n ( " < t r > " ) ; o u t . p r i n t l n ( " < t d a l i g n = \ " c e n t e r \ " b g c o l o r = \ " # F F F F F F \ " > " ) ; o u t . p r i n t l n ( " < / b > < b i g > < b i g > S i m p l e D a t a b a s e < / b i g > < / b i g > < / b > " ) ; o u t . p r i n t l n ( " < f o r m m e t h o d = \ " g e t \ " a c t i o n = \ " d a t a b a s e \ " > " ) ; o u t . p r i n t l n ( " < t a b l e b o r d e r = 0 > " ) ; o u t . p r i n t l n ( " < t r > " ) ; o u t . p r i n t l n ( " < t d > I t e m : < / t d > < t d c o l s p a n = 2 > < i n p u t t y p e = \ " t e x t \ " n a m e = \ " i t e m \ " > < / i n p u t > < / t d > " ) ; o u t . p r i n t l n ( " < / t r > " ) ; o u t . p r i n t l n ( " < t r > " ) ; o u t . p r i n t l n ( " < t d > < / t d > " ) ; o u t . p r i n t l n ( " < t d > < i n p u t t y p e = \ " s u b m i t \ " n a m e = \ " o p \ " v a l u e = \ " A d d \ " > < / t d > " ) ; o u t . p r i n t l n ( " < t d > < i n p u t t y p e = \ " s u b m i t \ " n a m e = \ " o p \ " v a l u e = \ " D e l e t e \ " > < / t d > " ) ; o u t . p r i n t l n ( " < / t r > " ) ; o u t . p r i n t l n ( " < t r > " ) ; o u t . p r i n t l n ( " < t d c o l s p a n = 3 > < h r > < / t d > " ) ; o u t . p r i n t l n ( " < / t r > " ) ; o u t . p r i n t l n ( " < t r > " ) ; o u t . p r i n t l n ( " < t d c o l s p a n = 3 > < b > I t e m s i n D a t a b a s e < / b > < / t d > " ) ; o u t . p r i n t l n ( " < / t r > " ) ; o u t . p r i n t l n ( " < t r > " ) ; o u t . p r i n t l n ( " < t d c o l s p a n = 3 > < t e x t a r e a r e a d o n l y r o w s = \ " 5 \ " c o l s = \ " 2 0 \ " > " ) ; i f ( D a t a b a s e . g e t I t e m s ( ) . s i z e ( ) < = 0 ) { o u t . p r i n t ( " \ n \ n D a t a b a s e i s E m p t y ; \ n \ n " ) ; } e l s e { f o r ( S t r i n g s t r : D a t a b a s e . g e t I t e m s ( ) ) { o u t . p r i n t l n ( s t r ) ; } } o u t . p r i n t l n ( " < / t e x t a r e a > < / t d > " ) ; o u t . p r i n t l n ( " < / t r > " ) ; o u t . p r i n t l n ( " < / t a b l e > " ) ; o u t . p r i n t l n ( " < / f o r m > " ) ; o u t . p r i n t l n ( " < / t d > " ) ; o u t . p r i n t l n ( " < / t r > " ) ; o u t . p r i n t l n ( " < / t a b l e > " ) ; o u t . p r i n t l n ( " < / t d > " ) ; o u t . p r i n t l n ( " < / t r > " ) ; d i s p a t c h e r = r e q u e s t . g e t R e q u e s t D i s p a t c h e r ( " / W E B - I N F / f o o t e r . i " ) ; d i s p a t c h e r . i n c l u d e ( r e q u e s t , r e s p o n s e ) ; } } As you can see from the preceding
code listing, P e r s i s t e n c e S e r v l e t . j a v a works like any other subclass of
HTTPServlet. All you need to do is
override the HTTP methods that you
want, and replace them with your own
code. In this case, we're only
supporting HTTP GET requests. If the HTTP parameter "op" is set to "Add",
then we'll add a new item to the
database. If, however, "op" is set to
"Delete", then the specified item will be
removed from the database. In either case, the servlet completes its
work by showing the final list of
contents in the database. The Java
Card 3 platform doesn't support JSP
files, so you should notice in Listing 2
that much of the application is dedicated to creating the HTML
response. Figure 4 is the
PersistenceServlet in action. Figure 4. Adding My Favorite Stock
Symbols to the P e r s i s t e n c e S e r v l e t . j a v a Conclusion The Java Card 3 platform is lightyears
ahead of its predecessor. It includes
several new features that allow
developers to create extremely
sophisticated applications using Java
servlet technology. Are you ready for a new generation of servlet
applications that execute on a smart
card?