Mobility Resources Search Box

Relevant mobility-specific web search.

The Concern with CLDC-based Profiles Today

by C. Enrique Ortiz, August 11, 2004

To "profile" or not to "profile". That is the question. There is the Mobile Information Device Profile (MIDP), and the Information Module Profile (IMP). And most recently the new Set-top box (STB) profile JSR was submitted to the JCP. In this essay we briefly explore CLDC-based profiles today, and the concern that CLDC-based profiles are being defined without proper forward-looking organization or structure. Over the last 5 years the J2ME platform, and especially the CLDC and MIDP, have become a proven application platform with millions of deployments - it is time to address any organizational issues now, before the problem gets compounded.

Organization

Java[TM] is owned by Sun Microsystems. Java evolves via the Java Community Process (JCP). Enhancements to Java are done by companies or individuals who submit to the JCP a Java Specification Request (JSR). The JCP is governed by executive committees (EC): there is one committee for J2EE, one for J2SE and one for J2ME. Committee members are elected members consisting of companies or individuals with a common interest. The EC is responsible for accepting or rejecting submitted JSRs based on criteria such as usefulness, duplication, API fragmentation, or lack of clarity/purpose.

The J2ME architecture is organized as a software stack with functionality increasing as we move up the stack. This organization is the result of JSR-68, which defines the organization of J2ME. This architecture or software stack consist of configurations, profiles and optional packages:

Figure 1. J2ME Organization

At the bottom of the stack we have the hardware and operating system. As we move up we have configurations which "contain" the JVM and core Java packages, and as we move up we find higher-level definitions (the profiles) that define device characteristics and supported APIs such as UI, networking and storage APIs. Profiles addresses the characteristics and common functionality for a specific device-type such as a cellphones, headless devices, or set-top boxes. Optional packages extend profiles with extension APIs, for example, messaging or multi-media APIs - the original idea was for profiles to define the base functionality for a device-family, and optional packages to provide extended functionality. At the top of the stack is the application itself.

The Concern

Note the above definition of a profile: "Profiles addresses the characteristics and common functionality for a specific device-type such as a cellphones, headless devices, or set-top boxes". This is exactly how profiles are being defined today: MIDP for cellphones, IMP for headless devices, and STB profile for set-top boxes. But if we look a bit closer, we will see that some of these profiles are a complete subset of an existing profile (see IMP). The reason for this is historical - MIDP was defined first. The concern is that we are not building functionality up the stack - but instead decomposing MIDP down, without defining a base or foundation set of functionality (profile) for CLDC, without proper forward-looking organization or structure. This introduces some issues, for example:

The challenge (and cost) associated with keeping dependent profiles synchronized over-time..
Duplication of functionality, for example, the basic MIDP multimedia API vs. JSR-135 MM API optional package.
New unnecessary profiles; profile creep.

The number of profiles shall be kept to a minimum, while leveraging optional packages as much as possible.

Some Background

J2ME is broken into 2 branches: the Connected Device Configuration (CDC) and related profiles, and the Connection, Limited Device Configuration (CLDC) and related profiles.

In the case of CDC, profiles are neatly defined/separated: we have a Foundation Profile that provides the base/minimal functionality (minimal networking, no UI API, basic Java APIs), moving up we have the Personal Basis Profile that add some UI APIs and other functionality. And we have the Personal Profile which is basically J2SE 1.3 or 1.4 for CDC 1.0 or 1.1 respectively. In addition there are optional packages, such as support for JDBC APIs.

For the CLDC we have the MIDP that is mainly targeted at cellphone-like and low-end PDAs type of devices. We have the IMP, which can be viewed as parallel to MIDP; IMP is MIDP with UI APIs removed. And there is a new Set-top box profile (JSR-242), that as the name implies, is targeted at set-top boxes (note: I am not sure how the set-top box profile relates or not to MIDP or IMP). On CLDC, the organization and separation between profiles is not as clear as in the CDC. Instead of building increased functionality as we go up the stack, there is MIDP, and then we have profiles such as IMP that duplicates MIDP, with certain functionalities (the UI related APIs) removed:

Figure 2. Current CLDC-based Profiles: IMP and MIDP relationship

It Would be Great if....

It would be great if there is a clear definition for CLDC-based profiles, a definition similar to what have been done for CDC. In this ideal architecture, functionality is really broken down into optional packages - imagine that each major API in Figure 1, such as RMS or Security, is its own optional package. In this scheme profiles define the set of optional packages that comprises the given profile. At the bottom of the stack we would have a base profile for CLDC (lets call it the CLDC Base Profile), which defines the base structure and life-cycle of an Xlet, and any related methods. On top of the Base Profile would be the IMP, which would define the base functionality for headless devices with limited connectivity, and on top the MIDP would be the MIDP as we know it (functionality-wise) today - in this scheme each layer (profile) builds functionality as we move up the stack. In this scheme other optional packages could be optionally included by device-vendors, for example, a headless (IMP) device that needed "enterprise integration" would include support for the Web Services for J2ME API:

Figure 3. Ideal Organization for CLDC-based Profiles

In Conclusion...

