Java Reference
In-Depth Information
11.2 Types and Levels of Integration
System integration is the bringing together of different subsystems, which
are not necessarily heterogeneous, into one unified system that has
a uniform behavior and functionality. In a system that hosts multiple
application execution environments and is tightly integrated, the same
functionality in two applications running in different execution environ-
ments should not be different from each other. Each of the execution
environments would internally use the same underlying services, which
ensures that the functionality and behavior across the different environ-
ments is uniform. Ideally, an end user would not be able to distinguish
between applications that run in different execution environments.
Using this definition of system integration, we can deduce that the
integration of the Java ME subsystem JSRs onto Symbian OS native
services is meant to provide a consistent experience to end users. This
goal is achieved by making public Java ME APIs to produce a unified
set of functionality and behavior with native applications, by integration
with the native Symbian OS services.
At one extreme, a JSR does not need to collaborate with native
Symbian OS services and thus avoids the whole integration issue entirely.
However, such an integration approach is feasible or acceptable only
for a very small number of JSRs. At the other extreme, for each Java
method, we call an equivalent Symbian C++ method. Such a one-to-one
mapping cannot be considered realistic due to the differences in concepts,
architectures, and idioms between Java ME and Symbian OS. Between the
extremes of those two integration approaches, there are other approaches
for integrating JSRs. Each integration approach addresses some of the JSR
and integration requirements in a different way. The more likely approach
is that integration is driven by JSR functionality, rather than by mapping
Java classes to native classes.
A specific JSR is integrated with the relevant Symbian OS subsystem in a
way that ensures that the functionality and use cases are handled using
native primitives. In other words, the correct view of an integration
approach is not to map the JSR classes to native classes but to map the
JSR functionality to native functionality using the native classes.
In the case of a network protocol, if the run-time environment uses
the underlying native services that support this network protocol, we
can say that the run-time environment's support for the network protocol
is tightly integrated to the system. If native APIs are not available for
a given network protocol, the run-time environment is not necessarily
prevented from supporting the network protocol and exposing it to hosted
applications. For example, in the case of an application-level protocol,
