The goal of WS-Discovery protocol is to enable a client to search for one or more target services. For this reason WS-Discovery is specified as multicast discovery protocol. As I already announced one of message enhancements in .NET 4.0 will be support for WS-Discovery protocol. Note that this post is not about .NET 4.0, but about WS-Discovery.
This protocol is very usefully when clients need to find services. The term service in this context can be a usual Web Service in SOA environment or even some hardware device. For example Windows Vista implements WS-Discovery to support the Device Profile for Web Services (DPWS). DPWS provides standards-based connectivity to network devices including printers, RFID readers, wireless cameras, projectors, and more. The DPWS lightweight protocol fits into small devices and enables a new wave of experiences with across-the-Internet connectivity between devices, PCs and Web services. Web Services on devices allows devices and PCs to connect to each other across the Internet, even as they roam and change IP addresses.
WS-Discovery specification assumes DISCOVERY_PORT 3702 [IANA], IPv4 multicast address: 126.96.36.199 and IPv6 multicast address: FF02::C (link-local scope).
Note that all messages are sent over SOAP/UDP protocol. Here are four different scenarios defined by WS-Discovery specification, which corresponds to the model shown below.
(a) When a target service joins the network, it sends an announcement message (1) to the same multicast group. By listening to this multicast group, clients can detect newly-available target services without repeated probing. This reduces network traffic, because clients doe not have to send pooling requests to find the target service.
(b) To find a target service by the type of the service or by scope in which the target service resides (or both), a client sends a probe message (2) to a multicast group. Service(s) which matches the probe sends the response called Probe Match (3) to the client directly.
(c)The client can also try to find the service by its name. In this case client should send the resolve message (4) to the multicast group. Response to this message is called resolve match (5).
(d) Additionally WS-Discovery specification defines multicast suppression behavior. This is when a proxy called discovery proxy is available on the network. When a discovery proxy detects a probe [resolution message - (b)] , the discovery proxy sends an announcement for itself. By listening for these announcements, clients detect discovery proxies and switch in multicast suppression behavior (use a discovery proxy-specific protocol). If a discovery proxy is unresponsive for some reason, clients revert from this mode.
(e) When the service lives the network it sends the Bye message (6).
Note that WS-Discovery protocol does not provide any information about liveness of the target service.
Here is one example which uses Probe request (2) and Probe Match response (3).
Following message is an example of querying for the printer-service. Note that this request does not contain ReplyTo-tag (see in this post for one example of WS-Addressing). Because of that the reply message will be an UDP-packet according to SOAP/UDP, which is also a part of .NET 4.0.
The game between Type and Scope in this example illustrate the usage of these two terms. The client is locking for service of type PrintBasic in the specific group defined by LDAP.
The Probe Match response message is sent as response to the Probe Message. First of all this message contains the instance identifier of the service which responses the message.
<d:AppSequence InstanceId="1077004800" MessageNumber="2" />
Discovery Proxy Model
Following picture shows the message sequence by using of the discovery proxy. As shown at this sequence discovery proxy responses n behalf of services. Proxy timeout according to specification is set on 5 seconds.
1. Part II: WCF and Service Discovery in .NET 4.0
2. Part III: NET 4.0 : Enabling WCF service for discovery
Oct 19 2008, 12:09 AM