The MIDP Networking Model in J2ME

By: Emiley J Emailed: 1643 times Printed: 2112 times    

Latest comments
By: rohit kumar - how this program is work
By: Kirti - Hi..thx for the hadoop in
By: Spijker - I have altered the code a
By: ali mohammed - why we use the java in ne
By: ali mohammed - why we use the java in ne
By: mizhelle - when I exported the data
By: raul - no output as well, i'm ge
By: Rajesh - thanx very much...
By: Suindu De - Suppose we are executing

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.


J2ME Home | All J2ME Tutorials | Latest J2ME Tutorials

Sponsored Links

If this tutorial doesn't answer your question, or you have a specific question, just ask an expert here. Post your question to get a direct answer.



Bookmark and Share

Comments(3)


1. View Comment

Hi,
this is excellent stuff and I highly appreciate your efforts. Consider giving a generic solution or code base to the problems posted by users / developers who post their issues here? Not a bad idea I guess.
Still, a best of the efforts have been made so far.


View Tutorial          By: Nanda at 2007-11-02 04:58:30
2. View Comment

i want daily tutorials

View Tutorial          By: ashish at 2007-12-18 04:26:19
3. View Comment

Thanks a lot .. Great work!!

View Tutorial          By: MonamAlwerfally at 2013-03-26 14:41:29

Your name (required):


Your email(required, will not be shown to the public):


Your sites URL (optional):


Your comments:



More Tutorials by Emiley J
Password must include both numeric and alphabetic characters - Magento
What is Hadoop?
Returning multiple values from a web service
Tomcat and httpd configured in port 8080 and 80
Java Webservices using Netbeans and Tomcat
Java WebService connected to Database
How to Deploy a Java Web Service
Call a webservice in Java
Java WebService - Create your first web service in Java
package javax.jws does not exist
Getting Started with Android
HTML5 Location - getCurrentPosition() in HTML5
HTML5 Canvas - Using Canvas in HTML5
HTML5 - Introduction
HTML5 Video - Handling video in HTML5

More Tutorials in J2ME
Code sample to Send SMS from a J2ME application.
Adding your own Application icon for your J2ME application (jar file)
Play a multimedia file in J2ME Program (Audio/Video) using MMAPI
Datagrams in J2ME (UDP Programming sample)
Client Server in J2ME (Socket Programming sample)
Using HttpConnection in J2ME (Retrieve web content from a website to a phone)
Using HTTP vs UDP vs Socket in J2ME
RMSCookieConnector - Using Cookies in J2ME
POST UTF-8 encoded data to the server in J2ME
lists, forms, choices, gauges, text fields, text boxes in J2ME
Using List to create a Menu and Menu items in J2ME
Using alerts and tickers in J2ME
J2ME Canvas sample to show games programming in J2ME
Timer and TimerTask example in J2ME
List of GPRS Access points for all countries

More Latest News
Most Viewed Articles (in J2ME )
Using HttpConnection in J2ME (Retrieve web content from a website to a phone)
List of GPRS Access points for all countries
Download a file over a network in J2ME midlet
RMS Basics in J2ME
Code sample to Send SMS from a J2ME application.
Using List to create a Menu and Menu items in J2ME
Client Server in J2ME (Socket Programming sample)
What is J2ME?
Adding your own Application icon for your J2ME application (jar file)
GUI components and menu based J2ME Applications.
lists, forms, choices, gauges, text fields, text boxes in J2ME
Using HTTP vs UDP vs Socket in J2ME
Sample J2ME code that shows various functionality of RMS.
A sample J2ME midlet that shows an example of using a Timer and a TimerTask.
How to get the CLDC and MIDP version from a J2ME program
Most Emailed Articles (in J2ME)
How to load J2ME applications to the IDEN handsets
POST UTF-8 encoded data to the server in J2ME
Adding your own Application icon for your J2ME application (jar file)
What is J2ME?
Download a file over a network in J2ME midlet
A sample J2ME midlet that shows an example of using a Timer and a TimerTask.
paint() sample program to draw a line in J2ME
Client Server in J2ME (Socket Programming sample)
Using HttpConnection in J2ME (Retrieve web content from a website to a phone)
What is J2ME?
Sample Java program shows how to Read a file over a network using J2ME midlet
Gauge sample program in J2ME
Using List to create a Menu and Menu items in J2ME
Datagrams in J2ME (UDP Programming sample)
Using HTTP vs UDP vs Socket in J2ME