Newsletter sign-up

View all newsletters

Sign up for our technology specific newsletters.

Enterprise Java

Email Address:

How to write OpenCard card services for Java Card applets

Use different smart cards with the same application -- here's how!

By Thomas Schaeck With Rinaldo Di Giorgio, JavaWorld.com, 10/01/98

The OpenCard Framework allows you to develop end-to-end solutions using smart cards that are not bound to one platform, card, or application. OpenCard achieves this with an architecture that provides two primary subsystems, one for card terminals and one for card services. Card terminals are devices you insert smart cards, Java Rings, and the like, into. Card services are used by an application to communicate with the application on the card inserted into a terminal. For inserted cards, OpenCard can automatically select and load the right card service implementation.

In this article, we'll develop a card service that demonstrates how Java Card applications can be used to provide secure portable storage to applications running on your host system -- either your PC, Unix workstation, network computer (NC), or set-top. We've run OpenCard on all these platforms successfully. OpenCard bridges the void left by other solutions that only run on single operating systems.

Let's start with a brief overview of OpenCard. Figure 1 below shows the components that are part of the OpenCard Framework.

Figure 1: The OpenCard Framework and the components that can be plugged into it

The OpenCard Framework integrates CardTerminal classes and CardService classes and offers a standardized, high-level interface to applications. Card terminal manufacturers who want to make their terminals available to OpenCard applications need to provide a CardTerminal class, which encapsulates card terminal behavior, and a CardTerminalFactory class. The card terminal factory has to be registered with the card terminal registry, which keeps track of all card terminals to the OpenCard Framework and will be used by the Framework to create CardTerminal instances when the Framework is initialized. Card services offer smart-card functionality to application developers via high-level interfaces. Smart-card manufacturers have to provide CardService classes encapsulating the behavior of their smart cards and a CardServiceFactory class. The card service factory must be registered with the OpenCard Framework and is thereafter used by the Framework to instantiate card services.

Assuming we have a smart card that we want to use via OpenCard, we, as card developers, must provide at least one card service for our smart card as well as a "factory" that can represent the card service for the Framework. Thus, we enable application developers to use our smart card in their OpenCard applications.

card services
As you can see in the image above, there may be several instances of card services per card, owned by different threads. A card service offers a certain functionality of a card to the application developer via a high-level interface.

OpenCard defines interfaces for standard functions, such as filesystem access or generation of digital signatures. Card services for cards that offer such functions should implement these interfaces. For specialized cards, dedicated interfaces may be defined -- losing interoperability, of course.

 

About Us | Advertise | Contact Us | Terms of Service/Privacy

Copyright, 2006-2008 Network World, Inc. All rights reserved.