BlueTooth探索系列（一）---JSR082 API框架剪影
作者cleverpig
版权申明:可以自由转载, 转载请保留下面的作者信息:
作者 cleverpig(http://www.matrix.org.cn/blog/cleverpig)
关键词: 蓝牙,jsr,j2me,BlueTooth
一、JSR082 API框架：
1.api分类：
JSR82的API从功能上分为3大类：
1).发现：包括设备/服务发现，服务注册；
2).通讯：包括建立设备之间的连接、使用这些连接；
3).设备管理：可以负责管理和控制连接。
所以这3类的关系主要是：设备管理-(管理)->通讯-(实现)->发现。
2.开发包划分：
1).Javax.bluetooth:提供实现蓝牙功能的API。
2).javax.obex:提供无线上OBject EXchange的API。
这两个包是各自独立的，互相没有依赖关系。但是他们都依赖javax.microedition.io包。
3.midp与bluetoothapi的关系：
1).CLDC：连接受限制设备配置，即KVM，提供了基本的java语法安全验证和sandbox的安全功能。但是由于设备的处理能力有限，这里的验证只是通过预验证实现的，即把验证的工作放在了计算机上，而不是j2se中的编译和类装载时的安全验证。
只包含了java.lang、java.io、java.util这三个功能有限的包。
2).MIDP：移动信息设备框架，位于CLDC的上层，对CLDC的基本功能进行扩展。提供了网络和多媒体、存储功能。
3).Bluetooth API：蓝牙应用程序接口。与MIDP平级，但独立于MIDP，可与MIDP或CLDC共存。
4.蓝牙控制中心(bcc)：
实现BluetoothAPI的蓝牙设备，允许多个应用同时执行，这就需要BCC来避免一个应用与其它应用发生冲突。BBC具有允许用户或者OEM在蓝牙堆栈中定义某个配置的指定值，并解决由使用蓝牙API的应用所造成的冲突请求。
所以BBC是本地蓝牙设备设置的核心授权者，它的细节留给了实现：它可能是厂商提供的一个使用一个单独的API或者一组简单的配置本地应用程序，不能被使用者修改。
下面谈一下BBC与安全模式的关系：
从最基本的层面来看，BCC定义设备相关的安全设置。例如，BCC控制虚拟机中一个栈所使用的安全模式，维护着信任设备的列表。这个API允许应用某个应用指定它的安全要求：认证、加密、授权。JSR82实现了与BBC接口，来对所有应用的安全要求作出公断。
BCC在API中不是一个类也不是一个接口，但它是JSR82这个规范安全框架的重要部分。蓝牙无线技术的Java API需要BCC才能完成对程序的安全保证。BBC是依赖实现的，它只是可能用java开发的，具体的情况按照移动设备生产厂商不同而定。
BCC的特点：
BCC必须提供以下功能的API实现：
1).设备的基本设置，包括在蓝牙规范中定义的安全模式；
2).一个本地设备已知的远端蓝牙设备（并不必要为邻近的蓝牙设备）列表；
3).一个本地设备信任的远端蓝牙设备（并不必要为邻近的蓝牙设备）列表；
4).一种尝试无线连接两个设备的机制；
5).一种提供连接授权的机制。
以上这些信息只能被BCC所改变。
BCC可以提供，但是不被限制的行为：
1).设置本地设备的蓝牙设备名字；
2).设置基带层的超时；
3).检测可连接/可发现模式如何被设置；
4).重置本地设备；
5).枚举本地设备上的服务。
5.设备属性：
一些java技术适用的蓝牙产品需要根据产品和市场的需要进行不同的配置。所以设备属性API便应运而生了。这个定义了可以通过调用LocalDevice.getProperty()方法而返回的附加设备属性，如设备版本、MTU最大值等。这些属性既提供了蓝牙设备的附加信息而且定义了可被应用替换掉的限制。这些“String”类型的属性如果没有被定义或者未知，那么其属性值为null。
这里需要解释的是Page scan、Page、Inquiry、Inquiry scan。
这些属性与蓝牙设备无线连接过程密切相关：
Inquiry：首先主（Master）设备使用GIAC或DIAC查询周围的蓝牙设备；
Inquiry Scan：同时工作在副（Slave）设备模式下的蓝牙设备侦听Inquiry；
Inquiry Response：如果副设备接收到来自主设备的Inquiry，它将发送自己的设备地址和时钟信息给主设备；
Page Scan：在发送Inquiry Response后副设备将进入侦听从主设备发来的广播信息（Page message）的状态；
Page：主设备收到Inquiry Response后发现了周围的蓝牙设备后，广播建立连接所需要的信息；
Slave Response：处于监听状态的副设备收到广播信息后，将自己的设备访问代码回应给主设备；
Master Response：主设备收到Slave Response后将传输主设备的时钟和设备地址、设备类型回应给副设备；
Connection State：在副设备接收到Master Response后，双方就进入了连接状态。
6.c/s模式：
一个蓝牙服务是一个类似server的应用，它提供了client设备上不具备的功能。比如打印服务就是一个蓝牙服务的例子。开发者可以在蓝牙框架之上自己定义自己的蓝牙服务应用，并通过定义一个描述服务信息的服务记录，并将该服务记录添加到服务发现数据库（SDDB），提供给远程设备使用。
在注册服务记录后，server应用程序等待client开始与它的交互、并访问服务。而另一方面，client和server程序建立蓝牙连接，进行它们之间的交互。
从某个角度看，server应用好像超出了蓝牙规范的范畴，那样的话，就像蓝牙发展的前期多个厂商实现各自的蓝牙协议堆栈，没有要求标准化以确保不同蓝牙设备之间的互通性一样。那一定是一场灾难。不过，一套标准化的API的出台将改变这一种混沌的局面。
这套API将server应用、client应用、蓝牙堆栈三者的责任分离开来：
server应用的责任：
1).建立表述应用提供的服务的服务记录（service record）;
2).添加服务记录到server的SDDB，使client能够使用之;
3).注册在与client连接中使用蓝牙安全策略;
4).接收来自client对服务的请求;
5).当服务记录的特性改变时，即使更新server的SDDB中的服务记录;
6).当服务失效时，删除或者禁用server的SDDB中的服务记录.
client应用的责任：
1).使用服务发现协议(SDP)查询远端设备的SDDB;
2).注册在与server连接中使用的蓝牙安全策略;
3).开始连接提供服务的server;
4).可选的，轮询server的SDDB以确定服务是否改变或者失效.
蓝牙协议堆栈提供给本地蓝牙server应用的特性：
1).一个允许server添加、更新、删除它自己的服务记录的服务记录仓库;
2).给每个服务记录赋予一个唯一的服务记录句柄;
3).建立与client的逻辑连接.
蓝牙协议堆栈提供给远端执行服务发现的client应用的特性：
1).查询并接收保存在server的SDDB中的服务记录;
2).建立与server的逻辑连接.进入讨论组讨论。
（出处：http://www.knowsky.com）
