Issue 125 - WS-Discovery - Finding services require a double roundtrip

[Ram Jeyaraman <Ram.Jeyaraman@microsoft.com>]

This issue is assigned the number 125. For further discussions on this issue, please refer to this issue number or use this thread.

 

From: Vipul Modi
Sent: Monday, December 15, 2008 9:54 PM
To: Ram Jeyaraman
Subject: New Issue: WS-Discovery: Finding services require a double round trip

 

Spec: WS-Discovery

 

Version: Working Draft 04

 

Details:

The current WS-Discovery specification describes the conceptual content of the messages in Section 3.1. It mentions that a ProbeMatch may not have a complete information such as transport addresses for the endpoint. After receiving the ProbeMatch the client may need to send a Resolve for the endpoint from which it got the ProbeMatch to get the transport addresses. This double round trip increases the latency of the find operation on the client and also increases the network traffic. It seems unnecessary; the service should simply include transport addresses, if any, in the ProbeMatch message. This is what most of the implementation do today, by making the transport addresses, if any mandatory in the ProbeMatch, the Client implementation can be more deterministic and can avoid unnecessary Resolve immediately after a Probe.

 

Proposal:

 

Section 3.1

Starting at the top of Figure 3, Probe maps from Types and/or Scopes to an Endpoint Reference [WS-Addressing] and one or more transport addresses; though not depicted, Hello also provides an Endpoint Reference. Resolve maps Endpoint Reference this information to one or more transport addresses. Other address mappings may be needed, e.g., DNS, but are beyond the scope of this specification.

The required components of each message are defined in detail below, but as an optimization, a Target Service may short-circuit these message exchanges by including additional components; for instance, a Probe Match Hello may contain transport address(es) along with an Endpoint Reference, or a transport address may use an IP address instead of a DNS name.

 

The Figure 3 will changed to reflect the text above.

 

Section 5.3

/s:Envelope/s:Body/d:ProbeMatches/d:ProbeMatch/d:XAddrs

See /s:Envelope/s:Body/*/d:XAddrs in Section 4.1 Hello.

Transport address(es) that MAY be used to communicate with the Target Service (or Discovery Proxy). Contained URIs MUST NOT contain white space. If a Target Service has transport address(es), at least one MUST be included to avoid an immediate Resolve.

In a managed mode, all transport address(es) SHOULD be included.