|Figure 9. The SATSA Preference Tab: A new tab in the emulator Preferences window allows developers to associate a socket port number to a simulated slot. The emulator then uses socket protocol to communicate with the application on that port. Default ports are 9025 and 9026 respectively for simulated slots 0 and 1.|
Security and Trust Services API Support
Many wireless phones now contain smart cardsSIM cards in GSM phones, UICC cards in 3G phones, and RUIM cards in CDMA phones. The Security and Trust Services API (SATSA) was developed to allow J2ME applications use of smart card and WIM functions, secure storage and cryptographic operations. It, like the Location API, is an optional J2ME package.
Devices that actually have smart cards will have one or more smart card "slots" or compartments. The WTK 2.3 emulator, therefore, provides a new emulator Preference tab for specifying up to two simulated slots. Each slot is given a socket port number. The emulator then communicates with the smart card applications via socket protocol (see Figure 9).
|Figure 10. Setting Up Monitoring: To set up network monitoring between the smart card application running in the Cref simulator and a MIDlet running on the WTK emulator, open the Emulator Preferences window, select the Monitor Tab and make sure to enable network monitoring as shown.|
WTK 2.3 also ships with the Java Card Platform Simulator. It is the cref.exe application located in the WTK's \bin directory. With the SATSA slots and port numbers defined, you can test MIDlets running in the WTK emulator that communicate with Java smart card applications running on the Java Card Platform Simulator via the socket protocol. Of course, since it is just socket communications, a proxy can be set up to allow your MIDlets to talk with real smart card hardware and applications. In general, however, you would start cref.exe with the Java Card application you want to test, then start the WTK emulator and launch the appropriate MIDlet. The WTK emulator will use socket communications to exchange information with the cref.exe emulator and smart card application.
When the Java Card emulator is started, it too must be told to use the same port for communications. When starting cref.exe, pick the slot port (as set up in the emulator) that you want to give to the smart card application and provide it as a parameter to the start up command. In the example command to start the smart card emulator below, the default port for slot 0 (namely 9025) is associated with the smart card application.
cref –p 9025 –i myapplication.eeprom
The network monitor built into the WTK can be used to monitor data exchanged between the simulated smart card application and MIDlet running in the emulator. This can be quite helpful for debugging. To start a network monitor, open the WTK emulator Preferences window, select the Monitor tab and make sure the 'Enable network monitoring' is checked (see Figure 10
|Figure 11. The Network Monitor: Network traffic involved in the data exchanged between the smart card application running in the Java Card simulator and the MIDlet running in the WTK emulator will appear in the APDU tab of the Network Monitor.|
Now, run the MIDlet suite and launch a MIDlet in the emulator and the monitor window should appear. The data exchanged between the smart card simulator and the MIDlet emulator can be found on the APDU (which stands for Application Protocol Data Units) tab of the Network Monitor (see Figure 11).
WTK 2.3 comes with a MIDlet suite that demonstrates the SATSA API and WTK's support for SATSA. The demonstration suite is called Mohair (located in the apps directory of the WTK 2.3 download) and it has five MIDlets (each with associated smart card applications) for showing off the four packages of the Security and Trust Services API. Developing Java Card applications is beyond the scope of this article, but more information is available via the Java Card information link provided with this article.