Messaging enhancements in .NET 4.0: (Discovery Part I)

Damir Dobric Posts

Next talks:

 

    

Follow me on Twitter: #ddobric



 

 

Archives

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: 239.255.255.250 and IPv6 multicast address: FF02::C (link-local scope).

Discovery Model

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.

 

image 

Here is one example which uses Probe request (2) and Probe Match response (3).

Probe Message

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.

<s:Envelope
xmlns:a="http://schemas.xmlsoap.org/ws/2004/08/addressing"
xmlns:d="http://schemas.xmlsoap.org/ws/2005/04/discovery"
xmlns:i="http://printer.example.org/2003/imaging"
xmlns:s="http://www.w3.org/2003/05/soap-envelope" >
<s:Header>
    <a:Action>http://schemas.xmlsoap.org/ws/2005/04/discovery/Probe</a:Action>
    <a:MessageID>uuid:0a6dc791-2be6-4991-9af1-454778a1917a</a:MessageID>
    <a:To>urn:schemas-xmlsoap-org:ws:2005:04:discovery</a:To>
  </s:Header>
  <s:Body>
    <d:Probe>
      <d:Types>i:PrintBasic</d:Types>
      <d:Scopes MatchBy="http://schemas.xmlsoap.org/ws/2005/04/discovery/ldap">        
       ldap:///ou=engineering,o=examplecom,c=us</d:Scopes>
    </d:Probe>
  </s:Body>
</s:Envelope>

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.

Probe Match

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.

<s:Envelope
xmlns:a="http://schemas.xmlsoap.org/ws/2004/08/addressing"
xmlns:d="http://schemas.xmlsoap.org/ws/2005/04/discovery"
xmlns:i="http://printer.example.org/2003/imaging"
xmlns:s="http://www.w3.org/2003/05/soap-envelope" >
<s:Header>
<a:Action>http://schemas.xmlsoap.org/ws/2005/04/discovery/ProbeMatches</a:Action>
 <a:MessageID>uuid:e32e6863-ea5e-4ee4-997e-69539d1ff2cc</a:MessageID>
  <a:RelatesTo>uuid:0a6dc791-2be6-4991-9af1-454778a1917a</a:RelatesTo>
 
<a:To>http://schemas.xmlsoap.org/ws/2004/08/addressing/role/anonymous</a:To>
    <d:AppSequence InstanceId="1077004800" MessageNumber="2" />
  </s:Header>
  <s:Body>
    <d:ProbeMatches>
    <d:ProbeMatch>
      <a:EndpointReference>
        <a:Address>uuid:98190dc2-0890-4ef8-ac9a-5940995e6119</a:Address>
        </a:EndpointReference>
          <d:Types>i:PrintBasic i:PrintAdvanced</d:Types>
      <s:Body>
        <d:ProbeMatches>
          <d:ProbeMatch>
            <a:EndpointReference>
            <a:Address>uuid:98190dc2-0890-4ef8-ac9a-5940995e6119
              </a:Address>
            </a:EndpointReference>
            <d:Types>i:PrintBasic i:PrintAdvanced</d:Types>
            <d:Scopes>
              ldap:///ou=engineering,o=examplecom,c=us
              ldap:///ou=floor1,ou=b42,ou=anytown,o=examplecom,c=us
 
             http://itdept/imaging/deployment/2004-12-04 
           </d:Scopes>
             <d:XAddrs>http://prn-example/PRN42/b42-1668-a</d:XAddrs>
             <d:MetadataVersion>75965</d:MetadataVersion>
          </d:ProbeMatch>
        </d:ProbeMatches>
      </s:Body>
    </s:Envelope>

 

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.

 

image

 

Related Posts:

1. Part II: WCF and Service Discovery in .NET 4.0
2. Part III: NET 4.0 : Enabling WCF service for discovery


Visit: www.daenet.de


Posted Oct 19 2008, 12:09 AM by Damir Dobric

Comments

Damir Dobric Posts wrote WCF and Service Discovery in .NET 4.0
on 11-27-2008 0:05

This post describes how to implement the client able to perform discovery the service based on WS-Discovery

Damir Dobric Posts wrote Standard Endpoints and MexBindings
on 02-22-2010 22:12

WCF 4.0 provides few so called standard endpoints: WorkflowControlEndpointElement ServiceMetadataEndpointElement

Damir Dobric Posts wrote Standard Endpoints and MexBindings
on 02-22-2010 22:13

WCF 4.0 provides few so called standard endpoints: WorkflowControlEndpointElement ServiceMetadataEndpointElement

DamirDobric wrote Standard Endpoints and MexBindings
on 02-22-2010 23:07

WCF 4.0 provides few so called standard endpoints: WorkflowControlEndpointElement ServiceMetadataEndpointElement

Colin Geis wrote re: Messaging enhancements in .NET 4.0: (Discovery Part I)
on 09-25-2010 15:32

This is a nice overview.  Thank you.

I am investigating use of WS-Discovery for "adding" a build machine to a web application that directs distributed software builds.  Each build machine would be discoverable responding with the version it supports and a few other details needed by the web application.

developers.de is a .Net Community Blog powered by daenet GmbH.