Java Reference
In-Depth Information
This set of interfaces goes down as far as possible to the underlying
low-level functionality of the JSR, which leaves all of the higher-level
functional responsibilities of the JSR to be handled by the Java ME
subsystem itself (either in the Java system classes layer or in one of the
native layers) as shown in Figure 11.6. The licensee's implementation of
the APDU Bridge classes does not need to be aware of either the Java
application triggering the operations on the SIM card or the Java ME
subsystem.
APDUConnection
from javax.microedition.apdu
Java implementation layer
(Internal architecture)
Native implementation layer
(KJNI, Java Event Server)
Bridge abstraction layer
Bridge implementation layer
(Licensees DLL)
Figure 11.6
Implementation architecture layers of SATSA JSR-177 APDU
The upper layer in Figure 11.6 is the Java code layer, internal
to the Java ME subsystem, that breaks down the functionality of
the
javax.microedition.apdu.APDUConnection
into a few Java
classes. For simplicity, the JSR-177 SATSA APDU package defines a
single interface which abstracts functionality which is non-trivial and
even quite complex. This requires the APDU package implementation
to decouple the support into several Java classes, each of which has
a single responsibility (e.g., smart card and slots, SIM-related security,
APDU commands and responses, APDU validation). As expected, the
internal Java package that implements the functionality support of the
javax.microedition.apdu.APDUConnection
is integrated into
the Java ME subsystem's GCF internal framework.
Between the Java code layer and the licensees' interfaces implemen-
tation DLL, there is a layer of native C and C++ code whose role is
not to do any processing specific to the JSR functionality, but to provide
the required layer of the Java ME subsystem's solution to the Symbian
OS asynchronous programming idiom that was discussed in Chapter 10
(e.g., handling Symbian OS asynchronous operations using the Java Event
Server).
All of the code mentioned so far is built into the VM executable while
the implementation of the native interfaces is loaded from the DLL which
is provided by the licensees.
