An Overview of JABWT

This chapter describes

• The goals of the JABWT specification

• The characteristics of the JABWT specification

• The scope of the JABWT specification

Some sections in the chapter may not seem relevant for those primarily interested in programming with JABWT. But the overview of JABWT is presented to lead to a better understanding of the capabilities and the reasoning behind these APIs.

2.1 Goals

The Bluetooth specification defines the over-the-air behavior for ensuring compatibility of Bluetooth devices from different vendors. The Bluetooth specification does not standardize a software API to Bluetooth stacks for use by Bluetooth applications. JABWT helps solve this problem by defining the first standard API for Bluetooth application developers. The overall goal of the JABWT standardization effort discussed in this book is to define a standard set of APIs that will enable an open, third-party application development environment for Bluetooth wireless technology.

The goals were to minimize the number of classes (the total number of classes in JABWT is 21); keep the API simple and easy to learn and program; and keep it powerful. The meaningful high-level abstractions help in third-party application development. This API brings together the benefits of two different technologies: Bluetooth wireless technology and Java technology. Having this standard API in the Java language brings in all the benefits of Java technology, some of which are discussed in Chapter 1. The abstractions and ease of programming of the Java language facilitate easy development of complex programs. The goal of JABWT is to present access to Bluetooth wireless technology in the easy but powerful form of the Java language.

2.1.1 Target Devices

JABWT is aimed mainly at devices that are limited in processing power and memory and are primarily battery operated. These devices can be manufactured in large quantities. Low cost and low power consumption are primary goals of the manufacturers. JABWT takes these factors into consideration. Figure 2.1 shows the types of devices that might use JABWT. Some of the devices shown, such as the car, laptop, and LAN access point, are not J2ME devices. These devices are likely to operate with J2SE, CDC, or PersonalJava. Some manufacturers of these products, however, are already incorporating JABWT in their designs. In addition, work completed under JSR-197 will make integrating JABWT into these products easier. JSR-197 [21] is intended to create an optional package out of GCF alone, allowing applications that rely on the GCF to migrate to J2SE. JSR-197 also is intended to use GCF APIs as defined by the J2ME Foundation profile along with improvements proposed in CLDC 1.1 (JSR-139) [25].

2.1.2 Keeping Up with the Bluetooth Profiles

One initial idea was to define an API based on the Bluetooth profiles. But the JSR-82 expert group realized that the number of Bluetooth profiles is constantly growing and that it would not be possible to keep up with the new profiles in the JABWT specification. Instead the JSR-82 expert group decided to provide support for only basic protocols and profiles rather than introducing new API elements for each Bluetooth profile. The intent of the JABWT design is to enable new Bluetooth profiles to be built on top of this API with the Java programming language. Bluetooth profiles are being built on top of OBEX, RFCOMM, and L2CAP. For this reason, all three of these communication protocols are incorporated in JABWT. Writing future Bluetooth profiles in the Java programming language enables portability across all operating systems and Bluetooth protocol stacks.

In addition to APIs for accessing the protocols, there are APIs for some Bluetooth profiles. JABWT addresses the following: GAP, SDAP, SPP, and GOEP. Detailed information on Bluetooth profiles and relations to protocols such as OBEX, RFCOMM, and L2CAP are given in the Bluetooth Core specification [1] and the Bluetooth Profile specification [3].

JABWT is based on Bluetooth specification version 1.1. However, nothing in the JABWT specification is intended to preclude operating with version 1.0–compliant stacks or hardware. In addition, if future versions are backward compatible with version 1.1, implementations of the JABWT specification also should operate on those versions of stacks or hardware.

2.1.3 JABWT Use Cases

Any technology does better when more applications are created for it. Standardized APIs foster an environment to create a variety of applications. In addition, standard APIs make it possible for certain types of applications and markets that otherwise would not be possible. The portability of Java applications and standardization of JABWT facilitate the use cases discussed herein.

Peer-to-Peer Networking

Peer-to-peer networking can be defined and interpreted in many ways. For the purpose of this discussion, a peer-to-peer network is defined as a network between two or more devices whereby each device can be both a server and a client. JABWT supports peer-to-peer networking with Bluetooth wireless technology. An example of a peer-to-peer network application is a game played between two or more devices connected through Bluetooth communication.

The devices involved can belong to entirely different device classes, such as a phone and a personal digital assistant (PDA) using different hardware and operating systems. If these devices are JABWT enabled, the software games can be written once in the Java programming language and run on all of the devices. In addition, the device independence of these JABWT applications makes it possible to share and download these games onto different devices.

Kiosk

It is impractical for a kiosk that sells software to store different executables for the various Bluetooth devices that have been manufactured. With JABWT, an application can be written once, purchased, and executed on all Bluetooth devices that have implemented this API. This capability enables establishments such as airports, train stations, and malls to have custom applications that work best in their environment. Bluetooth devices with JABWT implemented can download these custom applications from kiosks.

Buying Soda and Bluetooth Applications through Vending Machines

Another example of the benefit of this API is a scenario in which people purchase or download Bluetooth applications to their Bluetooth devices while using the same device to purchase a soda from a vending machine. The API allows applications to be written once and run on many different Bluetooth platforms. The vending machine stores these applications and transfers them via Bluetooth transports. A game manufacturer might buy advertising space on vending machines to house a sample game. Customers purchasing soda could be given the option of downloading a free sample game, which can be upgraded later when the game is purchased.

2.2 API Characteristics and Hardware Requirements

This section describes the characteristics of JABWT and the hardware requirements followed in defining JABWT. There were two categories of hardware requirements:

• The requirements of the J2ME device

• The requirements of the Bluetooth subsystem in the device

2.2.1 JABWT Specification Characteristics

This API design was challenging because both Java technology and Bluetooth wireless technology appear in a variety of devices. It was difficult to try to cover all the devices with one API. The initial goal of the JABWT specification was to define an API that could be used by all devices that support J2ME. As stated earlier, the expert group believed that J2ME devices would be the first to implement JABWT. Hence the API was built with standard J2ME APIs and the GCF defined in CLDC. Thus JABWT can be ported to any Java platform that supports the GCF. The first two characteristics below resulted from this thinking. JSR-197 adds the GCF into J2SE platforms and will help JABWT and other J2ME APIs to be usable on other Java 2 platforms.

The characteristics of the JABWT specification are as follows:

1. Requirement for only CLDC libraries.

2. Scalability—ability to run on any Java 2 platform that supplies the GCF.

3. OBEX API definition independent of Bluetooth protocols. By contrast, applications written with the Bluetooth API are expected to run only on platforms that incorporate Bluetooth wireless technology. While defining the API for OBEX, the expert group recognized that OBEX could be used over a number of different transports (e.g., IrDA, USB, TCP). Therefore, the OBEX API is defined to be transport independent. The OBEX API is in a separate javax.obex package.

4. Use of the OBEX API without the Bluetooth API. An IrDA device could implement the javax.obex package and not implement the javax.bluetooth package, which contains the Bluetooth API.

5. Prevents applications from interfering with each other. The concept of the Bluetooth Control Center (BCC), discussed in Chapter 3, was introduced for this reason. The intent of the BCC is to allow...