What's BREW-ing Today?
InformIT
Feb. 7, 2003
Article by Jasmit Kochhar
Introduction
The last few years have seen amazing growth in the wireless industry. Wireless network operators have recognized that real growth in revenues and efficient usage of their networks require introduction of non-voice services that provide an opportunity for increased average revenue per user. Such non-voice services include games; entertainment; news; and productivity applications such as calendars, email, and instant messaging. These data-driven applications have become a way for a network operator to define its competitive advantage.
Not so long ago, consumers had little (if any) choice of applications on their handsets. This is rapidly changing. As wireless operators add data services to their networks, virtually any Internet-enabled device within reach of a cellular base station can initiate and maintain a connection to the Internet. The ability to download games or productivity and business applications "over the air" provides significant advantages for increasingly mobile customers.
Challenges for the Wireless DeveloperMobile phones and personal digital assistants (PDAs) continue to be the most common wireless devices. Their pervasiveness makes them attractive targets for application development. However, deployment of applications and mobility portals has several challenges:
- Constrained devices. Processing power and storage capabilities are highly constrained on mobile devices. These devices are designed to be small and inexpensive and are required to consume as little power as possible. As a result, wireless application programmers don't have the luxuries of the PC-based environment: almost unlimited memory, storage, and bandwidth.
- Device variability. Mobile devices vary greatly in form, user-input interfaces, use of non-standard markup languages, and over-the-air protocols. Server-based application infrastructure and middleware must interact with many more client environments than in the PC world.
- Multiple browsers and platforms. Browsers on devices that use common markup languages are so diverse that even browser-based applications must be modified significantly for each type of browser and device. Latency in the network and lack of disconnected operation make browser-based applications unrealistic for serious uses. Hence, the developer community is moving to develop client-based applications. Options for developing client-side applications include Qualcomm's BREW platform, Sun Microsystems' J2ME standard, and Microsoft's adaptation of Windows CE for mobile computing. Even if browsers are standardized, devices have other differences screen size, RAM, physical storage space, colors, TAPI interfaces that must be considered when developing applications. All these factors make it difficult to create a single source code base to accommodate a number of different data-enabled devices.
- Limited customer base. Added to the complexity of the devices is the fact that different manufacturers or OEMs support different platforms, network technologies, or operating systems. The developer is left with the challenging task of having to select the target customer base. Applications designed for one platform rarely work on another. The developer often feels tied to one environment, with significant costs connected to any associated expansion plans to other environments.
- Barrier to entry. Network operators are huge establishments, and the barrier to entry can be daunting for small developer organizations. Handset manufacturers often work with a few select developers who create limited sets of applications for all their handset models.
- Rogue applications. Finally, network operators are very concerned with stability and performance of applications. Operators want to protect their networks from rogue applications, which could affect their network operations for both voice and data services. Downloadable applications add the challenges of viruses, hackers, bad performance, and application instability or malfunction, which can lead to perceived degraded value of operators' service offerings. This is another impediment for new developers to get an easy foot into the wireless development space.
All the above concerns are significant challenges for developing, deploying, buying, and consuming data services on today's wireless networks. The BREW platform was designed to address these challenges.
What Is BREW?
BREW stands for Binary Runtime Environment for Wireless®. At a basic level, the BREW platform functions as an interface or a layer of abstraction to the embedded chip's operating system on a handset. Think of it as being similar to the Win32 API for Microsoft Windows in the PC environment. The BREW platform is a set of binary libraries compiled and linked for native execution and optimized to allow applications to take advantage of wireless services and resources. It controls the flow of events to and from the applications and accordingly starts, stops, suspends, or resumes applications in response to appropriate events. The BREW execution environment discovers applications and any associated extensions at runtime.
- BREW application platform and porting tools for device manufacturers
- BREW Software Development Kit (SDK) for application developers
- BREW Distribution System (BDS) that is managed and controlled by network operators enabling them to easily get applications from developers to market and to coordinate the billing-and-payment process
The BREW Story
Device manufacturers receive tools to port the BREW platform on top of the operating system of the embedded chip system. BREW provides a layer of abstraction on top of the operating system to some of the functions and variables that are crucial for wireless application development. The BREW platform is completely independent of underlying network technology or air interface. BREW applications can execute independently of a network connection (unlike WAP-based applications) and can be deployed on 2G and 3G networks.
BREW provides access to the underlying low-level functions of the mobile device through its application interface. Developers can use the BREW SDK and C/C++ to write applications for the device without having any knowledge of the underlying complexity. Because the application interface doesn't change, porting applications from one BREW device to another becomes a lot easier. These interfaces are a collection of functions related to a particular service IApplet, IFileMgr, IDisplay, and so on. The APIs are encapsulated in reference-counted object classes. Each interface is associated with a unique 32-bit ID called AEECLSID (Application Execution Environment Class ID). Developers and device manufacturers can add their own custom interfaces.
A developer writing a BREW application implements all the functions in the BREW interface called IApplet. The application classes are all stored in binary modules (.mod) files. The application also has associated resource files and a module information file (MIF). The MIF contains AEECLSIDs for each of the applications or extensions in that module, titles and icons to be used for the applets, and registry information and security/privilege information for system-level services accessed by the application (file I/O, network I/O, TAPI, and so on). This information is used by BREW to discover applications and extensions and enforce the necessary rules at runtime.
Developers can choose familiar programming tools, such as Visual C++, to develop BREW applications. The BREW emulator that comes with the SDK allows developers to debug their application on PCs. The emulator comes with a variety of skins provided by different device manufacturers to constrain the environment in terms of form factor, memory, etc. Once developers have completed development and testing in the emulator, they can use an ARM compiler to port the code to a handset and test on the hardware.
The BREW story is incomplete without discussing the BREW business model. For a solid business case, the industry needs a model that allows for developing, deploying, discovering, buying, downloading, and managing the applications transparently to the end user. This is the function of the BREW Distribution System.
At the network operator's request, applications go through a testing process to ensure that no disruptive applications are introduced onto the carrier's network. The BDS allows developers to submit tested and digitally signed applications to a global virtual marketplace of network operators. All BREW applications are digitally signed by VeriSign certificates for the developer, Qualcomm, and the network operator. The execution environment looks for these signatures before allowing the application to run in its environment.
Network operators can access a catalog of BREW applications, negotiate financial terms with developers, and select applications for distribution to customers. Consumers can select, purchase, and download applications from carrier networks over the air onto their devices. Based on the pricing options, a consumer can choose to try or buy applications. BREW manages the download, configuration, and billing aspects of the transaction.
A consumer running a BREW-enabled device has a BREW mobile shop that can query the BDS for applications that it can download. The BREW environment automatically filters the applications that can run on the consumer's phone, based on the device's capabilities and memory requirements. The consumer can select any of the listed applications for download. He or she can also choose to free up space on the handset by removing an existing application or by disabling it; only the executables are deleted, and the application can be reactivated by the user at any time.
The BDS is integrated into the network operator's billing system to allow easy tracking and billing for application downloads. Operators can charge customers for applications directly on their regular monthly bills. The BDS funnels a portion of the purchase price back to developers as agreed upon by the network operator and the developer.
The results:- Network operator's perspective: Good, stable, high-value applications and services ensure that the average revenue per user will increase, leading to greater economies of scale.
- Developer's perspective: The developer is paid based on the usage of the application.
- Consumer's perspective: The consumer has the ultimate control over what he or she uses and when. The BREW business model provides an end-to-end system that ensures that the applications developed and consumed generate revenue for the application developer and provide value to all players in the system. It provides an incentive to everyone and helps to stimulate the growth of wireless services and applications.
What BREW Isn't
So, is BREW an operating system or a virtual machine (VM)? Neither. BREW is a layer of abstraction that sits on top of the embedded chip's operating system and provides access to some low-level functions, environment variables, and subroutines. It's not a VM because it doesn't act as an interpreter. A Java VM interprets the bytecode of a compiled Java program class file at runtime.
On the other hand, BREW is like embedded development in C. Unlike with J2ME, a developer can write C code that will be compiled directly for an ARM processor in a highly constrained environment. This makes the BREW-compiled code more efficient both in size and execution. Developers can write a full-featured mail client in BREW for less than 50KB. BREW also allows access to system-level functions, such as integrating applications with the TAPI interfaces. For example, consumers can make a voice call from within a BREW application. This is impossible in the J2ME environment.
BREW also isn't a browser or a browser-based service, such as i-Mode. A browser is a program that allows the user to view or download content from web sites that are written in a specific markup language. For example, i-Mode uses CHTML for delivering data and services to the devices. This implies that what you can do with i-Mode is limited to the CHTML tag set, and generally the applications require a device to be connected to the i-Mode server. With BREW, the connected state is totally dependent on the functionality of the application and has little to do with the BREW application platform. A developer can write a browser in BREW to do what i-Mode does, but that's not a function of the BREW platform.
Java and BREW
Java-based applications require custom JVMs written for each device to handle system-level functions such as access to the SMS messaging layer. In addition, every network operator defines its own specification for Java implementation, requiring custom builds for each device. BREW helps to abstract all of this because of its standardized interface. Anyone can write a VM on the BREW platform as an extension, and it becomes available on all BREW devices. For example, IBM introduced a single JVM as a BREW extension. Java developers can take advantage of this JVM to write Java applications once and run them on all BREW-enabled devices with a sufficient memory footprint, regardless of the device manufacturer.
When a developer develops and wants to deploy a J2ME-based application on a BREW phone, he or she submits the application in the same way as any other BREW application. A part of the application descriptor defines its dependency on the JVM. The BREW execution environment is smart enough to download the JVM at runtime to configure the J2ME application properly. The BREW platform is standardized, so porting applications from one device to another is simplified. With its inherent application distribution model, BREW makes getting Java applications onto handsets much easier. It also enables upgrading and recalling JVMs over the air.
Time to BREW?In summary, BREW was designed to meet the needs of wireless application developers, who want a platform that offers a long-term customer base, doesn't lock them into a technology that prevents porting to other platforms, doesn't require a rewrite of the application for multiple platforms and devices, can effectively distribute the application to a customer base without too much cost, and can quickly make money on the application. BREW offers developers these features:
- An optimized execution environment: Native BREW code is written in C or C++, resulting in highly efficient code that works well in an environment constrained by memory, storage, and processing power. Applications developed with BREW can run on smaller, mass-market devices, which opens up a wider customer base than the ones created using Java or other development systems that run on top of a virtual machine and require high-end handsets.
- Writing BREW extensions: If you're a developer who writes tools and technologies used by other application developers, this is a great way for you to get your products to the wider developer community. BREW extensions may be VMs, parsers, authentication plug-ins, media players, synchronization plug-ins, and so on that could be used for other application development.
- Support for different development environments: With the JVM extensions, developers can also develop Java-based applications on the BREW platform.
- Low cost of porting to multiple devices: Because BREW provides the abstraction between the operating system and the application, the amount of effort required to port the application is minimal.
- Business model based on tangible returns: The download and billing system lets consumers download applications, records the transactions for the network operators, and handles all payments to the developer. This is perhaps one of the most significant advantages to developing on the BREW platform.
The market for mobile applications is still in its infancy, but it's growing up fast. BREW has been deployed in markets worldwide, including KTF in South Korea, KDDI in Japan, and Verizon Wireless and ALLTEL in the United States. China Unicom is slated to start the service in 2003. These carriers have deployed games, encyclopedias, streaming video, productivity applications, ring tones, road maps, real-time traffic reports, sports and weather news, and financial applications. The developer has an opportunity to reach an existing customer base using low-end devices, and to ride the future growth of high-end devices with BREW applications.
