A Technical Introduction to the Devices Profile for Web Services

  • Article

 

Jeffrey Schlimmer
Microsoft Corporation

May 2004

Introduction

The Web services architecture includes a rich suite of specifications that provide complementary functions in the areas of security, reliability, and transaction-based messaging. By design, these specifications may be used together to meet varied service requirements.

The Devices Profile for Web Services (Devices Profile) pulls together a core subset of these specifications into an overall whole. The Devices Profile is a detailed specification intended for those who are implementing networking libraries or platform components. It is written as a set of numbered normative statements together with rationale and examples.

The Devices Profile focuses on IP-capable devices which are growing in computational power. Though many of these are still resource-constrained by desktop and server standards, these devices are ready to contribute to general, Web services scenarios involving services already being deployed in the home, small office, enterprise, and Internet. To enable a base level of interoperability between devices and Web services, the Devices Profile calls out best-of-breed Web service specifications in core areas and prescribes how to use them in concert to enable the following networking functions:

  • Send secure messages to and from a Web service
  • Dynamically discover a Web service
  • Describe a Web service
  • Subscribe to, and receive events from, a Web service

However, the Devices Profile does not define specific application messages; these are left to vendors and their standards organizations in specific domain areas.

Example

Using the Devices Profile, here is a typical message exchange between a client that has something to print, a printer device, and a print service hosted by the device.

Discovery

Message 1: To find a printer, the client sends a Probe message over UDP multicast. The Probe indicates the client is looking for a print service, and the Probe indicates whether the client requires security. The Probe message is defined in WS-Discovery as part of a multicast discovery protocol to locate services; to scale to a large number of endpoints, WS-Discovery defines multicast suppression behavior if a discovery proxy is available on the network.

Message 2: The device listens for Probe messages; in this case, it hosts a print service, so it responds with a Probe Match message (defined in WS-Discovery) directly to the client. The Probe Match includes three pieces of information:

  • A SOAP-level address for the device which is an Endpoint Reference. The Endpoint Reference is defined in WS-Addressing that defines transport-neutral mechanisms for end-to-end addressing of Web services and messages.
  • Transports where the device may be reached. All devices must expose SOAP over HTTP but may support other transports too.
  • Security requirements and capabilities of the device.

In simple, ad hoc deployments, devices respond directly to multicast requests from clients. In managed deployments, a discovery proxy (WS-Discovery) informs clients to refrain from sending multicast requests and instead communicate directly with the discovery proxy to find appropriate services.

These discovery messages are the first step in client and device association that is used in systems like Plug and Play.

Security

If the client requires security, the next message in the sequence sets up a secure channel between the client and device. This channel protects the confidentiality and integrity of all subsequent messages between the client and device (or services hosted by the device). The basis for device authentication is a device certificate. In simple, ad hoc deployments, a device may have a self-signed certificate; this requires the user to enter a device-specific PIN into the client. In managed deployments, a device may have a certificate with a root that is trusted by the client.

The Devices Profile defines an initial, simple security profile that may be extended to provide greater and/or more flexible protection and authentication.

Description

Message 3: To find out more about the device and services it hosts, a client may send a Get Metadata message directly to the device. The Get Metadata message is defined in the upcoming WS-MetadataTransfer specification to retrieve arbitrary types of metadata associated with a service.

Message 4: The device responds with its metadata, either in-line within the response message, or by including a pointer to the metadata. Besides information like the manufacturer of the device, its serial number, and firmware version, the metadata also includes the endpoint reference for each of the services hosted by the device.

Message 5: To find out more about the print service itself, a client may send a Get Metadata message directly to the service.

Message 6: The service responds with its metadata which contains the WSDL for the operations supported by the service and printer-specific metadata (such as ability to print in color, PPM, number and size of paper trays, etc).

Strictly speaking, Messages 3 through 6 could be optional. When the Devices Profile is applied to specific vertical domains, standards organizations within those domains could mandate standard services to be hosted, standard capabilities for those services, and even standard names for those services. While this implies less flexibility, it would allow a client that wished to use only the standard functionality the option of not retrieving the device and/or service metadata.

Control

Messages 7 and 8: The client sends a message to start a print job, and the print service responds. The Devices Profile does not define such application messages; they may be defined by individual vendors or by standards organizations working in specific domains.

Eventing

Message 9: To receive updates on the status of the print job, or to receive information about the overall status of the print service, the client may send a Subscribe message to the print service. The Subscribe message is defined in WS-Eventing along with messages to renew and cancel a subscription.

Message 10: The Subscribe response message (defined in WS-Eventing) includes an identifier for the subscription and when it will expire. If the client wants status after this expiration, it must renew the subscription.

Attachments

Messages 11 and 12: The client sends the print job itself to the print service, encoding large images as attachments to the message. The response from the print service indicates that the job has been accepted. Attachments are defined in MTOM as an optimization for transmitting a SOAP message by selectively re-encoding portions of the message while still presenting an XML Infoset to the SOAP application.

Eventing

Message 13: The print service sends an event to the client, informing it of, for instance, a change in the print job, for instance, number of pages printed, paper jam, job completed, etc. The format of application events is neither defined nor constrained by the Devices Profile; specific domains are free to define general messages as events.

Summary

As this brief overview illustrates, the Devices Profile provides functionality through the Web service specifications it calls out.

  • In the area of messaging, SOAP provides a model that allows declaratively identifying message processing requirements, WS-Addressing defines transport-independent service addresses, and MTOM allows efficiently including binary data in a message without compromising the SOAP processing model.
  • In the area of discovery, WS-Discovery allows finding a service by its type or by a scope it has been deployed into, and in managed networks, allows suppression of multicast traffic to improve scalability.
  • In the area of security, WSS SOAP Message Security is used to protect the integrity of discovery messages, and TLS protects the confidentiality and integrity of other messages.
  • In the area of description, WS-MetadataTransfer provides an extensible mechanism to retrieve service metadata, including message descriptions (WSDL), capabilities and requirements (WS-Policy), inter-service relationships and domain-specific metadata.
  • In the area of eventing, WS-Eventing allows application domains to define their own event models, provides a lease model for subscriptions, and allows either the service or the client to cancel an unneeded subscription.

Relying on Web service specifications, the Device Profile allows devices to participate in the Service Oriented Architecture (SOA) fabric. Sharing a common protocol framework allows devices to contribute to Web service scenarios that are traditionally beyond the reach of individual devices. Moreover, this commonality allows ISVs to leverage development tooling when writing applications for devices, and it allows IT departments to leverage service management infrastructure.

By leveraging factored Web service specifications built on a common foundation of SOAP and XML, device implementations can support rich functionality in a pay-as-you-go manner.

The Devices Profile is a new foundation for application protocols. It frees vendors and their standards organizations to concentrate on designing messages for specific device classes. The well-factored architecture and significant extensibility of the Device Profile enables as-yet-unforeseen messaging patterns, transports, metadata, and capabilities and requirements.

To ensure that the Devices Profile meets overall needs and is sufficiently precise, the authors are broadening the ongoing discussion with the community of device vendors. Most feedback will result in refinements within the Devices Profile itself, but some of the feedback will flow back into the core specifications themselves, incrementally improving the overall Web services architecture.

(c) 2004 Microsoft Corporation. All rights reserved.