The JABWT specification defines an optional J2ME package for Bluetooth wireless technology.
What is it?
The JABWT operates on top of the CLDC and is intended to extend the capabilities of profiles like the MIDP. JABWT use the Generic Connection Framework (GCF) defined in the CLDC specification for Bluetooth communication.
What does it provide?
JABWT consists of two packages.
| javax.bluetooth | The core Bluetooth API. |
| javax.obex | The Object Exchange (OBEX) API. |
These packages are separate optional packages so the CLDC implementation may include either of the packages or both of them.
The javax.bluetooth package provides an API for discovering devices and the services they provide. In addition it provides functionality for setting up services of your own and customization of local service records. Setting up L2CAP and RFCOMM connections is available through an extension to the Generic Connection Framework (GCF) from the CLDC.
The javax.obex provides an API for the OBject EXchange (OBEX) protocol. This package is not implemented on the Nokia 6600 smartphone. It is not tied to the Bluetooth API alone but is intended to be of more general use
Security
The JABWT does not define any security models itself. It depends on the security models available through the Bluetooth stack. However, it does define how the JABWT should interact with the lower layers in the Bluetooth stack responsible for security features. The device must have a Bluetooth Control Center (BCC) to which JABWT applications can direct their security requests.
BCC
The JABWT depends on a BCC implemented on the device. The BCC is the central authority for local Bluetooth device settings. It controls base security settings and provides lists of devices both known and trusted by the local device. The BCC is responsible for pairing devices and providing authorization for connection request. All of these functions must be included in the BCC.
The BCC may have other capabilities like setting the Bluetooth friendly-name of the device, setting timeouts for the baseband layer, determining how connectable and discoverable modes are set, resetting the local device or enumerating services on the local device. This BCC functionality is implementation dependent and may vary between OEMs an their devices. Some implementations may provide a GUI to the BCC while others provide hard-coded defaults in the BCC. For example, a headset will provide only defaults in the BCC since it does not have an input device or screen. When sending request to the BCC one should always check if the request was fulfilled by the BCC. One is not guaranteed that the BCC can fulfill the request at the given time.