从脚本和其他编程环境访问设备主存的服务的制作方法

专利名称：：从脚本和其他编程环境访问设备主存的服务的制作方法从脚本和其他编程环境访问设备主存的服务背景微软公司开发了媒体传输协议(“MTP”)来管理具有存储的任何便携式设备上的内容。它基于现有协议-图片传输协议(“PTP”)，并且可被实现成完全与该协议相兼容。MTP通常用来便于连接到个人计算机(“PC”)或其他主机的设备之间的通信，交换数据，以及随后断开连接以供独立使用。MTP的第二个用途是使得能够命令和控制连接设备。这包括远程控制设备功能、监视设备发起的事件、以及读取和设置设备属性。简单设备可以实现最小MTP功能集合，这允许设备供应商使用最小的固件和驱动程序投资来开发产品。更高级的设备可以利用完整的MTP特征集合或用供应商专用插件来对其进行扩展。例如，MTP可用来传送图像、音频、视频、播放列表、或任何其他媒体对象。MTP还提供包括传输控制在内的对设备操作的直接控制，这些设备操作通过操作系统展示给应用程序。通过以可由设备访问的形式将元数据附加到对象，MTP能以便于设备用户界面的一般方式来关联诸如艺术家、专辑、风格、以及音轨等属性。MTP可用来匹配在PC上的设备内容和库之间共享的文件，以使得能够同步诸如联系人和任务列表等数据。MTP还提供用于优化内容描述的工具，该工具可以非常快速地索引具有大型存储和数千项目的设备，从而为大容量存储设备初始化操作。还可以使用引用来将文件彼此相关联，这对于创建播放列表和将DRM(数字权限管理)许可证与内容相关联而言是有用的。设备制造商可以利用MTP类驱动程序支持来帮助减少对设计、开发、以及支持专用设备连接解决方案的需求。MTP与微软Windows设备体系结构紧密且可预测地集成，这帮助降低开发第三方应用程序的成本并帮助确保与Windows的将来版本的兼容性。MTP还可被一般化并且是可扩展的，从而制造商能通过简单的缩放来为多个设备模型和类实现通用解决方案，这帮助降低固件开发成本并提高了稳定性。因为引入MTP，微软公司还开发了Windows便携式设备(“WPD”)平台。WPDAPI(应用编程接口)提供对来自微软Windows应用程序的设备连接协议的抽象以鼓励更丰富的设备生态系统。尽管MTP是首要WPD设备连接协议，但具有专用或其他基于标准的协议的设备供应商也能够在WPD框架内作为设备连接模型来注册，从而允许他们的设备对未经修改的WPD知晓应用程序也有效。WPD中的许多概念直接从MTP行为继承，并且因此WPD应用程序可用的功能中的许多与从将MTP用作连接协议的设备可用的功能直接相关。MTP已经证明很好地适用于以丰富且有用的方式表示文件系统对象和关联元数据的任务。然而，尽管MTP在许多应用程序中表现得完全令人满意，但一般仍然需要利用该协议并维持与它的兼容性的附加特征和功能。提供本背景来介绍以下概述和详细描述的简要上下文。本背景不旨在帮助确定所要求保护的主题的范围，也不旨在被看作将所要求保护的主题限于解决以上所提出的问题或缺点中的任一个或全部的实现。概述提供了用于通过MTP协议向主机应用程序或进程展示客户机设备上的自描述的设备主存的服务的安排，包括新MTP命令的MTP扩展通过该安排使得该设备主存的服务能够向后和向前兼容现有MTP实现。该扩展中的新MTP命令使得诸如在PC上运行的主机应用程序等主机应用程序能够发现由连接客户机设备提供的设备主存的服务。在一说明性示例中，设备主存的服务包括用服务特征来补充传统MTP存储的存储服务、支持主机和客户机设备之间的基于消息的交互的功能设备服务、以及可简单地向主机呈现信息的丰富的静态数据集而非提供附加存储或功能能力的信息服务。这些设备主存的服务有利地允许主机和客户机设备之间的更丰富的通信。还提供了一组方法来获取设备上存在的任何这样的设备主存的服务并通过利用可脚本化或其他编程环境将该功能展示给例如基于web的客户机应用程序以及其他薄客户机解决方案。提供本概述是为了以简化的形式介绍将在以下详细描述中进一步描述的一些概念。本概述不旨在标识所要求保护的主题的关键特征或必要特征，也不旨在用于帮助确定所要求保护的主题的范围。附图描述图1示出其中主机和客户机设备使用MTP进行通信的说明性MTP环境；图2示出图1所示的客户机设备所支持的说明性服务体系结构；图3示出可被MTP的现有实现利用的说明性一般化对象分层结构；图4示出与现有MTP存储模型下的存储的特定示例相关联的说明性对象分层结构；图5示出发起者与响应者之间的、与设备主存的服务查询相关联的说明性命令_响应消息流；图6示出通过利用设备主存的服务来修改的说明性一般化对象分层结构；图7是包括存储服务、功能设备服务、以及信息服务的一组说明性设备主存的服务的表示；图8是示出与功能设备服务相关联地实现的对象传输的说明性消息收发流程图；图9示出与添加/移除设备主存的服务相关联的、发起者与响应者之间的说明性命令_响应消息流；图10是示出从一个设备主存的服务将服务行为继承到另一个的说明性模型的示图；图11示出用于在脚本或其他编程环境中向自动化客户机展示设备主存的服务的说明性安排。各附图中的相同的附图标记指示相同的元素。详细描述传统上，PC将设备看作加入机箱内部的槽内并提供它们被建造来提供的特定功能的固定功能硬件。例如，视频卡总是将计算机存储器中的图像转换到显示设备，调制解调器总是提供一种用于创建与另一调制解调器的通信链路的方式，或硬盘控制器总是允许数据从计算机存储器传送到磁存储接口以供更持久的存储。在某些情况下，这些设备物理上未安装在计算机中——它们可以简单地连接到计算机。打印机(像视频卡一样)总是只将存储器中的某些数据转换成纸张上的物理表示。消费者购买越来越多的不遵守该简单的“单功能”模型的新设备。这些设备由诸如移动电话、便携式媒体播放器、个人导航设备、个人信息管理器、以及其他“便携式”计算设备等电子装置表示，它们正变得更加复杂，具有更多功能，且通过添加自定义应用程序而变得更有能力支持丰富的消费者自定义。然而，迄今，这些设备中的大多数仍然以固定功能方式与PC交互。例如，移动电话可作为三个固定功能设备-调制解调器、文件共享设备、以及音频输出设备-来连接。这通常是有问题的，因为许多桌面平台不能稳健地处理同一设备正展示多个不同功能的事实。在许多方面，该行为是设备用来连接到PC的技术的直接结果。大多数设备通过对等的基于电缆的连接模型连接，如USB、蓝牙、IDE(集成/智能驱动器电子设备)、SATA(串行高级技术附件)、或其他点对点模型。在这些通信链路上运行的协议是目标或任务专用的，几乎没有用于新功能的空间。在启用新功能的情况下，它通常以功能专用可扩展性的形式而非丰富的一般可扩展性模型的形式出现。另外，向协议或设备添加附加功能的过程需要在管道的两端编写和安装新驱动程序。这对设备制造商造成负担，因为它现在必须在所有所需主机平台上不仅要为设备创建固件还要创建适当的驱动程序以充分利用该功能。在TCP/IP(传输控制协议/因特网协议)连网世界内，丰富的连接构造使得能够开发更丰富的数据交换模型。非常任务专用的协议，如对等电缆世界中的那些协议仍在大量使用，包括用于传递电子邮件(例如，通过“STMP”-简单邮件传输协议)的协议、用于检索文件(例如，通过“FTP”-文件传输协议)和数据流(例如，通过“HTTP”-超文本传输协议)的协议、或用于打印文件(使用“LPR”-远程行式打印机)的协议，但它们是经过更高层的“协议”行为扩充的。在OSI(开放系统互连)模型术语中，协议曾经在栈的最高层(即，应用层)考虑，其本身被用作更丰富的数据交换的表示手段。例如，考虑HTML(超文本标记语言)如何变成HTTP顶层的协议。在其核心，HTML实际上是用于交换关于一组元素在页面上的布局的信息的协议。然而，通过扩展和脚本模型，HTTP上的HTML已经成为传递完整应用程序的方式，从而允许开发新的丰富的web客户机连同自定义行为和丰富的可扩展性。HTTP如何从应用程序转移到表示协议的另一示例是web服务。在该环境中，对远程执行操作的请求是通过HTTP表示来携带到远程主机的。web服务和面向服务体系结构的引入极大地改变了解决分布式计算问题的方式，并且鼓励了更加集中于服务的体系结构。实际上，在web主存的基于HTML的客户机应用程序内使用web服务只在表示层增加了HTTP协议的价值。这些解决方案的增长的关键是以下事实HTML和web服务两者都为薄客户机开发者提供了利用这些技术来产生丰富的分布式解决方案的新的丰富方式。通过创建可在其上构建面向服务体系结构的强大解决方案，web服务还使得更厚客户机以与薄客户机相同的方式受益。许多最新和大多数流行网站广泛使用高级HTML协议类特征和web服务类特征来传递它们的功能。在对等的电缆连接环境中，出于在类似层保持设备能力和连接数据交换的目的，存在对将传统上被视为“应用，，层协议的协议类似“重新因式分解”成“表示”层协议的需求。然而，与TCP/IP世界不同，不是所有都已经在同一底层传输协议上运行。这些缺点由本发明的对设备主存的服务的安排来解决，对MTP协议的扩展通过该安排启用其中可开发和利用设备主存的服务来允许MTP主机和客户机之间的更丰富的数据交换的环境。通过在web以及其他薄客户机环境中展示设备主存的服务的脚本接口，这样的设备主存的服务的力量还可扩展到web体验以及其他薄客户机解决方案。要强调的是，MTP中的术语“媒体”用来标识任何二进制数据，并且因此不限于其通常所适用的音频/视频格式。非音频/视频对象的某些典型示例包括联系人、程序、预定事件、以及文本文件。在MTP会话传输期间，需要将媒体对象表示为原子二进制对象，但不需要将其以同一格式或结构存储在设备上。媒体对象可以按需创建，只要它们在内容枚举期间被准确地表示。MTP对象不仅包括文件的二进制内容，还包括描述性元数据和引用。设计MTP以使得对象可以通过在该协议中提供的机制来识别，而无需理解该文件本身的二进制格式。因此，在MTP中，“对象”是二进制文件、其描述性元数据、以及任何对象内引用的组合。还可以明白，MTP所定义的设备行为在微软Windows平台内使用WPD来表示。尽管此处的材料根据MTP实现来描述，但WPD框架内也存在使得微软Windows应用程序可以利用对MTP所作出的扩展以解决这些缺点的类似实现。此外，因为WPD作为抽象代理的本质，构造此处描述的材料的替换实施例是可能的，这些替换实施例通过直接或间接使用与在此描述的那些相类似的形式和实现来向MTP提供类似或相同功能而不使用MTP协议本身。现在转向附图，图1示出其中主机102和客户机设备110使用MTP进行通信的说明性MTP环境100。MTP是基于对象的协议，其对设备能力、对象、以及对象属性进行抽象以便可以独立于设备实现来将它们与主机进行交换。微软公司至少部分地响应于用户在将他们的诸如媒体播放器等便携式设备连接到基于Windows的PC时所经历的困难而开发了MTP。在硬件供应商引入第一便携式设备时，来自每一供应商的设备使用专用协议来与计算机进行通信。每一供应商提供了在基于Windows的PC上运行以与他们的设备进行通信的驱动程序。用户不能够使用这些便携式设备，直到他们定位并且安装了他们的设备的适当驱动程序为止。为改进用户体验和解除硬件供应商编写驱动程序的任务，微软定义了MTP来作为用于在媒体播放器和Windows计算机之间进行通信的标准化协议。代替专用驱动程序，微软提供在基于Windows的计算机上运行的通用MTP驱动程序。该MTP驱动程序与所有兼容MTP的设备进行通信并且一般作为Windows操作系统的一部分来提供。用户可以简单地将设备连接到Windows计算机以使该设备能够与该PC进行通信而无需进一步的设置。微软将MTP协议定义成对用于数字静止照相机的PTP的客户机扩展。对于关于PTP的信息，请参见PIMA15740(PTP)规范“用于数字静止摄影设备的图片传输协议(PTP)”，原来称为摄影和图像制造商协会(“PIMA”)的国际图像工业协会(I3A)(请参见http://WWW.i3a.org/)支持版本1.0。MTP规范例如可在http//download,microsoft,com获得。MTP当前也提交到USB实现者论坛并被评估，并且将来可能被合并到USB-IFMTP版本1.0中。要强调的是，尽管本文图1所示并描述的说明性示例在Windows操作系统环境中实现，但本发明通过MTP对设备主存的服务的安排不限于Windows实现或基于Windows的服务。取决于特定应用程序的要求，其他普遍使用的操作系统环境可用于通过MTP协议来支持设备主存的服务。例如，当前存在用于Apple、UNIX、以及Linux操作系统的MTP实现。MTP交换一次只可在两设备之间发生，并且在每一次通信中，一个设备担当“发起者”而另一个设备担当“响应者”。发起者是通过向响应者发送操作来发起与该响应者的动作的设备。响应者可以不直接发起任何动作(但响应者向主机发送对服务的“事件”请求从而发起动作是可能的)，并且可以只发送对发起者所发送的操作的响应或发送事件。设备可以担当发起者、响应者、或这两者。设备如何最初确定其将在MTP会话中担当发起者还是响应者将以传输专用的方式定义为发现过程的一部分。在图1所示的说明性MTP环境100中，主机102通常是发起者而客户机设备110是响应者。如图1所示，主机102被配置成台式PC而客户机设备110被配置成移动电话。然而，要强调的是，这些特定设备及其作为发起者和响应者的角色仅仅是说明性的，因为本发明通过MTP对设备主存的服务的安排可灵活地应用于各种兼容MTP的设备中的任一种，并且取决于特定使用场景任一设备都可担当发起者或响应者(或两者)。这样的兼容MTP的设备一般可定义为具有一定量的存储的、以二进制格式消费或产生媒体对象的电子设备，这些设备与其他设备具有间歇性的连接并且在不连接到另一设备时实现其主要目的。兼容MTP的设备一般主要担当媒体消费者或媒体生产者，但这一分界线正日益变得模糊。另外，尽管媒体对象在MTP环境100中普遍使用，但MTP实际上还允许传输可由大多数现代文件系统表示的任何类型的文件，并且因而本发明的设备主存的服务不限于仅仅处理媒体对象。兼容MTP的设备(即，当前使用MTP或具有使用它的能力的那些设备)的一些示例包括数码相机(静止和视频两者)、音频和/或媒体播放器、移动电话、PDA(个人数字助理)、袖珍PC、智能电话、手持式游戏播放器、GPS(全球定位系统)、以及其他导航设备、以及提供这些功能中的一个或多个的组合的设备。这些设备一般是便携式的。主机类设备通常包括例如台式PC、膝上型以及笔记本PC、游戏控制台、以及被配置成支持MTP能力的其他类型的消费电子设备。然而，主机和设备的特定角色不必总是严格地定义，因为某些主机类设备能够用作客户机设备，反之亦然。并且，如上所述，客户机或主机中的哪一设备担当发起者和响应者的相应角色也可以变化。如图1所示，使用MTP协议栈来对称地配置主机102和客户机设备110以允许通过MTP会话的双向通信。因此，主机102具有发起者MTP协议栈116，而客户机设备具有响应者MTP协议栈121。这些相应的MTP协议栈提供相似功能，但各自通常被配置成在它们在其上操作的相应设备的能力所施加的限制内工作。主机102和客户机设备110还用向相应主机和客户机硬件提供基本接口的相应物理层127和130来配置，该主机和客户机硬件可以例如经由诸如USB(通用串行总线)或用于在设备之间实现例如IP(网际协议)或蓝牙连接的其他网络驱动程序等驱动程序来实现。MTP旨在是传输不可知的，并且可通过多个底层传输机制来运作。这一特征允许在通过不同模型中的不同传输或甚至同一设备内启用的多个传输进行连接时优化设备实现。然而，MTP要求底层传输具有一定质量，以根据MTP规范来高效地运作。在该说明性示例中，使用USB来实现传输，并且使用USB电缆134来耦合主机102和客户机设备110。然而，在本发明的安排的其他实现中，例如经由IP(有线或无线)或经由蓝牙提供连接是合乎需要的。如上所述，MTP驱动程序138通常在Windows操作系统中实现，并且具体作为用户模式驱动程序来实现。MTP驱动程序138通过基于组件对象模型(“COM”)的Windows便携式设备(“WPD”)层140来接口，以使不同主机应用程序146能够参与同客户机设备110上的资源的MTP通信会话。这样的资源可包括例如，客户机设备应用程序153、存储、媒体对象、以及设备主存的服务158。关于WPD的进一步的信息可在http://download,microsoft,com获得。设备主存的服务在图2中更详细地示出。在该说明性示例中，设备主存的服务包括存储服务205、功能设备服务213、信息服务215、以及用于实现对来自在主机102(图1)上操作的脚本和其他编程环境的设备服务的可访问性的脚本设备服务218。以下将依次描述这些服务中的每一个。参考存储服务205，注意，与诸如SCSI(小型计算机系统接口)、ATA(高级技术附件)、或USB大容量存储等其他基于文件系统的传输协议不同，MTP与特定文件系统语义无关。事务在设备的对象存储中而非在扇区、磁轨、或文件系统中的文件中操作对象。每一对象包含数据流(文件的内容)和与该对象相关联的属性集合(文件信息、元数据等)。还定义了表示文件夹和其他关联(媒体专辑)的特殊对象。在这些情况中的每一种中，数据流通常是空的并且只有属性定义该对象。对象还与表示其上存储对象的物理或逻辑介质片段的存储相关联。这些存储(像对象一样)具有与其相关联的有限的属性集合，这些属性允许它们表达诸如类型(固定或可移动)或结构(平面的或分层的)等信息。另外，存储被绑定到设备对象。这些对象表示整个设备并描述其能力以及诸如名称、制造商、所支持的命令数量和类型、以及所支持的对象格式的数量和类型等信息的总体。还存在为不同的设备行为(例如，照相机的当前快门速度)提供默认属性值的附加设备属性。如适用于该类系统的，所有MTP属性、对象、格式、以及命令都能够通过明确定义的机制来扩展。当今存在来自多个供应商的MTP设备对象存储的多个不同实现。然而，MTP具有在操作期间出现的若干低效性。尽管MTP被定义为对在何处存储和如何存储对象是不可知的，但在通常使用中，其几乎专门用于将对象从一个媒体存储复制到另一个。然而，作为该过程中的代理，MTP只具有对定义要如何在目的地设备上存储对象的有限支持。即，如果特定文档文件要存储在设备上的特定位置中，则不存在设备通过MTP提供的关于该位置的提示。设备也不指定照片要存储在特定位置中而音乐存储在另一位置。MTP的用户只能使用惯例来确定在何处以及如何组织文件。例如，微软Windows媒体播放器在媒体对象上施加了分层结构，当今其表示在MTP所展示的存储上存储媒体内容的情况下的事实标准。然而，随着诸如联系人对象(即，名字、地址、头衔、公司、电话、电子邮件地址等)等新形式的MTP对象投入使用，不存在定义应该如何或在何处存储这些对象的现有事实标准，也不存在指示设备想要它们被存储在何处的方式。设备上的对象通常被看作“文件”而非适当的对象。尽管MTP围绕对象存储模型来设计，但大多数用户仍然将其当作将文件从一个位置移动到另一个位置的方式。这意味着不具有数据流的对象被当作文件而非基于属性的对象。另外，给定当今文件存储的主要MTP使用模型，大多数MTP实现优化了其对象存储来表示文件系统的内容。在引入对象专用行为时(包括其中不存在二进制数据流的情况)，这会引发问题。尽管MTP与对象的存储有关，但其对象存储通常是文件系统的丰富视图的事实将存储的概念限于与特定设备上的不同文件存储卷直接相关联。MTP存储通常与设备上的物理或逻辑存储映射11。这暗示MTP不具有“对象存储”的丰富概念，其可以是文件系统(例如，数据库)中的文件而非特定物理存储卷或其某逻辑分区。因为存储表示物理介质，所以它们通常作为其上可存储文件的不同物理位置而存在于主机用户界面中。例如，在内部闪存和可移动存储设备(如闪存卡)上具有存储空间(文件系统)的MTP客户机设备通常使得MTP主机用户体验示出该设备上的两个存储位置(“设备”和“闪存卡”)，与向连接到同一台式PC的硬盘驱动器如何呈现它相类似。如果客户机设备实现者决定展示包含一种特定类型内容的另一“虚拟”存储，则这一存储也将与其他物理存储一起作为标准存储用户体验的一部分来显现。这可能是不适当的，因为MTP不严格要求对象存储中的对象是兼容文件系统的对象。当前，格式和能力被绑定到设备并且不绑定到它们所在的存储。主机实现假定设备上的所有存储都能够支持列出的所有格式。然而，如果为一种特定类型的数据保留特定存储，则在尝试向该特定存储存储无效类型的数据的情况下，用户可能面对不想要的体验。为克服这些问题中的许多问题，MTP当前转向批量枚举的概念。基本上，设备的全部内容按格式或位置以很高的性能成本来枚举，并且“最强大”的主机根据其自己所需的行为来执行对象的丰富聚集和表示(例如，Windows媒体播放器中的媒体库视图)。尽管这一模型对基于台式PC的主机很有效，但出现了具有有限资源来管理其可用存储器内的视图的更多消费电子主机。从MTP客户机实现者的观点看，这提出了附加挑战，因为枚举现在可能不再只限于文件系统的内容。再一次使用联系人对象的示例，在尝试在使用当前MTP体系结构的设备之间传输联系人对象时存在所导致的若干分支。MTP当前未在设备上定义存储联系人的位置。一个设备供应商可选择在不在根上的被称为“联系人”的文件夹中存储联系人，而另一个设备供应商可选择将“联系人”文件夹存储在该设备的根处的被称为“个人信息”的另一文件夹内部。尽管两种方法同样有效，但没有用于向主机应用程序通知这是对这些位置的预期使用的现有方法。例如，根据MTP，Outlook可选择在第三位置(根下的“Outlook”下的“联系人”文件夹)中存储联系人。然而，因为设备不识别这一联系人文件夹，所以它不能够呈现这些联系人作为设备联系人用户体验的一部分。MTP当前将所有对象看作文件。因此，联系人可被看作文件系统对象-基本上其中数据流为空的对象，因为所有属性完全描述该对象。设备制造商当今作出的假定通常导致创建空文件，因为对象表示文件。因此，用户在看到这些文件后，将并非必然能够对它们做任何事，并且将可能怀疑它们为什么出现。MTP当前假定所有存储都是物理的。因此，例如，假定联系人存储在联系人数据库中而非作为文件存储在文件夹中。如果联系人数据库而非其中的联系人被表示为文件存储中的一项，则该数据库将经由标准MTP枚举模型作为特定存储设备上的单个文件系统对象来枚举。为实际上展示联系人，MTP客户机实现将需要对联系人文件进行特例处理，并将其作为可被进一步枚举以发现各单独的联系人的“虚拟”文件夹来处理。MTP主机实现通常将所有可用存储当作设备上的不同物理存储。例如，考虑选择创建其上将存储联系人的独立存储而非将它们当作“虚拟”文件夹的MTP客户机设备实现者。这具有将该独立存储展示为设备上的新物理存储的不幸结果。尽管这对联系人而言是可接受的，因为新存储都以该方式展示(日历、邮件、凭证、信用卡/钱包等)，这使得与可以将特定对象存储在何处相比，用户更加难以区分可将文件存储在何处。MTP对象格式被绑定到设备。继续该将联系人数据库展示为独立MTP存储的说明性示例，客户机和主机实现必须处理一下事实设备在该设备上的不同存储中支持不同类型的格式。这可进一步复杂化用户对该设备的体验，因为用户不仅必须知道每一存储上能存储什么类型的数据，还可能有尝试将数据置于用户相信它所属的位置而没想到被告知这一位置不支持的不幸体验。MTP依赖于批量枚举来设法解决这些问题中的许多问题。在其中MTP客户机设备通常只表示一种类型的对象存储(通常是媒体存储)的当今世界，这是对向用户隐藏设备的物理实现的合理解决方案。然而，在添加联系人数据存储时，增加了主机和客户机设备实现的枚举复杂性。在主机上，应当在大多数设置中添加附加代码和存储器以与媒体条目分开收集和管理联系人条目。这在主机在较不强大的消费电子设备上执行的情况下是不合理的。在客户机设备侧，枚举现在因以下事实而复杂化来自多个源的不同类型的数据必须绑在一起以完成枚举请求。鉴于这些低效性，为拓宽MTP处理非文件绑定数据类型的有效性，提供了称为“设备主存的服务”的包括如上所述的存储服务205的新枚举模型。该模型矫正了上述限制中的许多限制，而同时解决了当今MTP中存在的其他可扩展性挑战。图3示出可被MTP的现有实现利用的说明性一般化对象分层结构300。该对象分层结构的顶部两层，即分别由附图标记310和320所指示的客户机设备和存储比该分层结构300中的更深的层更严密地定义。标准MTP枚举首先使用MTP命令GetDevicelnfo(获取设备信息)来标识并提取关于设备的信息，并使用命令GetStorageIDs(获取存储ID)和GetSt0rageInf0(获取存储信息)来标识并提取关于其附连存储的信息。除该点之外，通过与标准WindowsWin32文件系统API类似地操作的任何数量的批量操作来完成枚举，以定位特定类型的文件(例如，通过扩展搜索)、表示该分层结构(例如，寻找目录)、并获取关于每一文件的信息(例如，打开文件或获取文件系统目录信息)。图4示出与现有MTP存储模型下的存储的特定示例相关联的说明性对象分层结构400。在该示例中，名为“存储0”的存储411展示客户机设备422上的音乐文件夹413和文本文件夹415。音乐文件夹411包括相应艺术家“艺术家1”和“艺术家2”的两个艺术家文件夹430和435。如图所示，艺术家文件夹430包括多首歌曲438m通过比较图3和图4所示并在下文中描述的现有MTP存储模型，在本发明的设备主存的服务模型中，修改了枚举客户机设备的方式而仍然维持与当前MTP实现的向后兼容性。这一修改通过创建包括新操作的MTP扩展来实现，这些新操作被配置成使发起者能够找出并访问响应者上的通过设备主存的服务展示的特定类型的内容。尽管MTP当前支持按格式枚举，但新命令允许只处理特定内容类型的应用程序的更大灵活性。新MTP命令在下表1中示出。操作码操作名0x9301GetServiceIDs(获取服务M)<table>tableseeoriginaldocumentpage11</column></row><table>表1GetServiceIDs命令用于返回可以与MTP扩展中的另一新命令GetServiceInfo相关联地使用的服务标识符阵列(即，列表)。GetServicelnfo命令将服务ID(ServiceID)当作参数，并用于返回该服务ID参数所标识的特定设备主存的服务的、名为“服务信息(ServiceInfo)，，的静态服务定义数据集。服务信息数据集一般被安排成定义设备主存的服务的核心属性和交互性元素。该数据集可以例如由诸如移动电话制造商等媒体设备客户机供应商在需要时来定义，以实现所需功能和特征集合。服务信息数据集还用于将设备主存的服务展示为功能对象。在该说明性示例中，该功能对象在使用进行中COM服务器来实现以与MTP驱动程序138(图1)进行通信的基于对象的WPD基础结构中使用。因此，MTP驱动程序138读取服务信息数据集来创建对应的WPD功能对象。服务信息数据集在下表2中示出。<table>tableseeoriginaldocumentpage12</column></row><table><table>tableseeoriginaldocumentpage13</column></row><table>表2如图所示，尽管服务信息数据集可被安排成包含多个条目，但出于枚举目的的重要条目是包括了MTP存储ID。存储ID标识保持给定服务的内容的存储，其并非必需表示物理存储。存储ID如果存在则可在接受例如经由现有GetStorageInfoMTP命令使用传统枚举来检索到的存储ID的任何操作中使用。与传统存储实现一样，在设备上一次具有服务⑶ID(其中“⑶ID”是全局唯一标识符的首字母缩写)类型的特定服务的不止一个实例是可能的。例如，考虑移动电话上的能够在设备存储器中以及在SIM(用户身份模块)卡上存储联系人的联系人服务实现。这些存储位置中的每一个通常用不同的能力来配置，例如SIM卡限于每一条目的名字和电话号码，并且各自都使用该服务基础结构来适当地建模。为使得这些服务能够彼此区分，通过持久唯一标识符(“PUID”)向每一服务分配不同的计算机可读全局唯一标识符。该服务PUID随后可用来表示该服务的通过设备110到主机102的多个连接的特定实例。在本发明的设备主存的服务中使用的其他数据集包括服务属性和服务能力。名为“服务属性列表(ServicePropertyList)”的服务属性数据集提供一种用于设置设备主存的服务属性的可修改机制，并且与当前MTP协议中的现有对象属性列表(ObjectPropList)数据集相似。服务属性列表数据集在下表3中示出。<table>tableseeoriginaldocumentpage14</column></row><table>表3GetServicePropertyList命令将服务ID作为参数，以返回该服务ID参数所标识的特定设备主存的服务的服务属性列表数据集。还可以使用可任选服务属性码(ServicePropCode)参数。如果使用，则客户机设备110(图1)将返回只具有单个指定属性值的服务属性列表数据集。如果不使用该可任选参数，则客户机设备110将返回该服务ID参数所指定的设备主存的服务的所有服务属性值。GetServicePropertyList命令以与当前MTP协议中的GetObjectPropList(获取对象属性列表)命令相类似的方式操作。同样，以与SetObjectPropList(设置对象属性列表)相类似的方式使用SetServicePropertyList命令来向设备发送属性信息。名为“服务能力列表(ServiceCapabilityList)”的服务能力数据集包括可用来限制对给定对象的支持的一组属性。示例包括将所支持的位速率限于MP3文件(运动图像专家组“MPEG”音频层3)或对联系人的读/写能力。能力通常按照设备主存的服务来定义，并且设备级能力(如在现有MTP设备信息(Devicelnfo)数据集中定义的那些能力)可以用服务专用能力来覆盖。服务能力列表数据集在下表4中示出。<table>tableseeoriginaldocumentpage15</column></row><table>表4GetServiceCapabilities命令将服务ID作为参数，以返回该服务ID参数所标识的特定设备主存的服务的服务能力列表数据集。还可以使用可任选格式码(FormatCode)参数。如果使用，则客户机设备110将只返回该设备主存的服务的该指定格式的能力。如果不使用该可任选参数，则客户机设备将返回设备主存的服务专用的所有所支持格式的能力。添加到设备服务的又一特征是定义服务专用事件的能力。像其他服务元素一样，这些事件根据名称和全局唯一ID(“⑶ID”)来标识。当前，MTP事件被定义为返回3个32位的值。同样，服务事件使用该同一结构并允许该服务定义如何解释对每一事件返回的这3个32位的值。图5示出发起者502(例如，图1的主机102)与响应者510(例如，图1的客户机设备110)之间的、与设备主存的服务查询相关联的说明性命令-响应流500。消息流500示出由发起者502执行的对表1中的MTP命令的使用和来自响应者510的响应。如图所示，命令-响应消息交换520包括GetServiceId(获取服务ID)命令和包括服务标识符列表的响应。消息交换526包括GetServicelnfo命令和作为响应的服务信息数据集。消息交换530包括GetServiceProperty命令和作为响应的服务属性列表数据集。消息交换535包括GetServiceCapabilities命令和作为响应的服务能力列表数据集。消息交换542包括SetServicePropertyList命令和相关联的数据(服务属性值)或数据集。来自响应者510的响应将以与当前MTPSetObjectPropList命令/响应相类似的方式来指示确认(例如，如图所示的“0K”)或适当的状态或出错消息。图6示出MTP根据本发明的设备主存的服务枚举所提供的修改所看到的说明性一般化对象分层结构600。在该所示示例中，枚举了两个设备主存的服务，服务I(由附图标记610标识)和服务II(由附图标记616标识)。如图所示，服务I610不与存储相关联，而服务II616与保持媒体对象6和7的存储C620相关联，媒体对象6和7分别由附图标记626和629指示。引入设备主存的服务导致对当前MTP实现所提供的用于枚举存储在设备上的对象的传统访问模型的某些暗示。为确保附连到访问的存储不被不知道该服务模型的传统主机看到，不将与服务相关联的存储作为GetStorageID的响应来返回。从基于服务的枚举的观点看，传统存储被认为是默认“传统服务”的一部分，并且必须继续经由传统GetStorageID操作来枚举。以此方式，较旧客户机设备仍然能够连接使用该设备主存的服务模型的主机设备并与其一起工作。为维持向后兼容性，服务作者必须知道对现有MTP批量操作命令的支持需要对服务数据对象指定的MTP格式码，且方法对象在该设备的域内是唯一的。然而，没有施加将同一格式码用于两不同设备上的同一对象的限制。例如，如果MTP格式码0x3009要由特定设备上的一个服务用来暗示格式A的对象的存储，则其不可由第二服务在同一设备上用来暗示格式B的对象的存储。然而，在来自同一或不同制造商的另一设备上，取决于设计选择，服务作者可以选择使用MTP格式码0x3009来表示任何服务上的格式B的对象的存储。因为服务表示对传统MTP行为的附加，所以不将在服务内定义的格式作为标准MTP“设备信息”数据集的一部分来列出也是重要的。只有服务知晓主机102才被启用来经由GetServicelDs/GetServicelnfo模型发现服务格式。这还暗示在设备级对服务知晓实现作出的批量枚举请求必须继续在设备级操作，以维持与非服务知晓实现的兼容性。图7示出设备主存的服务的若干特定说明性示例的MTP对象分层结构700。这些服务包括在客户机设备110上提供的存储服务205、功能服务213、以及信息服务215。存储服务205包括联系人服务TlO1、日历服务7102、以及铃声服务7103。功能服务213包括电话服务7104、状态服务7105、以及设置服务710N_lt)提示服务710N是信息服务215的示例。要强调的是，这些服务710(存储、功能、以及信息)仅仅是说明性的，并且在特定媒体设备客户机上提供的这些具体数量、类型、以及服务的混合一般取决于应用程序的需求并可以与图7所示的不同。例如，尽管并未示出，但SMS(短消息系统)数据和/或壁纸也可通过本发明的设备主存的服务安排来展示。如图所示，存储720U...H附连到相应设备主存的服务710联系人服务TlO1、日历服务7102、以及铃声服务7103分别展示来自客户机设备110中的其相应附连存储720的联系人、日历数据、以及铃声。存储服务205与现有MTP存储类似地操作。然而，本发明的设备主存的服务机制提供对存储中存储了什么类型的数据和如何使用该数据的增强的描述级别。另外，尽管所有存储服务由客户机设备上的某存储位置备份(并且因而在该说明性示例中可被认为与传统MTP存储等效)，但不要求存储在与物理存储设备11的基础上表示。存储可以是文件系统、数据库、或任何数据集合。有利的是，设备主存的服务的关键特征是它们被安排成自描述，以便不限于MTP内的现有可扩展性模型。这一特征使得设备主存的服务的消费者能够只通过发现它并读取该服务描述来正确地利用该服务。作为比较，现有MTP行为、格式、以及对象都以标准组织或扩展作者所维持的主纸质规范描述。这样的规范包含MTP中全部“已知”格式和属性的列表。这些格式和属性是16位的值，且使用受限的位模式来表示他们的类型。因为这一安排，MTP往往需要修改主存MTP栈以使得能够使用新行为、格式、以及对象。大多数MTP主机实现执行在设备固件中建立的、MTP格式世界或MTP功能世界与某本机的平台专用模型之间的映射。如此，必须更新这些映射表或功能占位程序来处理已经定义的新格式、属性、或功能。因此，服务信息数据集的目标中的一个是携带足够信息，以使主机MTP协议栈(例如，图1中的发起者MTP协议栈116)可在不必修改的情况下代理主机上的未知软件片段与客户机设备之间的交互。另外，如上所述，虽然MTP当前支持用于允许定义新格式、属性、以及功能的扩展机制，但它不以保证唯一性和兼容性的方式来这样做。尽管可能认为当前模型在数学上足以支持大多数实际用途，但它不保证兼容性，因为两个供应商能容易地且合法地使用同一值来指两个非常不同的事情。用于冲突解决的当前模型需要这些扩展互斥，以使没有一个设备可以在冲突中使用这些扩展中的两个。因此，难以将这些项认为是唯一的。设备主存的服务的自描述本质用于通过将格式、属性、以及功能提升到更大名字空间(按GUID来表示)来解决这一问题。这使设备制造商能够在他们的设备上指定任何MTP适当值，同时仍然维持与同一服务的所有实现的兼容性而不管制造商为何者。通过自描述，设备主存的服务具有指定描述它们对对象类型所施加的限制的能力的能力。这在特定服务需要将对对象的支持限于特定格式或特定格式子集的情况下是有价值的。使用铃声服务7103的示例，该服务可在将该服务上的所有文件限于MP3格式、128kbps位速率或更少、以及持续时间小于30秒的设备上获得。在本说明性示例中，这些限制有服务能力列表数据集来提供。尽管当前MTP协议下的现有方法能够在设备级处理这一点，但没有在存储级表达这些限制的方式，所以在文件被复制到该铃声位置的情况下，设备必须拒绝它们为“无效”(用户接收到诸如“不支持”错误等)而非使主机计算机转换内容的代码以满足要求。另外，不需要将设备主存的服务只限于服务信息数据集中可用的信息。将服务认为对象本身并且在需要时能够脱离服务请求属性是合理的。现转向功能设备服务213，功能服务的一般模型是将功能请求当作现有MTP协议内的对象传输。简化处理在图8所示的说明性流程图800中示出。发起者802(例如，图1的主机102)和响应者810(例如，图1的客户机设备110)利用“各方法”来实现功能服务。在此，各方法与常规web服务中的调用类似——它们是在发起者802与响应者810之间交换以传递与可执行命令相关的信息的对象。发起者802向响应者810传递方法对象属性816，响应者810将响应820发送回发起者802。发起者802随后等待完成事件从响应者810返回，如附图标记825所示。在本发明的设备主存的服务的许多应用中，方法对象不具有二进制净荷。相反，它将是具有属性列表的0字节对象。然而，在替换应用中，该方法对象可任选地以二进制实现，如附图标记822所示。响应者810处理方法对象属性816，如附图标记832所示，从而执行功能服务213所提供的功能。在完成处理之后，如附图标记835所示，从响应者810向发起者802传递方法完成事件840。在接收到方法完成事件840后，发起者802可以使用方法对象属性请求842检索来自响应者810的属性或信息。同样，本发明的设备主存的服务的许多应用将只需要检索属性，然而，替换应用可使得检索来自方法对象的结果846。一旦检索到了所得信息，则发起者802删除该方法对象来为下一方法对象让路，如附图标记843所示。发起者802向响应者810发送删除方法对象850。如附图标记854所示，该方法对象在响应者810处被删除并且未被响应者810存储来用于稍后检索。可以明白，为说明简明起见，在图8中只示出单个代表性调用序列。响应者810—次可以支持不止一个方法调用-在同一设备服务上或在另一服务上调用同一方法或调用不同方法。再次参考图7，功能服务213的示例是电话服务7104。在该示例中，考虑图1中的主机102对客户机设备110作出的拨打电话号码并将传入和传出音频流遥控到主机102的功能请求。表示电话行为的功能电话服务7104被定义为具有要接受参数(即电话号码)并返回结果的动词“拨打”的行为。为发起拨打操作，主机102使用现有MTP命令SendObjectPropList来向电话服务发送方法对象，如上在图8所附随的文本中所述，且格式被指定为拨打动词和电话号码的相关联的属性。客户机设备110执行拨打电话所需的工作，并且在连接或出错条件下，通知主机动词对象已经改变。客户机设备Iio随后经由现有MTP命令GetObjectPropList请求该操作的结果。该操作的结果将作为该动词对象上的属性来出现。在成功结果的情况下，这些属性可包含表示所请求的呼叫的呼叫对象的对象ID以及要用来发送/接收该呼叫的编码音频的流的ID。尽管“服务信息”数据集包含关于特定方法对象的格式和名称的信息，但它不包含关于服务方法操作的这些属性(或用方法术语是自变量)的细节。因为方法对象显得与MTP内的标准数据对象一样，所以现有操作-GetObjectPropsSupported(获取所支持的对象属性)和GetObjectPropDesc(获取对象属性描述)_能够被重用来发现这一信息。为便于服务行为和命名管理，对GetObjectPropDesc属性形式进行添加以允许详细的自变量信息，包括要提供的名称、全局唯一标识符(即GUID)、参数次序、以及自变量使用(输入、输出、输入/输出)。另外，引入了新形式来支持更丰富的面向对象的行为，包括将自变量定义为表示特定格式的对象的对象ID的能力。与存储一样，服务是动态的一它们可以在需要时由客户机设备110添加或移除，如图9中的说明性消息流900所示。在发起者902(例如，图1中的主机102)与响应者910(例如，客户机设备110)之间交换服务添加事件920，以指示新服务在响应者910上可用。图9中的其他消息(分别由附图标记926、930、以及935所示)遵循与图5所示的模式相类似的模式。在传统存储世界中，这样的动态行为是有意义的，因为物理介质被添加到设备或从中移除。在服务世界中，这暗示服务可由安装在客户机设备110上的新应用程序添力口。例如，如果第三方编写日历应用程序，则除已经展示的联系人服务外，该日历服务7102(图7)可以在该应用程序运行时展示。再次参考图7，状态服务7105向主机102(S卩，发起者)展示关于客户机设备110(8卩，响应者)的各种状态属性。在该说明性示例中，这些属性的值可包括在线/离线、电池寿命、信号强度、网络名、以及启用蓝牙。对状态属性进行更新的频率通常由被利用的特定客户机设备来选择，并且在设备属性已更新的情况下，服务属性已改变(ServicePropChanged)事件应被发送到发起者。在本发明的设备主存的服务的大多数应用中，更新频率将考虑相关客户机和主机PC性能能力并且将考虑例如便携式设备电池寿命来设计。设置服务710^展示客户机设备110(S卩，响应者)的要由主机102(即，发起者)远程操纵的各种设置。这些设置通常是客户机设备专用的，并且因此设置服务710^所展示的特定设置特征和功能将随设备变化并且是服务开发者(例如，设备制造商)的设计选择问题。提示服务710n向主机102提供信息来克服现有MTP实现对标识用于存储传统存储服务或特定服务内的特定对象类型的设备位置的限制。如图所示，启用服务信息720N来携带该服务的正确操作所必需的服务专用数据。诸如提示服务710n等某些服务可能需要简单地向主机102呈现信息的丰富的静态数据集，而非提供附加存储或功能能力。这些服务(称为信息服务215)提供关于特定设备的附加信息，这些信息不能以其他方式提供。在提示服务710n的情况下，示例性数据集通常将包含MTP格式码、存储ID、父对象ID来唯一地标识优选位置以供主机存储指定格式的对象。在构造设备主存的服务体系结构时，可以使用某些面向对象的范例来提供好处。最有用的范例之一是在特定服务内对从一个服务到另一个服务或从一个对象到另一个对象的服务行为继承进行建模的能力。如表2所示并如图10所示，“服务信息”数据集1002提供关于服务中的不同对象之间的分层结构关系的信息。在服务级，两个字段定义该服务的继承属性。第一字段BaseServicePUID(由附图标记1006所示)允许服务实现者通过指定该基本服务的服务PUID来指示服务的一个实例直接包含另一服务的行为。这一“包含”继承关系1008因而暗示，对于在基本服务1015上定义的所有格式和方法，在派生服务1021上定义的格式和方法表示包含该基本实现的扩展实现。即，在基本服务1015上创建基本服务1015所指定的特定格式的对象使得也在派生服务1021上创建派生类型的对象。在特定服务需要参与基本服务所指定的某预定义行为但缺少供更丰富的交互所有所需功能的情况下，该继承关系的使用是有好处的。第二字段UsesService⑶IDs(由附图标记1012所示)是用于定义当前服务的实现的零个或更多个服务类型GUID的阵列。在传统面向对象的编程范例中，这是“实现”关系。与“包含”关系一样，关于“使用”继承关系的所有信息(由附图标记1025所示)还可用作派生服务1021的定义的一部分。然而，在派生服务1021上创建对象不能也使得在使用服务(usesservice)上创建对象。使用继承关系对在面向服务范例中定义聚集行为特别有用。例如，它使设备能够为特定服务(使用服务)指定一个通用模式，并随后允许多个服务从使用服务继承而非必须在所有服务上复制相同的信息。特定设备上的仅用于提供用作UsesService⑶ID的联系人的设备主存的服务被称为抽象服务并且不指定存储ID，从而阻止持久存储对象或调用方法。除服务级继承之外，“服务信息”数据集的定义在数据对象和方法对象级定义了详细关系。在数据对象的情况下，对“包含”关系的支持一般需要派生服务1021中的数据对象能够指定基本服务1015中的它所包含的数据对象。使用FormatBaseID字段来为所定义的数据格式中的每一个定义这一关系。在方法对象的情况下，一般需要关联来定义与之相关联的数据对象。在某些情况下，方法对象可应用于整个服务。返回到联系人示例，可定义服务方法对象，这使得能够从诸如标准vCard(最初称为“Versitcard”)数据流等特定数据集创建联系人。在这种情况下，该方法与服务对象而非单独的数据对象相关联。另外，特定数据对象格式自身可以支持方法。例如，从vCard流中转换对象的服务方法所创建的联系人对象可具有用于将该联系人对象与在从该联系人接收到电话呼叫时播放的特定铃声相关联的方法。现在转向用于实现脚本或其他编程环境的脚本设备服务218(图2)，图11示出用于向发起者(例如，主机102)上的自动化客户机展示设备主存的服务的说明性安排1100。分别由附图标记1105和1112所示的这样的自动化客户机可被安排成主机应用程序146中的功能元件和/或被安排成在主机102上运行的某其他组件1122的一部分。这样的组件1122表示可例如由过程、方法、线程等提供的各种基于主机的功能中的任一种。在Windows实现中，提供IDispatch接口1126以向自动化客户机1105和1112展示客户机设备Iio上的设备主存的服务。COM组件102实现IDispatch1126以允许自动化客户机1105和1112访问，IDispatch1126可以例如通常使用C++或VisualBasic通过ActiveX或其他自动化服务器或编程工具来实现。然而，要强调的是，本发明对设备主存的服务的安排不限于WindowsAPI和编程模型，并且根据特定实现的要求，可以在非Windows设置中实现类似的已知自动化接口。例如，基于操作系统的特定需求，改编所提出的解决方案来用于诸如Java等不同的脚本环境中是可能的。本发明的脚本和编程模型中的最丰富的机会之一是向设备侧应用程序开发者展示用于创建新服务和处理相关联的服务请求的能力。例如，在移动电话环境中，第三方应用程序开发者将能够充分利用Java环境中的用于在该设备上创建和安装新服务的支持。在将设备连接到Windows或另一平台时，设备侧Java应用程序将能够对来自MTP主机的服务请求作出响应，从而使设备应用程序开发者能够使用同一应用程序的PC版本来创建更丰富的数据交换模型。尽管通常优选地利用脚本来实现自动化，但可以明白，通常也可在程序性或说明性上下文或其组合中使用本机码来提供类似功能。给定本文描述的设备主存的服务，可以定义一组计算机可执行方法，这些方法将使得连接到WindowsPC的客户机设备上存在的任何MTP设备主存的服务能够作为可脚本化IDispatch组件来展示。这通过充分利用在IDispatch世界和设备主存的服务世界之间绑定的两个基类来实现。在此被称为IWPDDispatchableService的第一个基类表示服务本身。其展示用于创建服务中所标识的类型中的每一种的对象以及提供对与该服务相关联的属性的直接访问的方法。该服务的实现基于现有WPD设备API并使用向该API提供的扩展以供设备主存的服务领会所使用的信息。除展示对服务对象和属性的访问之外，还可以展示绑定到服务本身的任何设备主存的服务方法。对象在类似接口之上构建，在此被称为IWPDDispatchableObject。除用于修改、删除、或提交对对象的改变的基本功能之外，这一类型的对象展示与该对象相关联的、设备上存在的服务所定义的属性和方法。在两种情况下，在设备上携带的作为Servicelnfo数据集的一部分的信息向所展示的不同属性和方法提供名称和意义。给定现有MTP协议提供关于格式(对象/方法)和属性两者的详细信息的能力，在提交给客户机设备之前在主机PC基础对象内执行合理的错误处理也是可能的。可以明白，IWPDDispatchableService和IWPDDispatchableObject两者也具有以可最小化到客户机设备的往返次数来从而提高性能的方式，根据诸如初始化新对象等常见场景来高速缓存属性和请求的能力。可以预计，作为可脚本化环境的一部分，设置服务710,单独地或结合状态服务7105可以用来在诊断和故障查找、设备设置和配置、新设备应用程序及功能的安装和管理时便于这些服务。例如，在寻求诊断并修复问题时，客户机设备用户可以将该设备连接到该用户的PC，并随后将该PC的web浏览器定向到设备制造商的网站。状态和设置服务分别展示设备状态和遥控功能，从而使得能够作为来自设备制造商的web主存的应用程序来执行更高效的故障查找和修复。当然，这一服务仅仅是说明性的，并且本领域技术人员将明白，可以使用本发明的设备主存的服务来实现特定应用程序所需的各种不同的web体验。直接从诸如网页等薄客户机环境访问任何设备上可用的丰富服务的能力可对该设备形成重大的安全威胁。例如，用户可能被社会性地引导去点击网页，这导致他们设备的内容被读取或擦除。因此，可以实现不同的安全方法来帮助阻止这样的不当使用。在一种情况下，在基于彼此共享的秘密建立了信任级之后，设备主存的服务本身可以定义用于获取并使用安全通信的模型。或者，对客户机设备的访问可被只限于已被批准访问该设备的那些网页，例如客户机设备制造商的站点(如在以上示例中所述)。另外，可以实现用于创建安全专用web环境的常规方法以使得所有网页能够被确认和授权，这将使希望支持该要求的任何人能够被授权访问客户机设备。一旦安全上下文就位，则假定该上下文中的所有授权参与者都具有连接到并使用特定设备主存的服务的能力随后就变得合理了。为支持这样的模型，展示用于发现该上下文中所支持的设备的数量和类型以及发现它们所提供的每一个服务的方法也变得有必要。在此定义的这些方法专用于创建用于访问该设备的web上下文。可以明白，存在着也可从能够访问特定客户机设备上的设备主存的服务获益的其他开发模型。为便于在这些模型内开发，可以明白，也可以向这些非脚本环境展示服务。允许进行这一绑定暗示目标环境的必要需求已被满足。尽管用结构特征和/或方法动作专用的语言描述了本主题，但可以理解，所附权利要求书中定义的主题不必限于上述具体特征或动作。相反，上述具体特征和动作是作为实现权利要求的示例形式公开的。权利要求一种用于从主机(102)访问主存在设备(110)上的服务(610)的方法，所述方法包括以下步骤与主存所述服务(610)的所述设备(110)通信，所述设备主存的服务(610)与一个或多个对象存储(620)相关联，并且还被安排成响应于通过所述主机(102)所支持的编程接口(1126)作出的命令来展示所述存储(620)中的对象(626、629)；通过所述编程接口(1126)将所述设备主存的服务(610)桥接到所述主机(102)；以及使用所述设备主存的服务(610)来访问所述对象(626、629)。2.如权利要求1所述的方法，其特征在于，所述服务是存储服务、功能设备服务、或信息服务中的一个。3.如权利要求2所述的方法，其特征在于，所述存储服务是从包括联系人服务、日历服务、SMS服务、铃声服务、壁纸服务、或数据存储服务的组中选择的。4.如权利要求2所述的方法，其特征在于，所述功能设备服务是从包括电话服务、设备设置服务、或设备状态服务的组中选择的。5.如权利要求1所述的方法，其特征在于，所述主机支持包括薄客户机或厚客户机中的一个所支持的web体验的面向服务的体系结构。6.如权利要求2所述的方法，其特征在于，存储服务或功能设备服务由第三方定义，所述第三方是不作为所述设备的制造商或主机的制造商的一方。7.如权利要求1所述的方法，其特征在于，与所述设备的通信通过MTP协议来执行。8.如权利要求1所述的方法，其特征在于，还包括响应于查询来接收所述设备主存的服务的描述的步骤。9.如权利要求8所述的方法，其特征在于，还包括允许通过所述编程接口创建在所述描述中标识的类型的对象的步骤。10.如权利要求9所述的方法，其特征在于，还包括通过所述编程接口展示与所述对象相关联的属性的步骤。11.如权利要求1所述的方法，其特征在于，还包括通过所述编程接口展示与所述对象相关联的方法的步骤。12.如权利要求1所述的方法，其特征在于，所述编程接口包括由Windows环境中的一个或多个COM组件实现的IDispatch。13.如权利要求1所述的方法，其特征在于，还包括将所述设备主存的服务绑定到脚本环境或编程环境以向来自外部主机的程序控件展示所述设备主存的服务的步骤。14.如权利要求1所述的方法，其特征在于，还包括向程序控件展示所述设备主存的服务的步骤，所述程序控件是使用脚本或编程环境来实现的。15.如权利要求14所述的方法，其特征在于，所述编程环境包括基于Windows的API及编程模型或Java编程模型。全文摘要提供了用于通过MTP(媒体传输协议)向主机应用程序或进程展示客户机设备上的自描述的设备主存的服务的安排，包括新MTP命令的MTP扩展通过该安排使得该设备主存的服务能够向后和向前兼容现有MTP实现。该扩展中的新MTP命令使得主机能够发现由连接客户机设备提供的设备主存的服务。在一说明性示例中，设备主存的服务包括存储服务、功能设备服务、以及信息服务。这些设备主存的服务有利地允许主机和客户机设备之间的更丰富的通信。还提供了一组方法来获取设备上存在的任何这样的设备主存的服务并通过利用可脚本化或其他编程环境将该功能展示给例如基于web的客户机应用程序以及其他薄客户机解决方案。文档编号G06F17/00GK101802808SQ200880108222公开日2010年8月11日申请日期2008年8月25日优先权日2007年9月20日发明者D·戴维斯,D·高尔,G·德巴克,M·莫里斯申请人:微软公司