So-called microbrowser technologies, such as WAP, the i-Mode platform and Openwave's platform, have fuelled the first wave of interest in wireless data services. These early services are delivered using a Web-like, network-centric model.
Network operators worldwide almost universally employ Microbrowser technology. High microbrowser penetration means that content providers and application developers can now make content and services available to large populations of handheld terminals - as long as they are prepared to use a "lowest-common-denominator" approach.
However, the microbrowser model is far from a universal solution to the problem of delivering data services to handheld terminals, for the following reasons:
- highly interactive and business-critical applications are unsuited to microbrowser architectures. Microbrowser architectures rely on the network being able to ship data back and forth between a centralised server and the terminal; if the network becomes unavailable or slows down, then an application service delivered over it will, too
- microbrowser-based services are not cost-effective for many users. Sending data packets over a cellular network costs money - in many cases, quite a lot. Also, where packet-switched overlays such as GPRS are not available, users pay for airtime while they are waiting for a data connection. Microbrowser architectures rely entirely on network transmission for service availability - every interaction
"Operators will have to work hard to retain their current dominance in the wireless data services value chain when wireless Java technology becomes widely adopted" Source: Ovum
The solution to these issues is to install certain service components on handheld devices, to allow:
- Interactive applications to interact with users more frequently and immediately than network transmission alone would allow
- Business-critical applications to keep on working, even when the network connection is dropped
- Applications to function without the network present, and only connect occasionally to exchange highly-compressed packages of information with a remote server
For some applications and users it makes great sense to deploy services in a way that distributes their functionality more evenly between the network and individual handsets. However, the extreme variety of handheld terminals available today (and in the future) creates a significant problem: how do you create and package content and services so that they can run on a variety of devices?
This is where Java comes in. The Java platform was designed for this very purpose. Its creators have also defined "special editions" of the technology, particularly for small, limited-capability handheld terminals.
Other software technologies compete with Java in this way. However, most of Java's competitors differ from it in one key respect: Java is installed on top of, and independently of, a device's operating system, whereas most of the other key technologies - the Symbian Platform (formerly EPOC), PalmOS, embedded Linux and Windows CE - are all operating systems in their own right.
Qualcomm's Binary Runtime Environment for Wireless (BREW) operates independently of terminal operating systems, but only works with terminals employing Qualcomm's CDMA chipsets.
The anatomy of J2ME
Java 2 platform Micro Edition (J2ME) is a fairly recent addition to the family of Java environment specifications. Its brethren in this family are Java 2 platform Standard Edition (J2SE), which is aimed at PCs, and Java 2 platform Enterprise Edition (J2EE).
The specification family is split into three layers:
- The core J2ME specification, which lays out the base functionality that every "micro" Java implementation must support
- "Configurations", which build on the core specification and are designed to provide sets of functionality for specialised broad types of terminals
- "Profiles", which build on particular configurations and provide targeted sets of application program interfaces (APIs) that are designed to encapsulate functionality required for particular terminal types. For example, mobile phones, personal digital assistants and TVs
J2ME today defines two configurations:
- Connected Limited Device Configuration (CLDC), which is designed for mobile devices that must operate with limited power, limited network connectivity and constrained memory and processing capacities. It is based on an optimised Java Virtual Machine called the K Virtual Machine (KVM), which can run in around 130Kbyte of memory
- Connected Device Configuration (CDC), which is designed for more capable connected devices, typically sporting a 32-bit processor and 2Mbyte or more of total memory
The main difference between the CDC and the CLDC is that the core JVM technology used in the CDC is a full-featured Java Virtual Machine called the C Virtual Machine (CVM).
The CVM implements more functions and services than the KVM. Sun Microsystems' vision for the CDC is that it will not just be implemented in handheld terminals, but will also be delivered inside residential home-network gateways, home appliances, point-of-sale terminals and car navigation systems.
Wireless Java barriers
To really drive the market for next-generation wireless data services, every player in the value chain needs the benefits that a unifying technology such as wireless Java can bring. However, there are several potential barriers to the development of wireless Java as an enabler for next-generation wireless data services. All of them stem from the same fundamental issue: The technology is taking centre-stage, but there is not enough serious planning, testing nor collaboration in the industry to deliver the long-term benefits that everyone is looking for.
Market structure and vested interests
The evolution of next-generation device platforms, such as wireless Java implementations, provides many opportunities for content providers, application developers and device manufacturers. However, it threatens to diminish the role of the network and, consequently, it could pose a threat to mobile network operators' traffic revenue streams.
Where devices employ wireless Java technology or some other advanced software platform, users do not necessarily need a network connection to use services. Indeed, highly interactive applications, such as games and interactive multimedia information services, and business applications, such as CRM or field-service automation applications, should be used independently of the presence of a network connection.
The central role of the network in delivering data services used to be a "given", but soon this will not be the case. Operators will have to work hard to retain their current dominance in the wireless data services value chain when wireless Java technology becomes widely adopted - they will not retain it by right.
On paper, the so-called write-once, run-anywhere capability of Java technology is ideally suited to the world of wireless data services. However, the reality is somewhat less appealing.
Even in the realm of officially endorsed Java implementations, the Sun-hosted standards development process has yielded several different specification families that licensees can apply to new products. The wireless Java specification work that has been undertaken so far has created much more complexity than it needed to.
To make matters worse, the early implementations of wireless Java technology that are finding their way into deployed handsets have augmented the facilities offered in the standard specifications. The result is that, even in these early days, Java content and applications authored for use with one mobile operator's service cannot be deployed on another operator's service without significant changes.
The Japanese and Korean operators pioneering deployments of wireless Java have let their desire for a "first-to-market" advantage override the need to deliver standard platforms. In Japan, for example, where all three leading mobile operators are using Java, content written to work with any one operator's service will not run on either of the other two.
Device technology demands
Installing any kind of software on a resource-constrained device is tricky. Even the less demanding J2ME configuration (the CLDC) requires devices to have greater than 128Kbyte of memory to run the Java platform alone. The more demanding specification (the CDC) requires greater than 512Kbyte. Tomorrow's smartphones will provide much more than this capacity. However, more modestly specified devices may not be able to provide this kind of power.
Wireless Java technology also holds traps for unwary developers that can severely affect the performance and robustness of Java programs. Many implementations of the Java platform on handheld terminals do not behave in the way application or content developers might expect, particularly in terms of low-level system functionality and "housekeeping" functions such as managing memory.
Complexity of content development
The downside of a market that allows content and application developers to build more sophisticated interactive services is that they are difficult to build.
The demands on developers increase, because the expectations of wireless data service users will be higher than those of many of today's e-commerce and business application users.
Most of today's e-commerce and business application users have quite low expectations of the availability, reliability and performance of software applications and services, because they are used to poor reliability from PCs and poor perceived performance from the Web.
However, when interactive services are delivered to handheld terminals, users' expectations are naturally coloured by their experiences of using voice services, which perform better than the most mainstream software products.
Java is not the only contender
At a simplistic level, wireless Java technology does not compete directly with any other platform technologies. It appears to be completely independent of device and operating system, which sets it apart from other platform technologies. The practical truth is less certain, however.
There are two major technology players with platforms already deployed in various mobile handheld devices that compete with wireless Java: Qualcomm and Microsoft.
On paper, Qualcomm's BREW does not compete with Java, because it is not truly device-independent: It only runs on devices with CDMA chipsets. However, because the write-once, run-anywhere Java proposition is unfounded, Java is not particularly dissimilar from BREW in this area.
More worryingly for those backing Java, BREW offers content and application developers access to a broader range of features and functions than wireless Java variations. Moreover, Qualcomm is interested in licensing BREW to third-party infrastructure players.
In theory, Microsoft's SmartPhone and PocketPC platforms do not compete with Java. As with BREW, the promise of Java is that it operates above the level of any individual operating system, such as PocketPC, to provide a universal application and content deployment environment.
The truth is somewhat more complex and subtle. If Java continues to fragment, then the real market reach of any particular Java "flavour" will certainly be no larger than PocketPCs, and could well be much smaller. Also, Microsoft's .Net initiatives are broadening the reach of its developer API set: the same tools can now be used to build applications for desktop PCs, smartphones and personal digital assistants.
Microsoft's influence over both corporate and commercial software developers is a major weapon that the company can use, and is using, to further its position as a top-tier mobile device platform player.
These moves place Microsoft's platforms in direct competition with Java. The company cannot "kill" Java, but it has the potential power to seriously reduce the size of the wireless Java market by providing an attractive, powerful and ubiquitous substitute.
The outlook for J2ME
Wireless Java variants such as J2ME Mobile Information Device Profile (MIDP) are a valuable addition to the technology armoury available to the growing wireless data services market. However, we are fast approaching a crossroads in terms of wireless Java evolution. The technology has great potential, but all that could disappear.
Either the current level of fragmentation occurring within the scope of the current wireless Java pioneers is reduced through heavy pressure from the Java Community Process members responsible for the wireless Java specifications, or the whole wireless Java value proposition is bust.
The development outlook for the main competing technologies - Qualcomm's BREW and Microsoft's mobile platforms - is equal to that of Java, if not more favourable. If wireless Java technology continues to fragment, then Java, BREW and Microsoft's technologies will be set on an imminent collision course.
Device vendors, operators and content providers must work as closely together as possible to minimise the likelihood of further fragmentation of wireless Java technology.
Wise wireless content and application providers should track the ongoing technology development and licensing of BREW and Microsoft's platforms closely. There may come a time in the next year when it makes more sense to develop primarily for BREW, for example, than for Java.
Our message to users is caveat emptor, or "let the buyer beware". Today, there is no write-once, run-anywhere with wireless Java. This may not be a problem, but you need to match your requirements and expectations very firmly with what is really available.