Addressing this issue is not easy. For one, there is an existing MIDP base of millions of devices.

The issue brought up here is more than just an architectural purism thing - there is an economical impact associated with this - for example, keeping profiles synchronized is VERY expensive (it requires the formation of an expert group), and new certification tests (TCKs) licensed and passed. Also, a well defined organization helps minimize duplication of functionality.

I am hoping this important issue gets addressed ASAP, before more profiles for CLDC get submitted. I am hoping for a plan from the different expert groups leaders, and the J2ME JCP executive committee.

Note: It is not fair to write about this topic without first admitting that I have been part of the problem I am addressing here; I was member of the MIDP 2.0 expert group, but failed at that time to see this problem - too focused on MIDP. Today as part of the IMP expert group and with Carl Zetie's feedback (see his report "Market Overview Update 2003: J2ME in the Enterprise") I have come to realize the importance of addressing this important issue ASAP, before more CLDC-based profiles go through the JCP.

ceo

Why Google Ads?
To help subsidy this web site's hosting expenses.

About the Author

About C. Enrique Ortiz - I'm a mobility enthusiast, practitioner, and professional, with many years of experience in end-to-end mobile computing.

I'm a technologist by heart, a software architect and developer, who spends quite a bit of time with mobility technologies.

I am the co-founder and CTO of eZee inc, a new mobile solutions company. I also am Owner and Principal Technologist at Artemis Wireless Werks, a mobility services and consulting company which have helped dozens of companies deliver their mobile strategy.

I've worked in engineering and management positions in companies that include IBM, Pervasive Software, AGEA, Aligo, IBM and Dell, in areas that include avionics software (Space Shuttle OS), embedded, robotics and image processing, multimedia streaming, large financial systems, and of course, end-to-end mobility systems.

I've been the author or co-author of many publications, patent disclosures, and of the first book exclusively devoted to Java programming with the J2ME Mobile Information Device Profile (MIDP) published by John Wiley and Sons. I also was co-designer of the Mobile Java Developer Certification Exam of Sun Microsystems. Many of my writings are technical articles on mobility technologies and software development that can be found all over the Web. I also have a weblog where I write about mobility and other things.

I have been an active participant in the Java mobility community, where I have evangelized the Java ME technologies for many years now, and where I have had the privilege of serving as a member in various Java Specification Requests (JSRs) expert groups including the Mobile Information Device Profile (MIDP) 2.0, MIDP 3.0, the Web Services API for Java ME, the Information Module Profile (IMP), the Content Handling API (CHAPI), The Java Language & XML User Interface Markup Integration, and others, and have been a contributor to other JSRs such as the Payment API, the Device Management API and the Mobile Service Architecture.

I was a founding member of Mobile Monday Austin, the Austin Wireless Alliance, and the Carnival of the Mobilists, and I lead the Austin Bootstrap Network's Mobile Subgroup. I also, as time permits, volunteer my time as a mentor of Software Engineering at the University of Texas at Austin, helping CS students on their senior year get ready for the "real" world.

I hold a B.S. in Computer Science from the University of Puerto Rico, and if I count my pre-college days I have close to 20 years of software development experience -- other experience are in product development and management. I currently live north of the beautiful Austin, Texas, U.S.A.

Enrique's Affiliations:

Association for Computing Machinery

Austin Technology Council

Austin Wireless Alliance

Bootstrap Austin

Carnival of the Mobilists

Digital Convergence Initiative

Java Community Process

Mobile Monday

Wireless Future

Other Mobility Sites

Terms of Use, Legal

Content (text, sources lines of code, illustrations and similar) published in this website is copyright work by C. Enrique Ortiz, unless such rights have been deferred by the author, in which case the copyright terms will be stated as appropriate. For content pointed to from this website, but published on other websites, visit the appropriate webiste for their copyright notice.

The content by C. Enrique Ortiz, such as the text of articles and blog entries can't be reproduced without permission. Members of the press and the blogosphere and others may cite portions of research data or text that is no more than a paragraph in length, provided they properly attribute its source, for example: "Source: C. Enrique Ortiz". The content of this website can't be used by Mechanical Turks or other for the purpose of providing answers for a fee, and the source must always be attributed as described in the previous sentence.

The source lines of code (SLOC) written by C. Enrique Ortiz and available in this website is copyright work by C. Enrique Ortiz, and it is free software that you can use as reference, derive from, redistribute and/or modify under the terms of the GNU Lesser General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version.

All work, reference and usage, as reference or as a derivative work, including redistributions of text, code and images created by C. Enrique Ortiz and available in this website must retain the above attribution and Copyright notice.

Comments and opinions are my own, and do not necessarily represent the opinions of my employer, customers or others.

The following are registered trademarks of Sun Microsystems Inc.: Java, J2ME, J2EE, J2SE, Java ME, Java SE, Java EE, CLDC, CDC, MIDP, Java Card, and other related Java trademarks. All other registered trademarks are owned by their respective owners. This web site is not affiliated with Sun Microsystems Inc. or any other company.

C. Enrique Ortiz Mobility Resources

Technical Articles, Tips, and Opinions