What are Device Services?

"Device Services" is a brand new concept introduced in Windows 7 that provides a framework for device manufacturers to extend device functionality, and new APIs for applications to discover and access that extended functionality using WPD. We decided to call these extensions to device functionality "Device Services" because they foster rich interaction between the PC and devices by providing a model for devices to formalize extension capabilities and make these capabilities accessible to applications.

Device Services are available in Windows 7 and Windows Vista with the Platform Update for Windows Vista.

Why do we need Device Services?

First, a quick historical perspective. Media Transfer Protocol (MTP - one of the protocols supported within WPD) was introduced beginning with Windows Media Player 10 as an extension of the Picture Transfer Protocol (PTP). MTP became a USB standard, and was widely adopted by a myriad of device classes: media players, mobile phones, cameras, Xbox 360s, etc.  True to its PTP origins, MTP 1.0 was very media-centric; the scenarios it excelled in revolved around browsing device content and exchanging media files (images, music, and video, etc) between device and the PC.

Enabling PIM Scenarios

With Windows 7, we shifted our focus to enabling more device-to-PC scenarios centered around managing and accessing Personal Information Management (PIM) data (contacts, tasks, calendar, etc.) on the device. These involved more complex operations such as SMS, email and advanced synchronization with Outlook™. Non-media files present additional challenges in accessing and enumerating them efficiently on the device. Unlike an MP3 or a JPEG file, a contact or task may not be represented by a physical file on the device storage.  Depending on device implementation, these objects could be stashed anywhere: in databases, in SIM cards, etc.

Honey, where did you put my contacts (and music, and photos, and ...)?

Another common problem is that there was no standardized method for a device to figure out where to put its content.  Most applications would have to guess at a location, choose or specify an application-specific location, or crawl the entire device, often just to locate a subset of content. [Aside: In Vista, WPD does support the concept of "Device Hints", where devices/drivers provision a list of known folders that would accept particular content types. Unfortunately, this was not uniformly adopted by devices/drivers, and was limited to known WPD content types].

Crowded MTP 1.0 Extension Space

Last but not the least, MTP 1.0 had inherent limitations for growth and new functionality. The operation codes and property codes were constrained by a DWORD (4 byte) numerical space, with only a small subset allocated for extension codes. Without a notion of vendor-specific namespaces, new extensions must be careful not to collide with existing extensions. This would usually add the overhead of having to publish the codes or risk incompatibilities with applications that rely on existing extensions.  And, if the device/application needs to support new types of content, adding a new object format involves updating the MTP Specification, which is not easily revised.

How do Device Services help?

To solve the problems and overcome the limitations described above, we introduced the concept of Device Services to MTP. In a nutshell, "MTP Device Services" is an MTP Extension that defines a set of MTP operations revolving around a new type of object known as a "service."

A service is composed of 3 parts:

1. The core definition of that service and what it does, including its globally unique identifier (GUID).
2. The properties of the service itself, and
3. The properties and capabilities of objects and methods of that service.

Properties are represented by PROPERTYKEYS, and formats are represented by GUIDs, which eliminate the operation and format number space restrictions. Together, these provide the structure that applications would rely on to programmatically discover and use services in a consistent way. 

The following describes the most common ways in which Device Services are used today:

1. Provide a set of properties and events associated with a common scenario. One example is the Status Service, which defines properties for the battery level, the number of missed calls, the number of new voicemail messages, and the number of new pictures acquired by a device. These may be custom properties, and any application that discovers this service can programmatically discover these properties.
   
   
2. Provide a known source and/or sink for content. The Contacts, Calendar, Task, and Notes services are all services that allow applications to access and store PIM data. These are analogous to "virtual storages."  The device represents the content in a standard location (as child objects of these services) so that applications do not have to grovel through the device hierarchy to find them. At the same time, this abstraction allows a device implementation greater control over how objects are actually stored on the device. Services are not limited to the known MTP or WPD formats, and may support any arbitrary type of data. For example, devices that wish to provide a Device Stage™ experience upon install can implement a Device Metadata Service that stores *.devicemetadata-ms files.
   
   
3. Provide a set of functionality associated with a common scenario.  The Full Enumeration and Anchor Synchronization services support "methods."  Methods are like extensions to WPD commands, with the added benefits of being easily discoverable and supporting both synchronous and asynchronous invocation. The Anchor Synchronization Service features a method that allows a synchronization application to retrieve the set of changes to content on the device from a given anchor value (which can be a timestamp or a tick count). Methods also provide a flexible way to access content residing on multiple services. For instance, the Ringtones Service contains a method that allows an application to associate a ringtone (an object within the Ringtones Service) with a contact (an object within the Contacts Service).

How are Device Services used in Windows 7?

After creating Device Services, we put it through its paces in real-life scenarios that are part of Windows 7.

Device Stage™- Uses the Status service to display status on the Branding bar, and on the Taskbar and preview pane.

Windows 7 Synchronization – The Portable Devices Sync Provider uses the Contact Service, Calendar Service, Task Service, and Notes Service to access PIM data on the device. In addition, the Enumeration Synchronization Service and Anchor Synchronization Service are used to determine the level of synchronization capabilities that a device supports.

Windows Media Player and Windows Explorer – Both these applications use WPD Device Hints to determine content locations more efficiently.  For MTP devices, WPD Device Hints is now implemented at the MTP layer as a Hints Service. Devices that implement the Hints Service get WPD Device Hints for free.

Ringtone Editor – Uses the Ringtones Service to transfer user-created ringtones to the device, and to associate a ringtone with a contact that is located using the Contacts service.

WPD Class Installer – Uses the Device Metadata Service to retrieve and transfer metadata stored on the device, so that the richer, device-manufacturer-customized, Device Stage experience gets presented to the user after the first time the device is connected and installed.

More Information

We hope this post has given you a taste of what Device Services can do. Here are some additional links for further information.

Device Services:

Media Transfer Protocol: http://www.usb.org/developers/devclass_docs/MTP_1.0.zip

MTP Device Services Extension Specification: http://www.microsoft.com/whdc/device/wpd/MTPDevServExt_Spec.mspx

Windows Portable Device Enabling Kit for MTP: http://www.microsoft.com/whdc/device/wpd/MTP-DEK_Win7.mspx

Application Development:

Using the WPD API for Device Services: http://msdn.microsoft.com/en-us/library/dd319325(VS.85).aspx

The WPD Services API Sample: (available from the Windows 7 SDK): http://msdn.microsoft.com/en-us/library/dd389002(VS.85).aspx

The WPD Automation Object Model: http://msdn.microsoft.com/en-us/library/dd389295(VS.85).aspx

Driver Development:

The WPD Services Sample Driver (available from the Windows Driver Kit): http://msdn.microsoft.com/en-us/library/dd573849.aspx

This posting is provided "AS IS" with no warranties and confers no rights.