OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ws-dd message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: Issue 124 - WS-Discovery - xAddrs in ResolveMatches issue

Please review the proposal for resolving this issue. The proposal is in conjunction with the resolution of issue 125.






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


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


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






From: Ram Jeyaraman [mailto:Ram.Jeyaraman@microsoft.com]
Sent: Tuesday, December 16, 2008 8:09 AM
To: ws-dd@lists.oasis-open.org
Subject: [ws-dd] Issue 124 - WS-Discovery - xAddrs in ResolveMatches issue


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


From: Dan Driscoll
Sent: Monday, December 15, 2008 8:41 PM
To: Ram Jeyaraman
Subject: NEW issue: WS-D xAddrs in ResolveMatches issue


Physically addressed services that do not have distinct xAddrs are currently forced to generate an empty xAddrs element or produce no ResolveMatches at all in response to a Resolve for their EPR.


Since not all clients have the same understanding of physical addresses as services (some clients may know nothing about HTTP, for instance) Target Services need a way to generate meaningful ResolveMatches messages without including empty elements.  That way, they can inform clients that their EPR should be interpreted as a physical address.


Proposed change:

·         Make xAddrs optional in ResolveMatches schema (add ‘minOccurs=”0”’)

·         Craft some language that makes xAddrs mandatory in ResolveMatches if the service has xAddrs.  I’ll work with Vipul to build this.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]