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., http://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.