Update 2004-10-29: Microsoft Releases Revised Version of Web Services Dynamic Discovery (WS-Discovery). Microsoft has updated the WS-* composable architecture "Web Services Dynamic Discovery (WS-Discovery)" specification first released in February 2004. WS-Discovery defines protocols to announce and dynamically discover Web services through multicast messages. Probes are sent to a multicast group; target services that match return responses directly to the requester. WS-Discovery may be licensed on RAND terms from BEA, Canon, Intel, Microsoft, and webMethods.

[February 17, 2004] Microsoft, BEA, Canon, and Intel have jointly authored a Web Services Dynamic Discovery (WS-Discovery) specification which defines a multicast discovery protocol to locate services. WS-Discovery "enables advertisement and dynamic discovery of services on both ad-hoc and managed networks. Services may be organized in a hierarchical scope, and clients can query for services by type as well as scope without heavy administrative costs. The specification enables numerous design patterns for enterprise services and provides a discovery architecture for peer-to-peer services like buddy lists, websites, and file shares; it forms the basis for discovering network-attached devices such as printers, cameras, and PDAs."

The prose specification is accompanied by an XML Schema and WSDL file, using the XML namespace http://schemas.xmlsoap.org/ws/2004/02/discovery. WS-Discovery is part of the WS-* suite of "composable architecture" Web service specifications published by Microsoft, IBM, and others; it therefore "specifically relies on other Web service specifications to provide secure, reliable, and/or transacted message delivery and to express Web service and client policy." Microsoft MSDN reckons WS-Discovery among the Web Services Metadata Specifications, together with WSDL, UDDI, WS-Policy, WS-PolicyAssertions, WS-PolicyAttachment, and WS-SecurityPolicy.

The WS-Discovery Protocol Assignments require that multicast messages use port 3702 (UDP or TCP, typically for UPNP v2 Discovery) using designated IPv4/IPv6 multicast addresses. Messages sent over UDP must be sent using SOAP over UDP, compensating for possible UDP unreliability by use of a modified transmission algorithm documented in Appendix A of 'SOAP over UDP'.

WS-Discovery is not intended to support "Internet-scale discovery, to provide liveness information on services, to define a data model for service description, or to define rich queries over that description. It is meant to support "discovery of services in ad hoc networks with a minimum of networking services (e.g., no DNS or directory services), and to enable smooth transitions between ad hoc and managed networks. The multicast-based protocol defined in WS-Discovery enables clients on a network to automatically find Web services. "By default, probes are sent to a multicast group, and target services that match return a response directly to the requester. To scale to a large number of endpoints, the protocol defines the multicast suppression behavior if a discovery proxy is available on the network. To minimize the need for polling, target services that wish to be discovered send an announcement when they join and leave the network."

Bibliographic Information

Web Services Dynamic Discovery (WS-Discovery). Developed by: John Beatty (BEA Systems), Gopal Kakivaya (Microsoft), Devon Kemp (Canon), Brad Lovering (Microsoft), Bryan Roe (Intel), Jeffrey Schlimmer (Editor, Microsoft), Guillaume Simonnet (Microsoft), and Jack Weast (Intel). Copyright (c) 2004 Microsoft Corporation, Inc. The Web Services Dynamic Discovery Specification (WS-Discovery) was developed by Microsoft, with the assistance of BEA Systems, Canon Inc, and Intel. February 2004. 35 pages. With XML Schema and WSDL. XML Namespace: http://schemas.xmlsoap.org/ws/2004/02/discovery.

Acknowledgements for participation in joint work: Don Box (Microsoft), Mike Fenelon (Microsoft), Omri Gazitt (Microsoft), Richard Hasha (Microsoft), Erin Honeycutt (Microsoft), Christian Huitema (Microsoft), Chris Kaler (Microsoft), Thomas Kuehnel (Microsoft), Umesh Madan (Microsoft), Vipul Modi (Microsoft), Jeff Parham (Microsoft), Yaniv Pessach (Microsoft), Stefan Pharies (Microsoft), Dale Sather (Microsoft), Matt Tavis (Microsoft), and Eugene Yarmosh (Intel).

WS-Discovery Specification Summary

Goals: According to the published Requirements, the Web Services Dynamic Discovery (WS-Discovery) specification was designed to:

• Allow discovery of services in ad hoc networks with a minimum of networking services -- e.g., no DNS or directory services
• Leverage network services to reduce network traffic in managed networks where such services exist
• Enable smooth transitions between ad hoc and managed networks
• Enable discovery of resource-limited service implementations
• Support bootstrapping to other Web service protocols as well as other transports
• Enable discovery of services by type and within scope
• Leverage other Web service specifications for secure, reliable, transacted message delivery
• Provide extensibility for more sophisticated and/or currently unanticipated scenarios
• Support both SOAP 1.1 and SOAP 1.2 Envelopes

Overview

This specification defines a multicast discovery protocol to locate services. The primary mode of discovery is a client searching for one or more target services. To find a target service by the type of the target service, a scope in which the target service resides, or both, a client sends a probe message to a multicast group; target services that match the probe send a response directly to the client. To locate a target service by name, a client sends a resolution request message to the same multicast group, and again, the target service that matches sends a response directly to the client.

To minimize the need for polling, when a target service joins the network, it sends an announcement message to the same multicast group. By listening to this multicast group, clients can detect newly-available target services without repeated probing.

