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:Toby.Nixon@microsoft.com]
Sent: Monday, December 22, 2008 5:41 PM
To: ws-dd@lists.oasis-open.org
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
toby.nixon@microsoft.com
| 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 <Ram.Jeyaraman@microsoft.com>
- To:
"ws-dd@lists.oasis-open.org" <ws-dd@lists.oasis-open.org>
- 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 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 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 The Figure 3 will changed to reflect the text above. Section 5.3 /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 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. |