Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
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 (see Figure 1). BREW applications can execute independently of a network connection (unlike WAP-based applications) and can be deployed on 2G and 3G networks.
)
Figure 1 BREW architecture.
NOTE
Graphics used by permission from QUALCOMM.
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 (BDS), as shown in Figure 2.
)
Figure 2 The BREW application distribution process.
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 (see Figure 3). 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.
)
Figure 3 Downloading BREW applications.
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.