Some reader favorites:
EJB fundamentals and session beans
Create a scrollable virtual desktop in Swing
Wizard API updated!
Tim Boudreau has released a new version of the Swing Wizard library (version 0.997) that fixes the WizardException bug reported in JavaWorld's recent Open Source Java Project profile. The article's examples have been reworked to test out the new, improved WizardException. Thanks, Tim, for this helpful fix!
Open Source Java Projects: The Wizard API
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.
Free Download - 5 Minute Product Review. When slow equals Off: Manage the complexity of Web applications - Symphoniq
![]()
Free Download - 5 Minute Product Review. Realize the benefits of real user monitoring in less than an hour. - Symphoniq