In MIDP, as in J2SE, IO streams are the primary mechanism
available to applications to read and write streams of data. Both J2SE and J2ME have a java.io package
that contains these stream classes. Additionally, the MIDP defines the
javax.microedition.io package, which supports networking and communications for MIDP applications.
This package is in contrast to the J2SE java.net package, which defines networking support on
that platform. MIDP applications use the javax.microedition.io types to create
and manipulate various kinds of network connections. They then read from these
connections and write to them using the types in the MIDP java.io package, which contains a subset of
the classes and interfaces in the J2SE java.io package.
Perhaps the single most important goal of MIDP networking is to
abstract the heterogeneous nature, complexity, and implementation details of the plethora
of different wireless network environments. Achieving this goal requires insulating
application developers from exposure to the characteristics of the network.
The MIDP Generic Connection Framework
The MIDP generic connection framework defines an
infrastructure that abstracts the details of specific networking mechanisms, protocols, and their
implementations from the application. In the generic connection model, an application makes a request to a connector
to return a connection to the target resource. To make a connection, you use a generically
formed address to specify the target network resource. The form of the address is the same,
regardless of the type of connection desired.
The connector represents the actual connection returned as a generic
connection. That is, it characterizes the connection as one that has the lowest common
denominator of attributes and behavior of all connection types.
Applications make all such connection requests through the same
connector, regardless of the type of connection desired. The connector abstracts the details of
setting up a specific type of connection. The connector provides only a single interface for
obtaining access to network resources, regardless of the nature of the resource or the
protocol used for the communication. The term generic connection thus refers to the generic
mechanism used to obtain access to resources, not to the content or type of the established connection.
In the MIDP generic connection model, you identify the resource
and get a connection to it in one step. This contrasts with the J2SE model, where the application
must involve two objects: one that represents the target resource itself, with the other object
being the stream or connection to it. For instance, to access a URL in J2SE, an application constructs
a java.net.URL object, which represents the actual URL resource. Using this object, the
application then explicitly opens a connection to the URL resource, which yields a URLConnection
object. This object represents the actual connection between the application and the resource
and provides the medium through which the application accesses the contents of the resource.
Now, the application can obtain an input stream from the connection that delivers the content of
The URL class knows how to access the physical resource. The
connection object, on the other hand, knows nothing about locating and opening a URL, but it
does know how to interface to a URL object. You, as the programmer, must understand what object
to use to access the URL and what connection or stream interfaces to it.
In general, the J2SE model requires the programmer to build a
stream that's compatible with the type of resource being accessed—a URL, file, a network socket,
a datagram, and so forth. The J2SE model doesn't abstract these details from the application.
In the MIDP model, streams behave the same as in the J2SE model;
they still don't know anything about the actual physical network resource. They simply know how
to manipulate the content given to them when they were instantiated. The connector,
however, hides from the application the details of interfacing the stream with the actual network
There are two main advantages to the generic connection
framework model. First, it abstracts the details of connection establishment from the application.
Second, this abstraction makes the framework extensible. By using a standard, extensible mechanism
for referencing network resources, MIDP platform implementations can be enhanced to
support additional protocols while maintaining a single mechanism for applications to access all
kinds of resources. Moreover, application logic remains independent of networking mechanisms.
To use the generic connection framework, MIDP applications
specify the network resource they want to access by using a universal resource identifier (URI),
which follows the Internet standard URI syntax defined by RFC 2396. A URI supports a canonical
syntax for identifying resources on the Internet. The generic form of a URI is
Part of a URI is its scheme field, which represents the
protocol to be used for the connection. RFC 2396 supports a plethora of valid schemes, such as file,
datagram, socket, serversocket, http, ftp, and so forth.
The CLDC doesn't specify support for any of these. The reason is
that the CLDC specification doesn't allow customizations. Therefore, all CLDC
implementations must support the same features. MIDP implementations, however, can implement as many
customizations as desired. The MIDP specification does require that implementations at least
support the HTTP 1.1 protocol, however. Several factors influence the availability of protocol
support in MIDP implementations:
- Performance limitations in wireless networks, connection
establishment time, bandwidth, and latency constrain the types of networking communications
that are feasible when compared with fixed networks.
- Client-side software (on the mobile device) dictates the
kinds of connection schemes that can be supported. Mobile devices currently don't have the
resources to support processing for general types of networking connections or application level
- Wireless Internet portals make heavy use of HTTP as their
primary application-level communications mechanism.
A MIDP platform implementation provides the actual
implementation of support for protocols.
These protocol implementations aren't part of the MIDP or CLDC
Connectors and Connections
Figure above shows a schematic representation of the steps
involved in the creation and use of a connection. These steps, which we list next, correlate to the
notation in the Figure
- The application requests the Connector class to open and
return a connection to a
- The Connector.open() factory method parses the URI and
returns a Connection
object. The returned Connection object holds references to input
and output streams to
the network resource.
- The application obtains the InputStream or the OutputStream
object from the
- The application reads from the InputStream or writes to the
OutputStream as part
of its processing.
- The application closes the Connection when finished.
A connection object contains an input stream and an output
stream for reading and writing to the resource, respectively. Figure represents schematically the
relationships between the connection and its two streams.
Once you have the connection, you use its two streams to
interact with the network resource. There are two aspects to communicating with a network resource:
• parsing the protocol message
• parsing the message payload—the message content
For example, if the client establishes an HTTP connection, the
client must parse HTTP protocol syntax and semantics of the response message returned by the
server. The HTTP message transports some kind of content, and the client must also be
able to parse the content appropriately. If, for example, the message content is HTML data, the client
must properly parse HTML content. If the application doesn't know the format of the data delivered
by the input stream, it cannot correctly interpret either the syntax or semantics of the stream
The MIDP generic connection framework defines a hierarchy of
connection types that capture the nature of different kinds of stream connections. That is, the
different types represent different protocols used by connections. Using the appropriate connection
type makes it easier to parse and manipulate different kinds of content. For example, HTTP
connections are a mainstay of MIDP networking communications. The generic connection framework
defines a connection type whose interface supports constructing HTTP requests and parsing HTTP