Don't know much.....read the OCF 1.2 docs :
What i understand it is a low-level service for exchanging of APDUs and part
of the opencard APIs. But it is required to write/obtained card specific
services if some card is used which has its specific APDU structure etc.
Below is some material from the opencard docs : hope that helps!
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.
With Regards,
-Saira
-----Original Message-----
From: Michael Bender [mailto:[EMAIL PROTECTED]]
Sent: Thursday, March 01, 2001 9:45 PM
To: Christophe FOESSER
Cc: Mohammed SADIQ; Saira Bhatti; [EMAIL PROTECTED]
Subject: PassThruCardService
Hi all,
This e-mail from Christophe brought a question to mind:
> When you select your applet you can need a PassThruCardService, or your
applet
> specific CardService if you write it ;). It have to be compliant with your
> applet instruction set (You defined).
What is the OCF position on te PassThruCardService? I have OCF docs that
state that it is for debugging only, and we are having a lively debate
internally to Sun as to whether this service should be part of our
officially supported OCF API set.
mike
---
> Visit the OpenCard web site at http://www.opencard.org/ for more
> information on OpenCard---binaries, source code, documents.
> This list is being archived at http://www.opencard.org/archive/opencard/
! To unsubscribe from the [EMAIL PROTECTED] mailing list send an email
! to
! [EMAIL PROTECTED]
! containing the word
! unsubscribe
! in the body.
