Profiles
Configurations do not provide classes for managing the application life cycle, for driving the UI, for maintaining and updating persistent data locally in the device, or for accessing securely information that is stored on a network server. Instead, that type of functionality is provided by the profiles or by optional packages. A profile adds domain-specific classes to the core set of classes provided by the configuration, classes that are geared toward specific uses of devices and provide functionality missing from the underlying configuration.
At this writing, there are six profiles, three based on CLDC and three on CDC. The three standard CLDC-based profiles are the following:
- Mobile Information Device Profile (MIDP), versions 1.0, 2.0, and the upcoming 3.0
- Information Module Profile (IMP), versions 1.0 and 2.0
- Digital Set Top Box Profile
Not all these profiles are restricted to mobile handsets, with the latter targeted to digital set-top boxes.
The three profiles based on CDC are the following:
- Foundation Profile
- Personal Basis Profile
- Personal Profile
Figure 5 shows how profiles relate to their underlying configurations and to each other.
Figure 5: Java ME Profiles for CLDC and CDC
Multiple profiles can exist on top of the same configuration, as in the case of MIDP and IMP. They can also depend on or build on each other. For example, the Personal Profile extends the Personal Basis Profile, which in turn depends on the Foundation Profile. Expect more profiles to appear as Java ME technology evolves.
CLDC-Based Profiles
Of the profiles designed for CLDC, MIDP is the most prevalent. Although MIDP 2.0 has superseded MIDP 1.0 in capability, many devices still support only MIDP 1.0, so you should not ignore the older version. At the time of this writing, version 3.0 is being defined in the JCP program.
IMP promises to do for headless devices -- that is, those without display or UI facilities, such as vending machines, industrial devices, and security systems -- what MIDP has done for smart cell phones and low-end PDAs. There are two versions of IMP: Version 1.0 is based on MIDP 1.0, and the Next Generation (NG) version is based on MIDP 2.0.
Use of CLDC is not restricted to such devices, however. As Figure 6 illustrates, the Digital Set Top Box Profile (JSR 242) is a CLDC-based profile specifically defined for the cable market. Also referred to as OnRamp, this profile is based on a subset of the PersonalJava technology-based OpenCable Application Platform (OCAP), which defines a set of APIs for the development of applications for set-top boxes and similar devices.
Figure 6: Java ME Profiles for CLDC
OnRamp is quite large, with 31 Java packages and approximately 1500 APIs. But it is not as large as its superset, OCAP, which has approximately 8000 APIs. These include a subset from the Personal Basis Profile such as support for the Abstract Window Toolkit (AWT), Xlet, file access, and network APIs, as well as support for several media-related interfaces including Java TV, Java Media Framework (JMF), Digital Audio Visual Council (DAVIC), Home Audio/Video Interoperability (HAVI), Digital Video Broadcasting (DVB), and as previously mentioned, the OpenCable Application Platform (OCAP).
MIDP and IMP are so similar to each other that we'll review them together.
As the first Java ME profile, MIDP is the most mature and widely adopted, with millions of deployments all around the world, primarily on PDAs, cell phones, and other handheld communicators.
IMP's targets are devices with characteristics similar to those of MIDP devices but with little or no capabilities for UI: headless embedded devices in vending machines, industrial applications, and security systems. First defined by JSR 195, IMP borrows all of its functionality from MIDP, including application-management, storage, networking, security, and timer APIs. IMP 1.0 is a strict subset of MIDP 1.0, excluding the APIs for UI, specifically javax.microedition.lcdui. IMP applications are called IMlets, but for all intents and purposes, they are MIDP applications or MIDlets: They subclass MIDlet and have the same packaging, deployment, security features, and life cycle as MIDlets.
MIDP 1.0 was introduced in JSR 37 and is still in wide use. MIDP 2.0, defined by JSR 118, enhanced the profile's capabilities. To the original APIs for networking, UIs, local persistence, and MIDlet life cycle, MIDP 2.0 added new networking APIs to support TCP socket streams and UDP datagrams,as well as serial, push-initiated, and secure connections. Other additions include a robust security API and policy, as well as APIs for sound and gaming.
The MIDP 2.0 profile specification also includes an update of the Over-the-Air (OTA) User-Initiated Provisioning recommendation that was originally defined as an addendum to the MIDP 1.0 specification, which describes how users can discover and download applications over wireless networks. Even though the MIDP specification indicates the use of CLDC 1.0, nothing precludes use of CLDC 1.1 as the base for either version of MIDP.
At this writing, IMP is undergoing its first revision. JSR 228, also known as IMP-NG, is IMP's next generation. It will take advantage of MIDP 2.0's new security and networking types and APIs, and other APIs such as PushRegistry and platformRequest(), but like IMP 1.0, it will not include any of the UI, game, or media APIs. Table 3 summarizes the device requirements for MIDP and IMP.
Table 3: Device Requirements for CLDC-Based Profiles
Requirement
Profile
MIDP 1.0
MIDP 2.0
IMP 1.0
IMP-NG
Display
Screen size
96x54
Same as MIDP 1.0
N/A
Same as IMP 1.0
Depth
1 bit
Same as MIDP 1.0
N/A
Same as IMP 1.0
Aspect ratio
1:1
Same as MIDP 1.0
N/A
Same as IMP 1.0
Input
One or two-handed keyboard, or touch screen
Same as MIDP 1.0
N/A
Same as IMP 1.0
Memory
Nonvolatile, in addition to what CLDC requires
128 KB
256 KB
128 KB
128 KB
Nonvolatile memory for application-created persistent data
8 KB
8 KB
8 KB
8 KB
Volatile memory for the Java runtime
32 KB
128 KB
32 KB
128 KB
Networking
Two-way, wireless, possibly intermittent, with limited bandwidth
Same as MIDP 1.0
Same as MIDP
Same as MIDP
Power
Limited, typically battery-operated
Same as MIDP 1.0
Same as MIDP
Same as MIDP
Table 4 summarizes the packages available in both versions of MIDP and in IMP 1.0.
Table 4: Packages in the CLDC-Based Profiles
Name
Description
MIDP 1.0
MIDP 2.0
IMP 1.0
java.lang
MIDP subset of the core Java programming language
X
X
X
java.util
Small subset of utility classes
X
X
X
java.io
MIDP subset of system input and output through data streams
X
X
X
javax.microedition.io
Networking support using the Generic Connection Framework; includes new socket, UDP, serial, and secure connection types, as well as push functionality
X
X
X
javax.microedition.lcdui
MIDP classes for UI
X
X
javax.microedition.lcdui.game
Gaming classes such as sprites, game canvas, and layer manager
X
javax.microedition.media
Interfaces for controlling (Control) and rendering (Player) audio -- sound classes compatible with the Mobile Media API specification (JSR 135)
X
javax.microedition.media.control
Sound-control classes (ToneControl and VolumeControl) -- compatible with the Mobile Media API specification (JSR 135)
X
javax.microedition.midlet
Application interface, life-cycle classes, and interactions with the runtime environment and application manager
X
X
X
javax.microedition.pki
Public key class for certificates used to authenticate information for secure connections
X
X
javax.microedition.rms
Classes for storing and retrieving persistent data
X
X
X
For more information on the profiles based on CLDC, read the articles What's New in MIDP 2.0 and The Information Module Profile.
CDC-Based Profiles
A richer configuration than CLDC, CDC is aimed at higher-end handheld and embedded devices, those with more memory and more processing power, but the configuration and profile pattern are the same. CDC provides a generic, low-level interface to the device, and one or more CDC-based profiles provide classes whose capabilities are appropriate to particular categories of devices. You've already seen that the Foundation Profile, Personal Basis Profile, and Personal Profile build on each other, as illustrated in Figure 7.
Figure 7: Java ME Profiles for CDC
The Foundation Profile includes all the classes in CDC and adds more Java SE classes, security features, and other APIs. The Personal Basis Profile includes all of CDC and Foundation Profile, and then adds a minimum core set of UI classes, among other features. The Personal Profile incorporates all of CDC, Foundation Profile, and Personal Basis Profile, and it provides a more complete set of the Abstract Window Toolkit (AWT) API, including its heavyweight APIs and support for applets.
The Foundation Profile
The Foundation Profile is a base for building other CDC-based profiles. In addition to providing all of CDC's interfaces and classes, the Foundation Profile extends the configuration by adding security, utility, and locale classes.
Because the Foundation Profile does not provide any UI classes -- no AWT, no Swing -- it is the profile of choice for small devices that don't need a UI, such as headless, dedicated, connected, and embedded devices. Table 5 summarizes the Foundation Profile's Java packages.
Table 5: Packages in the Foundation Profile
Name
Description
All the packages in CDC
See Table 2
java.lang
The core Java programming language
java.lang.ref
Reference-object classes, which support a limited degree of interaction with the garbage collector
java.lang.reflect
Classes and interfaces for obtaining reflective information about classes and objects
java.math
Subset of classes for performing arbitrary-precision integer arithmetic
java.text
Classes and interfaces for handling text, dates, numbers, and messages in a manner independent of native languages
java.util
Set of generally useful classes such as collections, event model, date and time facilities, internationalization, and miscellaneous utility classes
java.util.jar
Classes for reading and writing the Java archive (JAR) file format, which is based on the standard ZIP file format, with an optional manifest file
java.util.zip
Classes for reading and writing the standard ZIP file format
java.io
Subset of system input and output APIs through data streams, serialization, and the file system
java.net
Classes for implementing networking applications; support for all CDC protocols (datagram: and JAR), as well as socket: and http:
java.security
Classes and interfaces for the security framework
java.security.acl
Access Control List support. Note: Some classes and interfaces in this package have been superseded by classes in java.security
java.security.cert
Classes and interfaces for parsing and managing certificates
java.security.interfaces
Interfaces for generating RSA PKCS#1 keys and DSA NIST's FIPS-186 keys
java.security.spec
Classes and interfaces for key and algorithm parameter specifications
javax.microedition.io
Network support based on the Generic Connection Framework; support for all CDC protocols (file: and datagram:), as well as socket: and http:
Version 1.0 of the Personal Basis Profile was defined in JSR 129. More recently, version 1.1 was introduced in JSR 217, which is still in progress.
Differences Between Foundation Profile 1.0 and 1.1
The two versions of Foundation Profile are very similar. Existing APIs are being cleaned up. Enhancements are mainly centered on support for J2SE 1.4, including support for the next generation of the Internet Protocol IPv6, and java.net.URI.
The Personal Basis Profile
The Personal Basis Profile builds on the Foundation Profile and is a subset of the Personal Profile. In addition to providing all CDC and Foundation Profile interfaces and classes, the Personal Basis Profile includes a lightweight subset of the AWT that supports graphics, images, and widgets on devices that require a simple UI, such as automotive devices, consumer devices, and simple appliances. This profile also supports JavaBeans programming and a new Xlet application model. Table 6 summarizes the Java packages in the Personal Basis Profile.
Table 6: Packages in the Personal Basis Profile
Name
Description
All the packages in CDC and Foundation Profile
java.awt
Subset of classes for creating simple UIs and for painting graphics and images
java.awt.color
Subset of classes for manipulating colors
java.awt.event
Subset of interfaces and classes for handling events fired by AWT components
java.awt.image
Subset of classes for creating and modifying images
java.beans
Subset of classes related to JavaBeans development
java.rmi
Subset of RMI classes to support inter-Xlet communication
java.rmi.registry
Subset of RMI classes to support inter-Xlet communication
javax.microedition.xlet
Defines new Xlet application model, life-cycle classes, and interactions with the application manager
javax.microedition.xlet.ixc
Defines classes for inter-Xlet communication
Version 1.0 of the Personal Basis Profile was defined in JSR 129. More recently, the Personal Basis Profile 1.1 was introduced in JSR 217, which is still in progress.
Differences Between Personal Basis Profile 1.0 and 1.1
Version 1.1 is very similar to the original version. Existing APIs are being cleaned up. Enhancements are mainly centered on J2SE 1.4 support, including changes related to graphics and UI.
The Personal Profile
The Personal Profile is the new embodiment of the PersonalJava application environment, now at the end of its product life. The Personal Profile is a superset of the Personal Basis Profile and provides all the Java packages in both CDC and the Foundation Profile. It then adds heavyweight AWT classes and applet support missing from the Personal Basis Profile.
The Personal Profile thus provides a more complete application environment and looks very similar to Java SE. It is aimed at devices that require advanced UI and secure network connectivity, such as high-end PDAs, set-top boxes, and other high-end appliances. Table 7 summarizes the Personal Profile Java packages.
Table 7: Packages in the Personal Profile
Name
Description
All packages in CDC, Foundation Profile, and Personal Basis Profile
See Table 2, Table 5, and Table 6
java.applet
Classes needed to create an applet, as well as classes that an applet uses to communicate with its applet context
java.awt
Adds the heavyweight AWT components: Component, Menu, Button, Choice, and so on
java.awt.datatransfer
Subset of interfaces and classes for transferring data between and within applications
Personal Profile 1.0 was defined in JSR 62. More recently, Personal Profile 1.1 was introduced in JSR 216, which is still in progress.
Differences Between Personal Basis Profile 1.0 and 1.1
Version 1.1 is very like version 1.0. Existing APIs are being cleaned up. Enhancements are mainly centered on J2SE 1.4 support, including changes related to graphics and UI.
For a handy comparison of APIs in CDC and its profiles to the corresponding Java SE interfaces, see the CDC API Comparison (PDF).
Optional Packages
Optional packages are very important components of the Java ME platform. You can look at them as profile extensions. They provide support in relatively narrow areas of functionality that some devices and applications need but others don't, such as messaging, multimedia, and location services.
With optional packages taking over such burdens, profiles can concentrate on supporting only those capabilities that most or all devices in a class need. Profiles can supply the runtime environment, while optional packages supply specific kinds of functionality, some of which were not even envisioned when the profiles were designed.
All Java ME optional packages are defined by the JCP, making them standard APIs. As the name implies, inclusion of these packages is optional. Some are mandatory, while others are conditionally mandatory as defined by the JCP. Still others are optional as defined by the handset manufacturers that may choose to include them in a particular product, or in extensible environments such as PDAs on which developers may elect to include them. For example, in a particular MIDP handset that has hardware support for Bluetooth, the Java APIs for Bluetooth (JSR 82) might be present.
The number of optional packages is increasing, with some for CLDC environments, some for CDC, and some for both. Some are already approved, and many new ones are in the definition phase. For this purpose, the MSA specification defines a common architecture and programming platform for wireless handsets. Two flavors of MSA are defined: the basic MSA that addresses CLDC-based platforms, and MSA-Advanced that addresses CDC-based platforms.
No comments:
Post a Comment