将控制 ID 和标识 ID 区分开是很重要的。标识 ID 唯一的命名了应用程序在硬件上执行一个操作的单一请求。 例如，如果一个应用程序需要在打印设备上打印一些信息并把打印出的那张纸吐出来，那么它需要通过内核向设备服务发送两个请求消息，一个用于打印，一个用于吐纸。每个请求都通过设备服务分配给它的标识 ID 来区分。相反，控制 ID 将唯一的命名产生请求的应用程序。

一个操作一结束，就会通过发送一个操作完成事件来将结果报告回来，操作完成事件包含操作结果和以前分配的 ID。如果设备服务在忙于执行前面接收到的操作请求时又收到了多个操作请求，每个请求都被放在队列中并且会按照到达的顺序被执行。这条规则的极少的特例在 J/XFS 规范中有清楚的描述（请参阅 参考资料)。

如果操作请求被取消，请求的应用程序将向 J/XFS 内核发送一个请求来取消这个操作。然后内核向设备服务传送包含取消请求和被取消的操作的标识 ID 的消息。设备服务必须有一个机制，这个机制可以尽量的停止执行操作并把设备设为操作开始前的状态，尽管这并不总是可以实现的。

状态管理

设备服务在运行时会呈现不同的状态。 大多数状态间的转换在相应的事件中会被报告给单独的或是所有的回调对象。在任何时候 J/XFS 内核都可以向设备服务发送消息请求它当前的状态。

打开和关闭设备服务

在应用程序建立了它自身、J/XFS 和 设备服务间的通信基础架构后，应用程序就已经准备好与设备服务一起工作了。但在它可以请求任何相关设备的操作之前，它必须通过请求内核打开设备服务的方式来正式的表达它要这样做的意图。在这一请求中内嵌了唯一的控制 ID。内核向设备服务发送一个请求为了操作而打开的消息。如果连接的硬件是可操作的，就通过发送一个相应的 操作完成事件来回答该请求。在这一点，设备服务对象的状态改变了；现在它“打开”来接收相关设备的操作请求。

应用程序一完成与设备服务的工作，并且在它请求内核反注册它的回调对象之前，它必须请求内核发送一个消息到设备服务，该消息包含为那个控制 ID 正式关闭设备服务的请求。此后，设备服务就不能再接受任何其它的关于该控制 ID 的相关设备的请求消息。

排它的访问请求

如你到目前为止所看到的，很多应用程序都可以请求内核为它们注册回调对象。操作请求可以以任何可能的顺序到达设备服务。多数情况下，按照接收的顺序来执行操作请求。

但有时候，一个应用程序必须确保它的请求在被执行时不受其它应用程序的干扰。在这种情况下，应用程序将通过 J/XFS 内核向设备服务发送一个要求排它访问的请求。设备服务必须有一种机制来管理来自内核的排它访问的请求。它必须能够确保在给定的一段时间中仅有一个以控制 ID 来标识的应用程序被授权了排它访问的权限。一旦设备服务成功的将排它访问和控制 ID 关联起来，仅有控制 ID 所标识的操作请求消息可以被执行。所有的其它请求都被放在队列中。

在请求排它访问的任务完成后，内核代表应用程序发送一个请求除去排它访问状态的消息。

值得信赖: J/XFS介绍，第2部分(3)

设备服务 API

既然已经对在 J/XFS 下开发设备服务的基本要求有了些认识，我们再来熟悉一下 API 规范。这一节 首先来关注一下 API 的实用编程技巧。所有的说明指的是标准版本 1.0 和它所伴有的内核实现。在 FDI for J/XFS　这节中有对软件包层次结构的解释。

状态管理

如我们前面所讨论的，设备服务对象在它的整个生命周期中呈现出不同的状态。所有可能的状态在所谓的状态类中都有规范进行定义。

JxfsStatus 类将每个设备服务可能呈现的布尔状态也归组进来。状态如下：

打开（Open）：设备已经为应用

凌众科技专业提供服务器租用、服务器托管、企业邮局、虚拟主机等服务，公司网站：http://www.lingzhong.cn 为了给广大客户了解更多的技术信息，本技术文章收集来源于网络,凌众科技尊重文章作者的版权，如果有涉及你的版权有必要删除你的文章，请和我们联系。以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢!