The Cover PagesThe OASIS Cover Pages: The Online Resource for Markup Language Technologies
SEARCH | ABOUT | INDEX | NEWS | CORE STANDARDS | TECHNOLOGY REPORTS | EVENTS | LIBRARY
SEARCH
Advanced Search
ABOUT
Site Map
CP RSS Channel
Contact Us
Sponsoring CP
About Our Sponsors

NEWS
Cover Stories
Articles & Papers
Press Releases

CORE STANDARDS
XML
SGML
Schemas
XSL/XSLT/XPath
XLink
XML Query
CSS
SVG

TECHNOLOGY REPORTS
XML Applications
General Apps
Government Apps
Academic Apps

EVENTS
LIBRARY
Introductions
FAQs
Bibliography
Technology and Society
Semantics
Tech Topics
Software
Related Standards
Historic
Created: October 29, 2004.
News: Cover StoriesPrevious News ItemNext News Item

Microsoft Releases Revised Version of Web Services Dynamic Discovery (WS-Discovery).

Contents

Update 2005-04: In April 2005 Microsoft released a new version of Web Services Dynamic Discovery (WS-Discovery), edited by Jeffrey Schlimmer. With XML Schema and WSDL file. It supersedes the October 2004 version. See the Web Service Metadata index page and WS-Discovery reference page.

[October 29, 2004] Microsoft has published an updated version of the Web Services Dynamic Discovery (WS-Discovery) specification initially released in February 2004.

The revised version includes webMethods, Inc. as a named Co-Developer, joining BEA Systems, Canon, Intel, and Microsoft. The revised IPR declaration deviates from a recent trend under which the WS-* specifications are licensed Royalty-Free. The updated WS-Discovery specification states that the Co-Developers "each agree to grant you a license, under reasonable, non-discriminatory terms and conditions, to their respective essential Licensed Claims, which reasonable, non-discriminatory terms and conditions may include, for example, the payment of royalties and an affirmation of the obligation to grant reciprocal licenses under any of the licensee's patents that are necessary to implement the Specification."

WS-Discovery belongs to the WS-* suite of 'Composable Architecture' specifications which "relies on other Web service specifications to provide secure, reliable, and/or transacted message delivery and to express Web service and client policy."

The revised version of WS-Discovery incorporates changes based upon a WS-Discovery Feedback Workshop held in San Jose on May 19, 2004. Twenty-one attendees from twelve companies were at this Workshop where the authors "discussed various aspects of the spec, including an introduction and detailed drill-down into the spec, implementation experiences, and possible future areas for investigation." Attendees included representatives from BEA Systems Inc, Canon Inc, CommerceOne Inc, Epson Corporation, iDesign Inc, Intel Corporation, Iona Technologies, Lexmark International Inc, Microsoft Corporation, Ricoh Corporation, Roxio Inc, and webMethods Inc.

The WS-Discovery specification "defines a multicast discovery protocol to locate 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."

The term "discovery" is used by the WS-Discovery specification in reference to advertising and finding devices or services on a network. This is in contrast to "discovery" in the sense of accessing a directory (e.g., UDDI) or inspection of a device or service (e.g., WS-MetadataExchange). It offers a "flexible, scalable, extensible, and lightweight mechanism for service discovery based upon simple messaging (Hello, Bye, Probe, Probe Match, Resolve, Resolve Match)."

WS-Discovery has been designed to "allow discovery of services in ad hoc networks with a minimum of networking services, e.g., where no DNS or directory services are available. It should leverage network services to reduce network traffic in managed networks where such services exist. The goal is to enable smooth transitions between ad hoc and managed networks, and enable discovery of resource-limited service implementations. Further, it is intended: to support bootstrapping to other Web service protocols as well as other transports; to enable discovery of services by type and within scope; to leverage other Web service specifications for secure, reliable, transacted message delivery; to provide extensibility for more sophisticated and/or currently unanticipated scenarios. It supports both SOAP 1.1 and SOAP 1.2 envelopes."

A WS-Discovery Interop Workshop is scheduled to be held December 6-7, 2004 in Irvine, CA, hosted by Canon Inc. This workshop will "demonstrate and explore the interoperability issues related to the WS-Discovery specification. The event is for hands-on interoperability testing by developers implementing the specification."

Bibliographic Information

  • Web Services Dynamic Discovery (WS-Discovery). Edited by Jeffrey Schlimmer (Microsoft). October 2004. 39 pages. Copyright (c) 2004 Microsoft Corporation, Inc. [with co-developer companies] BEA Systems, Canon, Intel, and webMethods, Inc. Co-Developers: John Beatty (BEA Systems), Gopal Kakivaya (Microsoft), Devon Kemp (Canon), Thomas Kuehnel (Microsoft), Brad Lovering (Microsoft), Bryan Roe (Intel), Christopher St. John (webMethods), Jeffrey Schlimmer (Editor, Microsoft), Guillaume Simonnet (Microsoft), Doug Walter (Microsoft), Jack Weast (Intel), Yevgeniy Yarmosh (Intel), Prasad Yendluri (webMethods). With XML Schema (Appendix II) and WSDL (Appendix III).

    Acknowledgements. This specification has been developed as a result of joint work with many individuals and teams, including: Don Box (Microsoft), Shannon Chan (Microsoft), Ken Cooper (Microsoft), Mike Fenelon (Microsoft), Omri Gazitt (Microsoft), Bertus Greeff (Microsoft), Rob Hain (Microsoft), Richard Hasha (Microsoft), Erin Honeycutt (Microsoft), Christian Huitema (Microsoft), Chris Kaler (Microsoft), Umesh Madan (Microsoft), Vipul Modi (Microsoft), Jeff Parham (Microsoft), Yaniv Pessach (Microsoft), Stefan Pharies (Microsoft), Dale Sather (Microsoft), and Matt Tavis (Microsoft).

  • Previous Version 2004-02: 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).

Summary of Changes from Jeffrey Schlimmer's Blog

"BEA, Canon, Intel, and Microsoft are delighted to welcome webMethods as a co-author on an updated version of WS-Discovery.

The biggest technical change is to define a baseline protocol for a Discovery Proxy (DP). While a rich DP-specific protocol is intentionally unspecified, feedback from the workshop indicated the community wants a fallback protocol, so:

  • A DP now responds to at least (unicast) Probe and Resolve (and probably other, richer DP protocols), and
  • Probe Match has been extended to allow > 1 match for Discovery Proxy, and
  • Resolve has been changed to carry the Target Service Endpoint Reference in the SOAP Body so Resolve can be sent to either the discovery endpoint (multicast) or the DP (unicast)

Other workshop feedback addressed includes:

  • Clarified phrase 'managed network' in Introduction
  • Cleaned up usage of address terms, i.e., Endpoint Reference, transport address, and IP address
  • Explained usage of a:EndpointReference/a:Address="uuid:..."
  • Added diagram to explain relationship between Probe and Resolve
  • Clarified omitted a:ReplyTo in Probe and Resolve
  • Explained that Clients talk to DP using transport address in DP Hello Revised Security Considerations..."

