The application of Java technology to wireless devices is, for
many, a natural evolution. Java was, after all, designed to be a
network-savvy platform. Korea and Japan have seen significant
wireless Java deployments, and Nokia is considering shipping 50
million wireless Java devices in 2002. But is the excitement
justified?
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 | | |
|
|
between the user and the service is transmitted over the
network
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.
Compatibility issues
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.
More information
Ovum:
www.ovum.com