Java Reference
In-Depth Information
also contains support for notification of the completion of asynchronous
operations back to the Java code.
So the layer in which the native services client usage resides (e.g.,
explicit usage of RFs and RFile APIs) is reached only after the code
execution crosses the Java, JNI and JES layers. This pattern of layers is
a recurring pattern in most JSR implementations (see Figure 11.3). We
chose to present it first with JSR-75 FileConnection as it is easier to
visualize this layer model with a fairly straightforward JSR.
Public JSR API
Java system classes layer
(Internal architecture)
KJNI layer
Synchronous C++ layer
Asynchronous C++ layer
(Event-Server)
Symbian OS client APIs
Figure 11.3
Recurring layers in JSR implementations
Conclusion
JSR-75 FileConnection has to be integrated with native Symbian OS
services as there is no other way to facilitate access to the file system.
Here we have seen a case of a straightforward integration where the Java
API maps well to the native Symbian OS service. We have also shown the
various layers of integration that are a recurring pattern in the integration
of most JSRs.
11.5.2 No Integration: JSR-172 Web Services
Strategically, integration with native Symbian OS services is the first
option when designing a new JSR implementation for the Java ME
subsystem on Symbian OS. However, there are cases where integration
with native services is neither applicable nor serves any requirement of
Java applications or the Java ME subsystem. We discuss such a case with
reference to JSR-172 Web Services.
A web service is a collection of APIs that can be accessed over the Inter-
net, to be executed on a remote system hosting the requested services.
Web services use XML to exchange data over standardized, open proto-
cols to ensure that the web services are interoperable and platform-neutral
