See: Description
Interface | Description |
---|---|
IMCConnection |
This interface defines a low-level asynchronous bi-directional stream
connection for the Inter-MIDlet Communication protocol (IMC), used for
communication between applications.
|
IMCServerConnection |
This interface defines a server connection for the Inter-MIDlet Communication
(IMC) protocol that is used for communication between applications.
|
Class | Description |
---|---|
IMCProtocolPermission |
This class represents access rights to connections via the "imc" protocol.
|
PushRegistry |
The
PushRegistry maintains a list of inbound
connections. |
PushRegistryPermission |
The PushRegistryPermission class is used to check the static and dynamic
registration of push connections and for registration of an alarm.
|
Exception | Description |
---|---|
QoSException |
This exception is thrown if the QoS (quality of service) parameter as
specified by
ConnectionOption s cannot be fulfilled when establishing
the connection, or cannot be fulfilled anymore for an existing connection. |
null
argument to a constructor
or method an any class or interface in this package MUST cause a
NullPointerException
to be thrown.
java.io.IOException
MUST be thrown.
IMCConnection
and
IMCServerConnection
.
Very similar to the socket protocol, the IMC protocol provides for both client and server connection. When an IMC client makes a connection to a server, the IMC server is identified by application UID, and the IMC server name and version. The application UID is the unique identifier of an application, composed of the combination of the application's name, vendor, and version. The application UID is omitted in the connection URL strings when opening an IMC server connection.
The Inter-MIDlet Communication protocol (IMC) MUST be supported by all implementations
that include this javax.microedition.io
LIBlets enable applications to share software components; however, an
application and the LIBlets it depends upon are statically bound at installation
into a single isolated runtime execution environment.
Further, code belonging to a single LIBlet and bound to multiple application's
execution environments cannot easily exchange data at runtime.
With the introduction of Inter-IMlet communication, an application will be able to access a shareable component running inside another execution environment through thin client APIs, and thus make possible component based programming for applications. The shareable component runs inside another application execution environment and handles requests from other applications.
An example use case for Inter-application communication is a sensor data collector. In this use case, an application controlling a technical facility based on incoming sensor data invokes sensor data collecting applications through an IMC connection in order to receive the collected and processed sensor data needed. These sensor data collecting applications are executed as if they were LIBlets bound to the Controller application, but can be individually installed or deleted and run inside isolated execution environments.
An application starting an IMC server can be launched in the background when the device is powered on, or at client request. Unlike LIBlet code static sharing, an application's IMC server can be independently shut down and unloaded from memory if it is no longer serving client requests. An IMC server can use all of the APIs available to an applications including, when appropriate and available, interactions with the network or user.
PushRegistry
is available to
provide an application with a means to register for network connection events,
which are delivered to the application if it is running or start the
application if it is not running and then deliver the network connection event.
The security of PushRegistry is defined by the
Auto-Invocation Security Policy.
The risks associated with an application application’s use of the network are related the potential for network abuse and to costs to the device owner since network use may result in charges. This specification provides a security framework in which network functions can be protected and allowed only to those applications that are bound to a Security Protection Domain containing the appropriate permissions.
SocketConnection
and ServerSocketConnection
SocketConnection
and
ServerSocketConnection
as defined in CLDC-8. The
implementation of SocketConnection
has to support the following
additional settings for calls to Connector.open
:
ConnectionOption | Type | Sample Value |
---|---|---|
sendingDelayVariation | Integer | 50 |
receivingDelayVariation | Integer | 50 |
sendingLatency | Integer | 100 |
receivingLatency | Integer | 100 |
sendingLevelOfGuarantee | Integer | impl. dependent |
receivingLevelOfGuarantee | Integer | impl. dependent |
sendingPeakBandWidth | Integer | 5242880 |
receivingPeanBandWidth | Integer | 5242880 |
sendingTokenBucketSize | Integer | 1048576 |
receivingTokenBucketSize | Integer | 1048576 |
sendingTokenRate | Integer | 4194304 |
receivingTokenRate | Integer | 4194304 |
sendingProviderSpecificQos | Byte[] | impl. dependent |
receivingProviderSpecificQos | Byte[] | impl. dependent |
sendingDelayVariation
and receivingDelayVariation
can be used
to specify the tolerable jitter for data sending/receiving operations.
sendingLatency
and receivingLatency
can be used to specify
the maximum acceptable delay between sending and receiving in microseconds
for data sending/receiving operations.
sendingLevelOfGuarantee
and receivingLevelOfGuarantee
can be
used to specify the desired QoS for data sending/receiving operations. Values
for the level of guarantee are implementation dependent. Proposed and
recommended value examples could be :
sendingPeakBandWidth
and receivingPeakBandWidth
can be used
to specify the maximum bandwidth in bytes per second for data sending/receiving
operations, which can be sent until the bucket is empty.
sendingTokenBucketSize
and receivingTokenBucketSize
can be used
to specify (together with the token rate) the burstiness of the datastream
for data sending/receiving operations.
sendingTokenRate
and receivingTokenRate
can be used to specify
the average bytes per second to be sent for data sending/receiving operations.
sendingProviderSpecificQos
and receivingProviderSpecificQos
can be used to specify provider specific QoS parmaters for data sending/receiving
operations. The possible values are implementation dependent.
The implementation of ServerSocketConnection
has to be extended
in a way that it accepts (or does not accept) the required QoS characteristics
and negotiates the QoS related conditions with the socket side.
ConnectionOption <Integer> sendingLatency =
new ConnectionOption<Integer>("sendingLatency", 200);
ConnectionOption <Integer> receivingLatency =
new ConnectionOption<Integer>("receivingLatency", 100);
ConnectionOption <Integer> sendingTokenRate =
new ConnectionOption<Integer>("sendingTokenRate", 4194304);
ConnectionOption <Integer> receivingTokenRate =
new ConnectionOption<Integer>("receivingTokenRate", 4194304);
try {
SocketConnection c = (SocketConnection)Connector.open(
url, sendingLatency, receivingLatency,
sendingTokenRate, receivingTokenRate);
} catch (IOException e) {
// ...
}
Copyright (c) 2013, Oracle and/or its affiliates. All Rights Reserved. Use of this specification is subject to license terms.