[See the complete text of the blog for additional description of changes: "WS-Discovery Updates," Jeffrey Schlimmer's Blog. Thursday, October 28, 2004.]

WS-Discovery in a Nutshell by Intel

"The Web Services Dynamic Discovery Specification, a/k/a WS-Discovery describes a way for a Web service to easily find and connect with other Web services over a network automatically. The publication of the specification is an effort to expand the existing Web services architecture to computing and peripheral devices that are not typically reachable through Web services, such as computer peripherals, computing appliances, and consumer electronics..."

Complementary with UDDI, WS-Discovery builds on the core Web services architecture of secure, reliable and transacted Web services to provide a specification that is flexible enough to be applied to scenarios that span the enterprise, the home and devices. This specification defines a way to locate services on a network with a minimum of networking services (e.g., no DNS or UDDI directory services). When coming online, the service will simply ask the network, via WS-Discovery, 'what services are available to me?' and the services enabled with WS-Discovery will answer with a list of available services and a connection can be established. Where such services like DNS and UDDI exists WS-Discovery will transition to using those richer network services to reduce network traffic..." [from "New Web Services Specification, WS-Discovery," based upon the 2004-02 spec version]

Discovery in the Web Services Architecture

"[Certain] functional components of the Web services architecture that used to locate Web services on a network and to determine the service's availability: UDDI and WS-Discovery.

Web service discovery is a key enabler for automating connections to services without human intervention. The Web service approach to discovery mirrors the two most common approaches to finding information in a computer system: looking in a well-known location, or broadcasting a request to all available listeners. The UDDI registries serve as the directory, and discovery protocols are used to broadcast requests...

UDDI specifies a protocol for querying and updating a common directory of Web service information. The directory includes information about service providers, the services they host, and the protocols those services implement. The directory also provides mechanisms to add metadata to any registered information. The UDDI directory approach can be used when Web service information is stored in well-known locations. Once the directory is located, a series of query requests can be sent to obtain the desired information. UDDI directory locations are obtained out of band, usually through system configuration data...

Dynamic Web service discovery is provided in a different manner. As an alternative to storing information in a known registry, dynamically discovered Web services explicitly announce their arrival and departure from the network. WS-Discovery defines protocols to announce and discover Web services through multicast messages.

When a Web service connects to a network, it announces its arrival by sending a Hello message. In the simplest case, these announcements are sent across the network using multicast protocols — we call this an ad-hoc network. This approach also minimizes the need for polling on the network. In order to limit the amount of network traffic and optimize the discovery process, a system may include a Discovery Proxy. A Discovery Proxy replaces the need to send multicast messages with a well-known service location, transforming an ad-hoc network into a managed network. Using configuration information, collections of proxy services may be linked together to scale the discovery service to groups of servers, scaling from one machine to many.

Since the Discovery Proxies are themselves Web services, they may announce their presence with their own special Hello message. Web services receiving this message may then take advantage of the proxy's services, and are no longer required to use the noisier one-to-many discovery protocols.

When a service departs from a network, WS-Discovery specifies a Bye message to be sent to either the network or the Discovery Proxy. This message informs the other services on the network that the departing Web service is no longer available.

To complement this basic approach to service announcement and departure, WS-Discovery defines two operations, Probe and Resolve to locate Web services on a network. For ad-hoc networks, Probe messages are sent to a multicast group, and target services that match the request return a response directly to the requestor. For managed networks utilizing a Discovery Proxy, Probe messages are unicast to the Discovery Proxy instead. The Resolve message is used when a Web service is to be located by name. The Resolve message is only sent in multicast mode. Resolve is analogous to the Address Resolution Protocol, or ARP [ARP], that converts an IP address to its corresponding physical network address.

The WS-Discovery specification also allows system configurations where the Probe message is sent to a Discovery Proxy that has been established by some other administrative means, such as by using a well-known DHCP record.

The ability to find services dynamically enables Web service management bootstrapping. In conjunction with WS-Eventing [WS-Eventing] and other protocols, more sophisticated management services can be built using this dynamic discovery infrastructure.

Dynamic discovery also extends the Web services architecture to devices, such as those that might implement the Universal Plug & Play (UPnP) protocols today. This is an important step in making the architecture truly universal. With WS-Discovery and WS-Eventing, devices such as printers or storage media, for example, may be incorporated into a system as Web services without the need for specialized tools or protocols..." [from "Discovery" in An Introduction to the Web Services Architecture and Its Specifications]

Introduction to WS-Discovery

The Web Services Dynamic Discovery (WS-Discovery) 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.

To support networks with explicit network management services like DHCP, DNS, domain controllers, directories, etc., 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..." [from the 2004-10 WS-Discovery specification Introduction]

Principal References


Hosted By
OASIS - Organization for the Advancement of Structured Information Standards

Sponsored By

IBM Corporation
ISIS Papyrus
Microsoft Corporation
Oracle Corporation

Primeton

XML Daily Newslink
Receive daily news updates from Managing Editor, Robin Cover.

 Newsletter Subscription
 Newsletter Archives
Bottom Globe Image

Document URI: http://xml.coverpages.org/ni2004-10-29-a.html  —  Legal stuff
Robin Cover, Editor: robin@oasis-open.org