To scale to a large number of endpoints, this specification defines multicast suppression behavior if a discovery proxy is available on the network. Specifically, when a discovery proxy detects a probe or resolution request sent by multicast, the discovery proxy sends an announcement for itself. By listening for these announcements, clients detect discovery proxies and switch to use a discovery proxy-specific protocol. However, if a discovery proxy is unresponsive, clients revert to use the protocol described herein. While the definition of a discovery proxy-specific protocol is beyond the scope of this specification, it is expected that any such protocol would define search messages clients send directly to the discovery proxy rather than to a multicast group.

To support managed networks, this specification acknowledges that clients and/or target services may be configured to behave differently than defined herein. For example, another specification may define a well-known DHCP record containing the address of a discovery proxy, and compliance with that specification may require endpoints to send messages to this discovery proxy rather than to a multicast group. While the specific means of such configuration is beyond the scope of this specification, it is expected that any such configuration would allow clients and/or target services to migrate smoothly between carefully-managed and ad hoc networks.

Security Model: This specification does not require that endpoints and the discovery process be secure. However, this specification RECOMMENDS that security be used to mitigate many types of attacks. The security model for discovery builds on the model described in WSS-SOAP Message Security, WS-Trust, and WS-Federation. Section 7 outlines how these specifications are used to secure the discovery process.

From the Intel Announcement

Delivering a valued experience for the digital home that keeps consumers connected everywhere they go will depend on the ability to create a unified platform and a surrounding ecosystem of support, in addition to specific new consumer-focused technologies, according to Louis Burns, Intel vice president and general manager of the Desktop Platforms Group. Speaking today at the Intel Developer Forum, Burns said the computing, consumer electronics and communications industries are merging to become one and that this new converged industry must deliver unified solutions focused around three consumer imperatives.

To enable the availability of the premium content for the digital home, Intel and Movielink today announced they have signed a co-marketing and technology collaboration agreement designed to accelerate the deployment of premium online movie content to multiple devices in the home as well as mobile PCs.

To bring the device and Web services worlds together, Burns announced that BEA Systems, Canon Inc., Intel and Microsoft Corporation have published a new Web services specification called WS-Discovery. With WS-Discovery, the companies are taking an important step toward enabling a rich and diverse set of devices to become fully integrated with Web services. Burns said WS-Discovery will operate whenever a device is connected to a network, leaves a network or is looking to see what else is on a network.

InfoWorld Tech Watch Commentary

InfoWorld's Paul Krill posted the following (excerpted) to InfoWorld Tech Watch on February 20, 2004, under the title "Because they can...":

"Microsoft this week proposed another Web services specification for industry adoption, WS-Discovery, and Sun Microsystems again accused Microsoft of trying to ram its own proposals down everyone's throat. Yes, Microsoft can seem a bit overbearing by putting out specifications for the industry without first going to an industry standards body. So why does Microsoft engage in this surly behavior? The answer is similar to why the New York Yankees buy up whatever players the team wants: Because they can...

Previously, Sun has accused Microsoft of trying to impose Web services specifications such as BPEL4WS (Business Process Execution Language for Web Services) on the industry. That proposal from Microsoft, IBM and BEA gathered steam while a similar Sun plan, Web Services Choreography Interface (WSCI), withered. Like it or not for Sun, Microsoft has the mass to lead in areas where it wants to, such as Web services. Microsoft says it does plan to eventually bring WS-Discovery to an industry standards group for its consideration..."

About UPnP Discovery

The WS-Discovery specification requires that multicast messages use fixed addresses (IPv4 multicast address '239.255.255.250', IPv6 multicast address 'FF02::C', link-local scope) using port 3702. From Section 2.4 Protocol Assignments: "Multicast messages described herein MUST be sent using the following assignments: PORT: 3702 (see Port Numbers [IANA])..." Registered Port 3702 (3702/tcp and 3702/udp, keyword 'upnp-discovery') is described as designated for UPNP v2 Discovery, according to the IANA registration by Christian Huitema (Microsoft) in February 2003.

The UPnP Forum is "an industry initiative designed to enable simple and robust connectivity among stand-alone devices and PCs from many different vendors. As of 2004-02, the Forum consists of more than 656 vendors, including industry leaders in consumer electronics, computing, home automation, home security, appliances, printing, photography, computer networking, and mobile products." Principal support for UpNP comes from Microsoft. See UPnP general references in the news story "UPnP Forum Releases New Security Specifications for Industry Review."

Summary: "The UPnP discovery protocol allows a device to announce to the control points that it has become available on the network. On joining the network, the device multicasts SSDP NOTIFY messages to advertise its embedded devices and services to all the control points on the network. When a new control point becomes available on the network, it multicasts a SSDP M_SEARCH discovery message through an HTTPMU request to search for available devices and services. The search message can contain qualifications on the type of device or service that the control point is searching for. All devices on the network must respond to the control point if their devices or services match the search criteria in the discovery message. The response that is transmitted to the control point by one or more matching devices contains a URL to the device description. The response message is sent to the control point using the User Datagram Protocol (UDP) with Simple Service Discovery Protocol (SSDP) headers..." (from UPnP Framework)

"The UPnP discovery protocol allows a device to announce to the control points that it has become available on the network. On joining the network, the device multicasts SSDP NOTIFY messages to advertise its embedded devices and services to all the control points on the network. When a new control point becomes available on the network, it multicasts a SSDP M_SEARCH discovery message through an HTTPMU request to search for available devices and services. The search message can contain qualifications on the type of device or service that the control point is searching for. All devices on the network must respond to the control point if their devices or services match the search criteria in the discovery message. The response that is transmitted to the control point by one or more matching devices contains a URL to the device description. The response message is sent to the control point using the User Datagram Protocol (UDP) with Simple Service Discovery Protocol (SSDP) headers..." (from UPnP Discovery)