Programming Tutorials

The MIDP Networking Model in J2ME

By: Emiley J  

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 resource.

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 resource.

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

<scheme>://<address>;<parameters>

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 protocols.
• 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 specifications. 

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 

1. The application requests the Connector class to open and return a connection to a
   network resource.
2. 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.
3. The application obtains the InputStream or the OutputStream object from the
   Connection object.
4. The application reads from the InputStream or writes to the OutputStream as part
   of its processing.
5. 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 content.

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 responses.

Archived Comments