to a smart-card device. Java ME applications can use this interface to com-
municate with applications on a smart card using the request-response
APDU application-level protocol.
The Symbian OS Telephony subsystem has an abstraction layer for only a
subset of the APDU package's required functionality. Symbian's (U)SAT
ETel API (e.g., RSat , which inherits from RTelSubSessionBase and
is defined in etel.h ) offers access to the (U)SIM Application Toolkit on
GSM networks and to the CDMA Card Application Toolkit (CCAT) on
CDMA networks. The (U)SAT and CCAT allow the card to be more than
just a storage device; they define a protocol that allows the card to ask the
phone to perform tasks such as displaying a message on the screen, adding
items to the phone's menus, dialing a number, or browsing to a URL.
However, the (U)SAT ETel API does not satisfy JSR-177 APDU require-
ments. (U)SAT is only a partial and optional requirement of the JSR and
that leaves a big functionality gap between the native support and the
required Java ME JSR functionality. It is clear that the available Symbian
OS services cannot satisfy the JSR's mandatory integration requirements
and another native library is required. We discuss how the Java ME
subsystem solves the integration challenge with another library to which
Symbian OS licensees have access.
The Java ME subsystem uses a variant of the Bridge design pattern (see
Figure 11.5 and [Gamma etal. 1994]). A limited set of pure abstract C++
classes (M classes in the Symbian C++ idiom) has been defined and has
to be implemented by Symbian OS licensees or network operators in a
separate DLL that is loaded the first time a SIM application is selected.
Figure 11.5 Applying the Bridge design pattern to the JSR-177 SATSA APDU