Package opencard.opt.util

Class PassThruCardService

  • Direct Known Subclasses:
    TransparentCardService
    public class PassThruCardService
extends CardService
    A card service for low level communication with smartcards. It allows to send application-provided command APDUs to the card and returns the response APDUs. The factory that creates this service is PassThruCardServiceFactory.
    This class serves as an example how a card service can be implemented. However, it contradicts the idea of card services. The responsibility for composing the APDUs sent to the card and interpreting the responses lies with the card services, not with the application. Since most people start getting familiar with smartcards by building APDUs themselves, this service is provided here as a "quick starter" for some test programs. Nevertheless, it's use is strongly discouraged when implementing real applications.
    OpenCard applications should never build APDUs, since APDUs are card specific. The same applies to interpreting the responses received from the smartcard. Instead, they should use high-level interfaces that can be implemented for different cards. These interfaces can be standard interfaces, like FileAccessCardService for ISO compatible, file system based smartcards, or they can be defined by an application.

    When designing an application that supports smartcards, there will typically be a need for two kinds of card specific code. First, the ATR sent by a smartcard has to be interpreted to make sure that the card inserted is supported by the application. An OCF application should put the respective code into a card service factory, or use an existing factory that knows the ATR(s).
    The second part of the card specific code will build command APDUs and interpret responses to these commands. This part of the code can provide rather general operations, like select a file or read some data from a file. In this case, a standard interface should be used. On the other hand, this part of the code can also provide specialized functionality, like read the serial number or read the card holder's name. In this case, the application should define it's own interface, and a card service implementing this interface has to be developed.
    Later on, if another card with different APDUs and responses has to be supported by the same application, just a service for that new card has to be developed, implementing the same interface as the first one. The factory used to create the first service will be extended, so it can decide which service to use, depending on a smartcard's ATR. The application itself does not have to be changed at all.

    Version:
    $Id: PassThruCardService.java,v 1.1.1.1 1999/10/05 15:08:48 damke Exp $
    Author:
    Thomas Schaeck (schaeck@de.ibm.com), Roland Weber (rolweber@de.ibm.com)
    See Also:
    PassThruCardServiceFactory, FileAccessCardService