当前页面: 开发资料首页 → J2ME 专题 → BlueTooth探索系列（二）---发现服务框架
BlueTooth探索系列（二）---发现服务框架
摘要: BlueTooth探索系列（二）---发现服务框架
版权申明:可以自由转载, 转载请保留下面的作者信息:
作者 cleverpig(http://www.matrix.org.cn/blog/cleverpig)
关键词: 蓝牙,jsr,j2me,BlueTooth,SDP
二、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作为本地设备正在查询周边的远程设备上的服务。
↑返回目录
前一篇: Java嵌入式开发之j2me--三
后一篇: 入门-J2ME学习日记之MIDlet的生命周期