RE: Issue 125 - WS-Discovery - Finding services require a doubleroundtrip

As we discussed this is the
modified proposal for this issue in light of issue 124.

 

Thanks,

Vipul

 

--

 

Moved the conceptual message
content paragraph from ad-hoc mode sub-section to separate sub-section in
Section 3 as it applies to both ad-hoc and managed mode. In addition to the modifications
shown below the figure was modified to indicate that a Probe Match provides
both EPR and transport addresses. 

Conceptual Message Content

Conceptually, Hello, Probe Match, and Resolve Match contain
different kinds of information as Figure 3 depicts.

Figure 3 : Conceptual content of messages.

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 (see Section 3.1 Endpoint
References). Though though
not depicted, Hello also provides an Endpoint Reference. Resolve maps this
the Endpoint Reference to one or more transport addresses (see Section 3.1 Endpoint References). 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.

 

 

Probe Match Section

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

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 (or Discovery Proxy) has transport addresses (see Section 3.1 Endpoint
References) at least one transport address MUST be included. If omitted or
empty, no implied value. See /s:Envelope/s:Body/*/d:XAddrs in Section
5.1 Hello.

 

Resolve Match Section

/s:Envelope/s:Body/d:ResolveMatches/d:ResolveMatch/d:XAddrs

As constrained for Probe Match (see
Section 6.3 Probe Match). See
/s:Envelope/s:Body/*/d:XAddrs in Section 5.1 Hello.

 

 

 

From: Toby Nixon
[mailto:] 

Sent: Monday, December 22, 2008 5:41 PM

To: 

Subject: [ws-dd] RE: Issue 125 - WS-Discovery - Finding services require
a double roundtrip

 

Here’s a proposed resolution to Issue 125. 

 

I
think the previously proposed changes to
Section 3.1 are fine. The concern I expressed on the last teleconference was with the
proposed change to Section 5.3, and was that the
new sentence (“If a Target Service has transport address(es), at least
one MUST be included to avoid an immediate Resolve.”) is ambiguous; it can be interpreted to mean that the target
service need only include one transport address in its ProbeMatch but
could include more at its option. The intent as expressed on the last
teleconference was that the target service must include the same transport address(es) in its ProbeMatch that it would include in a
ResolveMatch if one were immediately requested. I therefore propose that the
text previously proposed be changed to the
following (all of the text is red because this is actually new text in 5.3,
even though some of it was copied from section 4.1):

 

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. In order to
avoid the need for the Client to immediately send a Resolve to obtain the
transport addresses of the Target Service, if a Target Service has one or more
transport addresses, XAddrs MUST be included in ProbeMatch, and the transport
addresses included in ProbeMatch MUST be the same as would be returned in a
ResolveMatch to the same Client.

 

Note that the last sentence previously proposed is not included
(“In a managed mode, ALL transport address(es) SHOULD be
included.”). It had been cut and pasted from the description of the Hello
message in Section 4.1, which made sense because Section 4.1 was referenced in
the previous definition. However, it doesn’t actually make sense in the
case of ProbeMatch, which is sent only to clients and not to proxies, so the
requirement to include all transport addresses does not apply. It only
makes sense to send all transport addresses when a Target Services is sending a
Hello in managed mode to a proxy, so that the proxy has full information and is
able to send the appropriate information on behalf of the service when a Client
sends a Probe to the proxy. We may want to consider also making this same
clarification in the description of the XAddrs element of ResolveMatch.

 

           
-- Toby

 

Toby Nixon 
|  Senior Standards Program Manager  |  Windows Device and
Storage Technologies  |  Microsoft Corporation

 
|  www.microsoft.com
| V: +1 425 706 2792  |  M: +1 206 790 6377  |  F: +1 425
708 4811

 

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

 
From: Ram
     Jeyaraman <> 

 
To:
     "" <> 

 
Date: Tue, 16 Dec
     2008 08:10:40 -0800 

 

  
  
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.