| Runtime Environment Specification, Java Card Platform, v3.0.1, Connected Edition |    
|
| C H A P T E R 5 |
|
Card Initialization and Power-up |
The card initialization requirements are described in this chapter. Platform requirements during I/O interface reset are also included.
The card initialization occurs after masking and prior to card personalization and issuance. When the card is initialized, the Java Card RE is also initialized. Java Card RE initialization MUST be performed in the following sequence:
1. The Java Card virtual machine is started. The internal state required by the virtual machine and the Java Card RE to run Java applications is created and initialized.
In Java Card technology, the execution lifetime of the virtual machine (VM) is the lifetime of the card. The information required to run the applications that have been instantiated on the card MUST be preserved in persistent memory even when power is removed from the card. Because the VM and the objects created on the card are used to represent application information that is persistent, the Java Card VM appears to run forever. When power is removed, the VM only stops temporarily. When the card is powered up again, the VM starts again and recovers its previous persistent object heap from persistent memory store.
2. All Java Card RE facilities are initialized.
a. All the core platform classes and framework classes are created, loaded, linked and initialized
3. The platform policy (platform protection domains) is loaded
4. The inter-application communication facility is initialized
a. The SIO factory registry is created
b. The event notification registry is created
5. The authentication facility is initialized
6. The restartable tasks facility is initialized:
a. The restartable task registry is created
7. The card management facility is initialized:
a. The application registry is created
8. The application containers are initialized:
a. The applet container is initialized
b. The web container is initialized
9. The card manager application is loaded and instantiated
When power is re-applied following a power down (or tear) to the card, or reset operation is performed on the card (card reset), the Java Card RE MUST ensure that the following actions are performed in sequence:
1. All volatile objects are no longer accessible.
2. The component values of transient arrays are reset to their default values - 0 or null.
3. The internal reference field of all TransientReference instances is reset to null.
4. All monitors for objects are unlocked.
5. Persistent thread objects, instances of the java.lang.Thread class reachable from a root of persistence, MUST be placed in the “terminated” state and cannot be restarted.
6. All transactions in progress when power was lost are aborted. Updates to persistent object fields, array components and static fields which occurred during the aborted transaction are rolled back.
7. All I/O interfaces are initialized:
a. Any I/O interface which has been activated and supports the ISO 7816-4 defined APDU protocol is initialized per Section 5.3.1, ISO 7816-4 Reset.
b. Any I/O interface which has been activated and supports the TCP/IP protocol is initialized per Section 5.3.2, Transmission Control Protocol (TCP) Reset.
8. Any persistent GCF connection objects, instances of classes implementing the javax.microedition.io.Connection interface, that are reachable from the persistence root MUST be placed in a "closed" state.
9. The containers are restarted and MUST take the necessary actions as per the application model they support:
a. The applet container MUST perform the following actions in sequence:
i. All applet instances that were active when power was lost are implicitly deselected.
b. The web container MUST perform the following actions in sequence:
i. All active sessions are cleared - volatile HTTP session objects are garbage collected.
ii. All requests and responses are cleared - volatile HTTP request and response objects are garbage collected.
Listeners registered to receive session or request destruction events MUST NOT be notified.
10. The Restartable task facility MUST create and start new threads for the tasks that were still registered when power was lost.
11. The containers may now process incoming requests over the I/O interfaces and dispatch requests to applications.
When an I/O Interface is logically reset, all ongoing communication sessions on that interface are terminated. In addition, specific protocol requirements of each physical interface reset must be followed.
When an I/O interface which supports the ISO 7816-4 APDU protocol is reset, the applet container MUST perform the following actions in sequence to ready itself for accepting APDU commands:
1. The APDU object, if any, opened for that I/O interface MUST be placed in STATE_ERROR_IO state and MUST throw an APDUException exception with reason code APDUException.IO_ERROR upon use.
2. The applet thread, if any, dispatched to the currently selected applet instance MUST be terminated. The transaction in progress in the currently selected applet instance on that I/O interface, if any, MUST be aborted. Monitors for objects owned by the applet thread MUST be unlocked.
3. All applet instances that were active on that I/O interface at the time of reset are deselected.
If the I/O interface is being reset with the card fully powered up, meaning either initiated by the card itself or on programmatic request, each active instance is explicitly deselected via the appropriate deselect method (see Section 4.3.1.4, Applet Application Deselection). Otherwise, the active applet instances are implicitly deselected.
4. CLEAR_ON_DESELECT Transient data associated with each applet instance that was implicitly deselected is reset to the default value, if no applet instances from the application group are active on the card.
5. If default applet selection is implemented, the default applet for the basic logical channel (channel 0) for that I/O interface is selected as the active applet instance for the basic logical channel (channel 0) on that I/O interface, and the default applet’s appropriate select method is called (see Section 4.3.1.2, Applet Application Selection). Otherwise, the Java Card RE sets its state to indicate that no applet is active on the basic logical channel of that I/O interface.
When an I/O interface which supports the TCP protocol is reset, the Java Card RE MUST perform the following actions in sequence:
1. Any TCP/IP connections sustained over that I/O interface are terminated.
2. Any GCF connection objects opened over that I/O interface MUST be placed in a “closed” state.
3. If a Power Up or Card Reset is not in progress - the web container MUST perform the following actions in sequence to ready itself for accepting new HTTP requests on the ports of the I/O interface statically or dynamically allocated to the currently loaded web applications
a. Any listeners registered to receive session or request destruction events are notified.
b. All requests received on the “closed” connection are destroyed.
c. All active sessions associated with the “closed” connection objects MUST be deleted.
When the card is concurrently operating over multiple interfaces, one interface may be reset, physically or logically, without affecting the other interfaces. Applications which were communicating concurrently over multiple interfaces may need to track the termination of one of the connections.
| Runtime Environment Specification, Java Card Platform, v3.0.1, Connected Edition | 5-30-09 |
|
Copyright © 2009 Sun Microsystems, Inc. All rights reserved.