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的逻辑连接.

二、Service Discovery Protocol：
1.Service Discovery Protocol适用范畴：
自由的使用蓝牙设备上的服务是我们所期待的目标，但是这些蓝牙设备上提供的服务是以一种不可确定甚至无法控制的方式动态增减着。为了帮助使用蓝牙设备的用户有序地罗列出每次都在变化的服务，并从中选择一些为他所用，JSR组织制定了Service Discovery Protocol（简称SDP）——服务发现协议。当遇到未知蓝牙服务时，遵守这个标准化的框架的蓝牙产品将能够定位服务所在位置，识别和有选择的使用服务。蓝牙协议堆栈包含了SDP，这个协议能够在周围的蓝牙设备中定位有效的服务提供给用户，作为用户选择服务使用的依据。有关选择、访问、使用服务的内容不属于本文的范畴，然而尽管SDP没有直接的被防问服务所调用，但通过将SDP所获得信息作为属性条件来让本地蓝牙协议堆栈访问指定设备的方式对使用指定设备上的服务起到了极其重要的促进作用。
SDP协议框架定义了在一个蓝牙设备上运行的服务发现应用所要使用的协议和过程两个方面：服务发现应用按照这个协议和过程来定位其它设备上的服务并使用它们。从这个框架的角度来看，服务发现应用是一个特定的由用户发起的应用。从这个框架与其它的蓝牙协议框架的比较看来，两者是不同的：服务发现工作与两个在蓝牙设备中的SDP实例交互，其目的是使用某个特定的传输服务（RFCOMM）或者特定的用途（文件传输、无线电话、LAN AP等）。其中后者（将服务用于特定的用途）的详细描述在相应的Bluetooth usage scenarioprofile（蓝牙用途框架）文档中可以查到。在其它的框架文档中，服务发现也出现在了一些地方：协议讲解、访问某个特定服务需要的协议参数等。无论怎样，SDP框架说明了服务发现的过程和在这些过程中如何使用SDP协议。与在其它框架文档中不同的是这些过程在SDP框架中被用在了用户层面，而其它的框架文档中将它使用在了应用级别的行为上。

SDP直接支持以下几种服务查询：
1).通过服务类进行服务查询；
2).通过服务属性对服务进行查询；
3).服务浏览。
一般的服务发现应用都被以上的三种服务查询所覆盖。其中前两个代表了查询已知或者指定的服务，并对类似“服务A是否有效？”或者“具有B和C特性的服务A是否有效？”的问题作出了回答。后面的服务浏览代表了另外一种服务查询，对类似“有效的服务有哪些？”或者“有效的类型A的服务有哪些”的问题给出解答。

上面的服务查询段落可以被实现为两种方式：
1).用户有意识地连接到某个设备，并查找这个设备上的服务；
2).通过无意识地连接本地设备周围的设备，并执行服务查询。
这两种实现方式都需要设备首先被发现、被连接、被查询它们所支持的服务。

2.SDP概貌：
1).SDP框架的堆栈：


上图显示了蓝牙协议和使用SDP的应用实例。
如图中，SrvDscApp这个服务发现用户应用位于本地设备LocDev上，通过与蓝牙SDP客户端的接口，发送服务查询请求并接收从位于远端设备RemDevs上的SDP服务器的服务查询响应。SDP使用了面向连接的L2CAP协议来传输服务，这种L2CAP协议使用基带异步无连接（ACL）来实现最终装载/传输SDP的PDU（协议数据单元）。
服务发现过程以与发现设备过程密切相关，发现设备过程又与执行设备查询和设备捆绑的过程密切相关。这样，这个SrvDscApp应用通过使用BT_module_Cntrl实例与基带进行接口，而用BT_module_Cntrl实例在进入查询模式的操作时负责指挥蓝牙模块。
注：BT_module_Cntrl可以是蓝牙协议堆栈实现的一部分或者是SrvDscApp应用的一个低级部分。正因为这样，也没有关于任何特定协议堆栈或者SrvDscApp应用实现被完成的假设，BT_module_Cntrl实例代表着一个与SrvDscApp分离的逻辑实体，它既不是SrvDscApp的一部分，也不是协议堆栈的部件或者任何相应的代码片断。
服务记录数据库在上图中显示在SDP server的右侧，它是一个逻辑实体，工作起来就像服务发现的相关信息的仓库，可被client用来查找特定服务，可被server用来发布服务。

2).配置与角色：
以下角色被定义在SDP框架中：
本地设备（LocDev）：本地设备是一个发起服务发现过程的设备。它必须至少包含蓝牙SDP框架的客户端部分：被用户用来发起发现服务过程的服务发现应用（SrvDscApp），显示发现结果的显示功能。
远程设备（RemDev）：远程设备是一种参与服务发现过程，对来自本地设备LocDev的服务查询请求作出回应。它必须包含蓝牙SDP框架中的服务器部分：即包含一个服务记录数据库，用来组成对服务发现请求的回应部分。

赋予一个设备的LocDev或者RemDev角色不是永久的也不是唯一的。某个RemDev可能像SDP客户端那样安装了SrvDscApp，而某个LocDev也可能有一个SDP Server。对于一个安装了SrcDscApp、SDP客户端、SDP Server的设备，这个设备的角色赋值是由每次的SDP会话过程决定的。因此，一个设备可以在一个特定的SDP会话中担任LocDev角色，也可能在另一次SDP会话中担任RemDev角色。由上图看出，一个没有UI的设备，不能接收用户输入并显示服务查询的结果，那么这个设备就不被看作是LocDev的候选者。但无论如何，即使这样一个设备不被看作是一个LocDev的候选者，如果运行在这个设备上的应用需要执行服务发现会话时，在下面章节的过程描述仍能应用。


上图是一个典型的服务发现结构。图中notebook作为本地设备正在查询周边的远程设备上的服务。