Share via

xAddrs optionality in WS-Discovery messages

  • Article

Traditional big web services, like a billing system or a service running in the cloud, nearly always have fixed addresses--often HTTP URLs.  Smaller web services, such as those on a PC or a device, often have logical identifiers ("urn:uuid:c3de740f-9227-4706-b3ee-9494243c040d") that let you recognize the service, but which don't actually tell you anything about how to contact the service.

One of the great uses of WS-Discovery is transforming logical addresses into physical addresses (e.g., https://my_pc/service/) so you can actually contact the service.  A service uses the xAddrs field in WS-Discovery messages to express its transport addresses.

But it turns out that these xAddrs are optional.  There are actually a lot of really good cases why you would want to omit them--if they're very large, or if you don't want to generate different Hello messages for every IP address in the system--but the specification doesn't clearly explain when they're often omitted in the real world, and what happens when they are.

So let's go through the four messages a service can send.

  • Hello messages sometimes contain xAddrs.  On any given subnet it's likely to encounter Hello messages both with and without xAddrs.  Those without xAddrs will cause a Resolve from any clients interested in the service.  Hello is the only multicast message that can include xAddrs, so it's a little unique--and it differs from ProbeMatches and ResolveMatches in that sense.
  • Bye messages never contain xAddrs.  The specification does not allow it (note that this has been changed in WS-Discovery v1.1).
  • ResolveMatches messages always contain xAddrs.  It's technically possible for the xAddrs element to be empty but this is unusual and probably not a good way to achieve interoperability.  A service must realistically always produce xAddrs in its ResolveMatches messages.
  • ProbeMatches messages usually contain xAddrs.  It's very unusual for services to omit xAddrs in their ProbeMatches messages because it takes no more effort than including them in ResolveMatches--both messages are unicast responses.  Including xAddrs in ProbeMatches lets everyone avoid a Resolve/ResolveMatches exchange.

One interesting consequence of this is that the example sequence on page 11 of WS-Discovery (Probe -> ProbeMatches -> Resolve -> Resolve Matches -> success!) almost never happens.  Services usually include xAddrs in their ProbeMatches messages in the first place.

Comments

  • Anonymous
    September 11, 2009
    HI, I am trying to implement DPWS Discovery on my device to be able to send Hello messages and subsequently ProbeMatch, ResolveMatch, GetMetadataResponse etc. Howevere, sometimes when I send ResolveMatch or ProbeMatch from my device to Vista, Vista is not sending the next message and I suspect that I sent something in ProbaMatch or ResolveMatch because of which Vista decided not to go forward to send the next request to device. In this case it would help to understand why Vista dropped/ignored the message? So, please let me know if there are any tools for Vista using which I can see the Log Messages of DPWS Stack on Vista, Check why certain responses are not liked by Vista and hence not continuing with its next action. Please point me to some tools on Vista. Please note that Wireshark or similar tool will not help because I am interested in knowing what's hapening in Vista Machine (Logged Messages0 and not outside Vista Machine. Thanks and Regards Sankarshana M

  • Anonymous
    September 14, 2009
    Hi Sankarshana- Currently there's no way to view any logging related to WSD messages.  I realize this is not very convenient. One thing you can try is to compare your messages against known-good samples, such as those in the WS-Discovery specification, or those sent by Windows.  The WSDDebug_host tool can also be used to configure the service to send specific WS-Discovery responses. I hope this helps --Dan

  • Anonymous
    September 02, 2010
    Hello Dan, We are trying to write WS Scan driver. And we are using WSDL contract provided by the MSFT Rally. In our application we have called CreateCScannerServiceTypeProxy( <Web Services UUID>, <generated UUID>, &pProxyOut, &pXMLContext); We found that, as a result of this call, Resolve message has been sent to device, and device has also responded us with ResolveMatch. But still CreateCScannerServiceTypeProxy is returning E_FAIL. But if we pass the IP address of the device with port 65001, then everything works fine, that is metadata exchange happens and we are able to scan as well. Also, we have verified that if we stop sending XAddr in ProbeMatch, then Resolve message is sent to device and Inbox driver works fine with the same ResolveMatch. So, seems like device is working fine. May be there is some error in our call sequence.

  • Anonymous
    September 03, 2010
    Hi Rita- The WSDAPI Troubleshooting Guide describes steps for diagnosing discovery problems like this one.  You may find it to be helpful--it's available here: msdn.microsoft.com/.../bb648709(v=VS.85).aspx Thanks --Dan

  • Anonymous
    January 21, 2013
    The comment has been removed