The Generic Connection Framework
J2SE has quite a wide and deep set of networking classes. In JDK 1.3, there are 21 classes, six interfaces, and eight exceptions in the networking package java.net. Many of these classes are interrelated and contain much more functionality than a simple portable device requires. This makes it very difficult to create a subset for the memory-constrained devices targeted by CLDC. The designers of the CLDC have generalized the networking features of J2SE, providing a uniform framework for supporting new devices and protocols that devices may require.
For basic networking, J2SE includes the classes such as Socket, HttpURLConnection, DatagramSocket, MulticastSocket, ServerSocket, InetAddress, URL, and URLConnection in the java.net package. Generally, each protocol is handled by a different class. For example, datagrams are implemented using the DatagramSocket class, and HTTP connections are handled by the HttpURLConnection class. However, in J2ME CLDC, the networking classes are quite different. None of the basic networking classes in J2SE exist in J2ME CLDC. Indeed, the java.net package does not exist. The GCF classes are located in a CLDC-specific package, called javax.microedition.io. In the GCF, a single class?the Connector class?handles all the supported networking protocols[1] of the device. The result is that an application's code is essentially the same no matter which protocol is used.
[1] Note that supported protocols are not specified at the configuration level. Specification of the protocols is left to the profiles. This is consistent with the notion that profiles specify features that take advantage of the device's capabilities.
The Connector class has several static methods, which are used to create connections. These methods are summarized in Table 7.1.
The general form of opening a connection is to use a static method on the Connector class, as follows:
Connector.open("<protocol>:[<target>][;<parameters>]");
static Connection open(String name) | Create and open a connection, using a URL. |
static Connection open(String name, int mode) | Create and open a connection, using a URL and mode (read, write, or read/write). |
static Connection open(String name, int mode, boolean timeouts) | Create and open a connection, using a URL, mode, and a flag to raise timeout exceptions. |
static DataInputStream openDataInputStream(String name) | Create and open a connection data input stream. |
static DataOutputStream openDataOutputStream(String name) | Create and open a connection data output stream. |
static InputStream openInputStream(String name) | Create and open a connection input stream. |
static OutputStream openOutputStream(String name) | Create and open a connection output stream. |
The format of the argument to the open method needs to be in accordance with standard URI syntax.[2]
[2] A URI is a Uniform Resource Indicator. The URI standard is defined in RFC2396, which can be found at http://www.ietf.org/rfc/rfc2396.txt. There is also a discussion on URIs in "Java Server & Servlets" by Peter Rossbach and Hendrick Schreiber, Addison-Wesley, 2000.
The <protocol> part of the parameter string represents the protocol to be used for the connection.
The optional <target> part of the parameter is interpreted according to the protocol. For network-oriented connections, <target> refers to an address. The address can be a hostname or an IP address. For protocols that are not network-oriented, the <target> may be interpreted more loosely. As an example of a protocol that is not network-oriented, in a future profile a supported protocol may be file:, and so the <target> may refer to the file name.
The optional <parameters> part of the string contains a semicolon-separated series of name-value pairs. For example, ";name1=value1;name2=value2".
Even though the MIDP specification mandates http only, http and https are supported in the J2ME Wireless Toolkit 1.0.3 release. The protocols socket, serversocket, comm, and datagram are supplied in experimental form. However, the only protocol provided for the Palm device is the MIDP-mandated http. The positive side of the minimal protocols for the Palm is that the code we write for the Palm will have the best portability across MIDP devices, as http is guaranteed to be available on all MIDP platforms.
Figure 7.1 shows the interfaces specified in the GCF, and how they relate to each other.
Figure 7.1. Static structure of the GCF interfaces
